It takes discipline for development teams to benefit from modern software engineering conventions.
If your team doesn't have the right kind of engineering discipline, the
tools and processes you use are almost irrelevant. I advocated as much
in Discipline Makes Strong Developers.
But some commenters were understandably apprehensive about the idea of having a Senior Drill Instructor Gunnery Sergeant Hartman on their team, enforcing engineering discipline.
Cajoling and berating your coworkers into compliance isn't an effective
motivational technique for software developers, at least not in my
experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn't to brainwash everyone you work with, but to negotiate commonly acceptable standards with your peers.
I thought Dennis Forbes did an outstanding job of summarizing effective leadership strategies in his post effectively integrating into software development teams. He opens with a hypothetical (and if I know Dennis, probably autobiographical) email that describes the pitfalls of being perceived as an enforcer:
I was recently brought in to help a software team get a product out the
door, with a mandate of helping with some web app code. I've been
trying my best to integrate with the team, trying to earn some
credibility and respect by making myself useful.I've been forwarding various Joel On Software essays to all, recommending that the office stock up on Code Complete, Peopleware, and The Mythical Man Month,
and I make an effort to point out everything I believe could be done
better. I regularly browse through the source repository to find ways
that other members could be working better.When other developers ask for my help, I try to maximize my
input by broadening my assistance to cover the way they're developing,
how they could improve their typing form, what naming standard they
use, to advocate a better code editing tool, and to give my educated
final word regarding the whole stored procedure/dynamic SQL debate.Despite all of this, I keep facing resistance, and I don't
think the team likes me very much. Many of my suggestions aren't
adopted, and several people have replied with what I suspect is thinly
veiled sarcasm.What's going wrong?
I'm sure we've all worked with someone like this. Maybe we were even
that person ourselves. Even with the best of intentions, and armed with
the top books on the reading list, you'll end up like Gunnery Sergeant Hartman ultimately did: gunned down by your own team.
At the end of his post, Dennis provides a thoughtful summary of how to avoid being shot by your own team:
Be humble. Always first presume that you're wrong. While
developers do make mistakes, and as a new hire you should certainly
assist others in catching and correcting mistakes, you should try to
ensure that you're certain of your observation before proudly declaring
your find. It is enormously damaging to your credibility when you cry
wolf.Be discreet with constructive criticism. A developer is much
more likely to be accept casual suggestions and quiet leading questions
than they are if the same is emailed to the entire group. Widening the
audience is more likely to yield defensiveness and retribution. The
team is always considering what your motives are, and you will be
called on it and exiled if you degrade the work of others for
self-promotion.The best way to earn credibility and respect is through hard work and real results.
Cheap, superficial substitutes -- like best practice emails sent to
all, or passing comments about how great it would be to implement some
silver bullet -- won't yield the same effect, and are more easily
neutralized.Actions speak louder than words. Simply talking about
implementing a team blog, or a wiki, or a new source control mechanism,
or a new technology, is cheap. Everyone knows that you're just trying
to claim ownership of the idea when someone eventually actually does
the hard work of doing it, and they'll detest you for it. If you want
to propose something, put some elbow grease behind it. For instance,
demonstrate the foundations of a team blog, including preliminary usage
guidelines, and a demonstration of all of the supporting technologies.
This doesn't guarantee that the initiative will fly, and the effort
might be for naught, but the team will identify that it's actual
motiviation and effort behind it, rather than an attempt at some easy
points.There is no one-size-fits-all advice. Not every application is a
high-volume e-commerce site. Just because that's the most common
best-practices subject doesn't mean that it's even remotely the best
design philosophies for the group you're joining.
What I like about Dennis' advice is that it focuses squarely on action
and results. It correlates very highly with what I've personally
observed to work: the most effective kind of technical leadership is leading by example. All too often there are no development leads with the time and authority to enforce, even if they wanted to, so actions become the only currency.
But actions alone may not be enough. You can spend a lifetime learning
how to lead and still not get it right. Gerald Weinberg's book Becoming a Technical Leader: an Organic Problem-Solving Approach provides a much deeper analysis of leadership that's specific to the profession of software engineering.
Within the first few chapters, Weinberg cuts to the very heart of the
problem with both Gunnery Sergeant Hartman's and Dennis Forbes'
hypothetical motivational techniques:
How do we want to be helped? I don't want to be helped
out of pity. I don't want to be helped out of selfishness. These are
situations in which the helper really cares nothing about me as a human
being. What I would have others do unto me is to love me-- not romantic
love, of course, but true human caring.So, if you want to motivate people, either directly or by creating
a helping environment, you must first convince them that you care about
them, and the only sure way to convince them is by actually caring.
People may be fooled about caring, but not for long. That's why the
second version of the Golden Rule says, "Love thy neighbor", not
"Pretend you love thy neighbor." Don't fool yourself. If you don't
really care about the people whom you lead, you'll never succeed as
their leader.
Weinberg's Becoming a Technical Leader is truly a classic. It is, quite simply, the thinking geek's How to Win Friends and Influence People.
So much of leadership is learning to give a damn about other people,
something that us programmers are notoriously bad at. We may love our machines and our code, but our teammates prove much more complicated.
>Comments:
How many times has a performer joined a team with an expectation to
carry the water for non-performers? Or worse, fix non-performers. This
scenario is far too common in the IT industry, and is 180 degrees wrong.
Individuals are responsible for fixing themselves. Leading by
example is a noble concept, but at the end of the day everyone is
accountable for their own performance. The real failure in leadership
occurs when leadership does not communicate to individuals what is
expected of them, when it needs to happen, and what will happen if they
do not perform.
Most of this perpetual greek tragedy links back to inept hiring. If
a manager isn't any good at hiring, they produce an inferior product.
If a manager inherits the result of someone else's bad hiring, and
cannot or do not replace them, they produce an inferior product.
One other thing - about "motivation". There is a considerable amount
of empirical data to suggest that efforts to "motivate" people are a
waste of time. It is true, however, that one should avoid doing things
that would "de-motivate" people. There is a difference.
>Comments:
Becoming a Technical Leader... should have a subtitle of "herding
cats without being mauled to death". As mentioned above, the word is
respect. If you walk into a situation without knowing any of the
people, what they're doing, why they're doing it that way, and even
what their perception of the process might be, then start spouting off
about changing things because they aren't being done right - you'll be
shot down every time. And rightfully so.
I haven't read Weinberg's book, I think I'll pick it up. I have read
How to Win Friends and Influence People. Besides the fact that the
title is pretty sucky - it's an excellent book. I'll never be a sales
person, but it's a different way of looking at things. It's a difficult
thing being a technical manager, those who do it right are worth their
weight in gold.
>Comments:
Good article, I agree with the concepts completely. However, I don't
know how well they gibe with reality. For example I work for a large
auto insurance company, my division alone has 300 developers working
more or less on a common platform (and tools to support it, maintain
it, etc) and though it pains me to say it, barely capable of
maintenance coding, god forbid innovating new concepts. And these folks
run the gambit from entry level to retired in place, to about to
retire. They're not looking for a leader, they're looking for a
paycheck and doing as little as possible to get it. I agree this is
really a company culture problem, but if my company is like any of
your's this isn't sounding our of the ordinary.
Sometimes, you do indeed need Gunny!!