August 19, 2007
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.
You little scumbag! I've got your name! I've got your ass! You will not laugh. You will not cry. You will learn by the numbers. I will teach you.
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.
Posted by Jeff Atwood
Steve: "The deep dark secret underneath it all is that the software is company property and it needs to be done a certain way if the management says so."
The question is why this is even a "dark secret".
While I agree with the blog post, it isn't quite complete. It doesn't take too much experience for people to think that they know everything. Being able to introduce standards requires that people are open minded about adopting them. Very few people are open minded at all.
One does need to be "respectful" but one also needs to make it clear that standards have to be followed because of the "deep dark secret".
I think the lesson here is that you need to convince developers that they should follow the standards because they want to, because they believe in them.
*Not* because they were ordered to do so.
This is doubly true for software developers, who tend to be quite stubborn and heastrong. Myself included, of course.. :)
You can use Marine Corps leadership methods and not be like Gunny Hartman (BTW, the character failed at his job because he didn't remove Pyle from the platoon ASAP). Here's an article series I recently wrote about it: http://vbnotebookfor.net/2007/07/25/marine-corps-leadership-secrets-part-i/
The bottom line is that a lot of leadership is just having basic common sense in dealing with people.
Dave: easy on the Mountain Dew...
njkayaker: It's a "secret" because many developers aren't aware of this concept and think the project is their "canvas" to express themselves. Which isn't bad, but perhaps do that mostly on your own stuff.
Most of Dennis' points really boil down to this - be respectful. Be respectful of what people know even if you know differently, be respectful of what they have achieved even if you don't admire it, be respectful of what they think even if you don't agree with it.
Going down the path of actions instead of words says you don't know better than everyone else, you are just one of the guys. That shows respect for the job they do, because you are doing it to.
Love? Well, change the word to respect and I'd have to agree. Love is just a bit ripe for me, particularly concerning most of the technical people I know :)
"We may love our machines and our code, but our teammates prove much more complicated."
I am not sure where I heard this but it is a good rule for programmers in general (It might have been John Carmack talking about univeristy profs), it went something like: Just because you are smarter then them doesn't mean they don't have anything to teach you.
It goes along with the theme of just being respectful as Phil pointed out.
Hey, Jeff, let me be a picky bastard for a second (unusual because I tend to be such all day long).
I don't know what kind of blog software you use, but does it allow title-based urls? I mean, it sucks to hover the mouse on a hyperlink and see that it refers to blog post ID# 000788 which I can't at all recall the contents by number.
I don't know about other readers, but I never feel compelled to click a link that doesn't show me exactly where it's going.
It's either that or using the exact blog post title in the hyperlink, which makes for bulkier content.
Anyway, just being an annoying reader here :) Since you so detail-oriented and thorough, I thought it would make sense to point that out in the best interest.
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.
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.
Hey Jeff buddy, I love your blog man. Way too cool.
Correction, herding very smart cats...
Fantastic post! I agree that the human aspect is much more difficult to manage. As everyone has, I've ran into the individuals that send out the best practice emails, etc., yet never actually show you a real solution. We had a prime example at my company, and he is no longer here and either is the director who backed him. Lead by example, not by continuously talking about it. Code something up...and show someone...rather than talk about how it *should* be.
Keep up the great work on the blog, Jeff. I'm an avid reader.
It's certainly a mixture, particularly in this era of not having an opinion that might offend anyone.
One needs to be caring, to lead by example, to point out the benefits of a particular style, etc. The deep dark secret underneath it all is that the software is company property and it needs to be done a certain way if the management says so.
Years ago, working with a mainframe 4GL, we had published standards that everyone was accountable to live up to. But the boss said, "if our standards are wrong, prove it, we will change them". There was a review committee for this purpose.
"Not every application is a high-volume e-commerce site."
Well, thank goodness *somebody* noticed this.
Now, could you broadcast this fact to every dimwitted middle manager at Microsoft, Oracle? And while your at it, maybe we could get the word out to the thousands of myopic web-addled software shops in the world until they get the point?
A tester of ENGINEERING software
"Becoming a Technical Leader" is the single-most important book that I have ever read (several times). Jerry understands that being a technical leader is a people skills issue. Please read it and change the way that you "do software".
I'm always amused at companies who seem to believe that a manager can *either*:
a) have management skills
b) know how to do the job he's supervising.
I've found the hard way that either/or doesn't get you very far in a group.
Thanks for another interesting post Jeff.
Motivation and not de-motivation are a complex subject, and the idea of 'not de-motivating' is certainly simpler as Greg Askew points out.
However I've found that although not simple, motivation is extremely effective if done, and indeed possible. It takes experience and study, and I'd love to be better at it.
"There's never a bad student, just bad teachers" - I believe this to a point. Some students/team members are just mired in being a pain in the ass and worthless, and motivation certainly draws from the law of diminishing returns. Often it's just not worth it to take the time to get someone to be decent at their job.
That doesn't mean it's not possible.
Managing is certainly at least as much of an art as a science. Probably more so.
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!!
Tom DeMarco and Tim Lister: Why Does Software Cost So Much?
has some great essays on software leadership.
One is called "Standing naked in the snow" - about the transformation necessary for moving from engineering to management. Management is fundamentally different from engineering.
Another is "Pasta e Fagioli" about building team spirit by cooking together.
Sadly though the reality is one of messy even amateurish software kludged together by clueless undereducated losers who can't even work version control, wouldn't know an interface if it bit them and for whom a normal form is something you use to apply for expense with. The new guy is trying to gently point out that your guys a bunch of lamers who need the axe... and your afraid he's right - because he is.
Standing nacked in the snow my ass.
Very good post and i really liked it.I almost agree with all the points you mentioned.
A very good post.
In the software industry, higher managers tend to create more problems rather than solving the existing ones.
I would love to read the book and share the knowledge with my team
Jeff Atwood (quoted): "I think the lesson here is that you need to convince developers that they should follow the standards because they want to, because they believe in them."
Ideally, it would be possible to convince them. In practice, one might not be able to.
Steve (quoted): It's a "secret" because many developers aren't aware of this concept and think the project is their "canvas" to express themselves. Which isn't bad, but perhaps do that mostly on your own stuff.
I know it's a secret. It's still strange that it is a secret. The "express themselves" issue is what I have a problem with. It's bad because it typically leaves messes that the "artist" doesn't have to clean up. Also this attitude indicates that the "artist" thinks he knows everything and he won't be open minded to learn new (or different) things. It's a bit weird that the default assumption of a developer is that he's an "artist" and not a member of a team.
I talked about the failure of enforced TDD in my blog too:
It's painful when other devs don't realize the value of some practices, but you can't really force them much. All you can do is, as you said, lead by example.
In other engineering disciplines, it doesn't matter whether someone's feelings might be hurt by criticism. If you are doing it wrong, the building will fall down, the power plant will blow up, the pipeline will burst, or the car will not start, no matter what you feel about your design.
In a structural engineering firm, you'd never hear people leading their coworkers by saying "While your idea of using tapioca pudding instead of concrete as a structural material is interesting, might I respectfully suggest some reasons why we might want to..."; instead, they would unleash a stream of profanities that would shock Sergeant Hartman before summarily firing the individual.
However, it seems like in the software industry, we're constantly cajoled to 'be humble', 'be discreet with constructive criticism', and 'herd cats' when people are doing the software equivalent of using pudding instead of concrete.
Managers need to strike a balance rules, protocol, and discipline (Gunnery Sergeant Hartman), and a lazy environment where nothing gets done. Programs like the kolb learning style can help maximize efficiency and produce better results.