Welcome to part 3 of my 2-part series on how to make Agile Development actually work. This one has to do with managing programmers, which is both completely outside the purview of Agile and yet inextricably tied to it. (It also ran a little long, since it’s a topic that I’m very passionate about. Hopefully you’ll stick with it.)
First, a word on nomenclature: At my current job, I am a “software engineer.” At my last job, I was a “code monkey.” What I really am is a programmer. You can dress that up however you like, but, if you primarily write code for a living, you’re a programmer, and the following thoughts apply to you. Be careful applying it too broadly, though: folks in other tech pursuits that hardly sling code at all, like system administrators and DBAs, may not fit the mold I outline here, and folks who write a lot of code but also do a lot of other things (e.g. QA engineers who specialize in automating tests, release managers who have to help code up things like continuous integration systems) may sort-of-kind-of fall into these patterns ... or not.
And, though I say above “if you primarily write code for a living, you’re a programmer, and the following thoughts apply to you,” what I really mean is, “if you primarily manage coders for a living, you’re managing programmers, and the following thoughts apply to you.” For the advice I’m going to give you is pretty useless if you’re the one being managed. We typically have so little say in those sorts of things. Which is sad, really, but a topic for another time.
Next, a note on my qualifications. I ran my own software development business for 12 years, and I followed one simple philosophy: keep your employees happy. I never worried about keeping my customers happy, because I found that, if you keep your employees happy—and not just content, but deliriously, ecstatically happy; happy to the point where, at the end of the day, they’d rather stay at work because it’s more fun than going home—they’ll produce such amazing software that the customer satisfaction thing just takes care of itself. I had more than one employee tell me that it was the best job they’d ever had. Very few of my employees ever left for any other reason than I’d run out of work for them, and nearly all the ones that left because of that ended up coming back later. I had an employee once sit at home jobless for a year and a half because he was just waiting for me to call with more work (and also because I’d paid him well enough that he could afford to do that). When I tell you that I know how to manage programmers, I ain’t fucking around.
And finally (at least as regards this introduction), a cautionary note. I generalize. I think it’s good to generalize, even about people, as long as you remember that, at the end of the day, we’re all different, and we all need to be treated just a little bit differently. You must be careful not to fall into the trap of stereotyping. But there’s still a lot to be gained by understanding the whole through understanding the majority (because, even though we’re all different, we’re all the same), so absorb what I’m saying here, but remember that you’re always going to encounter exceptions.
So how does one go about managing programmers?
Well, there are two things that you must remember. The first I’ve already discussed in some detail, and it would be pointless to belabor it again. I’m talking about the issue of perception vs reality. If you’re too busy to click that link, here’s the executive precis: Programmers spend all day talking to computers, which are insanely literal; they tend to lose their concepts of perception. You, however, are most likely a business executive, for whom things like your perception in the marketplace, your reputation, and your perceived brand value are paramount. This leads to a fundamental disconnect.
The second one I touched on in my exploration of what agile means: programmers are craftsmen. Very few people get this. Most folks think programmers are all logical and mathematical, like Vulcans. And it’s true that programmers have to have a logical component to their personality. But some of the worst programmers I’ve ever met were mathemeticians, or mechanical engineers. Not to disparage those professions—they’re very fine careers. But the point is, those fields attract people who like things to fit together neatly and sensibly. Programming isn’t neat. It’s heinously messy. Stuff goes wrong that no one can really explain, there are bizarre interactions between complex systems that were never foreseen, and there’s all these terribly illogical users involved in the process. People who like things tied up in a bow get really crazy when they have to develop software.
But, even more than that, coding requires creativity. There’s actually one backwater of mathematics that I remember from my school days which was a bit like programming: proofs. I first learned them in geometry, which I took in the ninth grade. A proof is a way to chain together different rules: this rule leads you to that rule and thence to the next, and so on. To chain these rules together requires a very logical mind. But you also need to have a sense of where you’re going, and that’s where the creativity comes in. You need to be able to make a creative leap to the end first, and then be able to logically work your way there from the beginning. If you start a proof without a clear idea of where you’re going, you most often end up right back where you started.
And so it is with programming. That creative leap is absolutely crucial to being a top-notch programmer. Without it you’re just a monkey pulling wrenches. If more people understood this, the world (or at least the business world) would be a better place.
Because I think that the business world already understands that you have to manage creative people differently. Advertising agencies, for instance, routinely hire artists, and writers, and people whose sole job is just to come up with ideas. They’ve figured out that you can’t treat these people in the regimented fashion that you do for other workers—giving them dress codes, and set hours, and making up weird little rules about what they can and can’t put on their cubicle walls. (Not that I’m saying that those are good ways to treat anyone, really. Just that trying to treat creative people in such a fashion is even more doomed to failure.) The Internet culture that came out of California in the ‘90s (and in particular out of Silicon Valley) has gone a long way towards fixing this for programmers. There are many businesspeople who now understand that programming can be fun and they need to encourage their employees to have fun while doing it. (That attitude is still more prevalent on the West Coast than the East, in my experience, but we’re getting there.)
But what I’m not sure of is whether the business folks realize why they need to promote the culture of fun. See, there are many jobs where you don’t really need to think very hard to get the job done. You just do them. They’re mostly easy, and a bit repetitive, and, once you’ve done them two or three times, you can practically do them in your sleep. Again, this is not to denigrate any of those jobs, or any of the people who enjoy them. I can certainly appreciate a job where I can let my mind do its own thing all day while my body churns out work. That’s a cool gig. But that’s not my job.
My job doesn’t just require me to think; it requires me to innovate. Every day, in a thousand little ways, I make tiny little creative leaps (and sometimes, if I’m lucky, a few giant creative leaps). In order to do that, your mind has to be relaxed, and clear. Focussed is good, sometimes, but other times stepping away and focussing on something else entirely (like a rousing game of ping-pong) is exactly what the doctor ordered. The one thing you absolutely cannot do is just plug away at it until it works. That takes forever, and ususally produces a mess. You need to be able to distract yourself, or maybe even just close your eyes and lean your head back and ponder.
Note that I say you need to be able to distract yourself. Having other people distract you doesn’t help. In fact, it’s horrible. Just ask Samuel Taylor Coleridge. Programming is brief periods of seeming inactivity (waiting for inspiration to strike) followed by intense bouts of insane productivity (where you put the inspiration down on paper, or in this case on screen). This is why programmers always want to work from home. Other people can distract you at home occasionally (particularly if you have a family and if you don’t sit them down and go over the “rules”), but in general the phone doesn’t ring, and people don’t wander by your desk for a quick chat, and there are no meetings. I know that you, as a businessperson, value meetings. You think that if you spend all day in meetings, you’ve actually accomplished something. We programmers are different. Our job is to write code. You can’t write code in a meeting.
And the business world (even the California business world) is reluctant to let programmers work from home. It’s changing, a bit, but still there are too many classically trained managers out there who believe that, if they can’t see you working, you must not be working. This is 100% a trust issue. I’m a programmer. I’ve been a programmer for 25 years—that’s over half my life (actually, I’ve been a professional programmer for over half my life; I’ve been a programmer for about two-thirds of it). I want to program. You want me to write code, and that’s what I want to do. If you let me go home, you know what I’m going to do when I get there? Program. Programming has got be one of the few jobs in the world like this. When you’re a programmer, you relax after a hard day of writing code by writing more code.
So you don’t have to come up with strategies for making me do what you want me to do. What you need is strategies to make sure nobody stops me from doing it. Reduce my interruptions. Reduce my meetings (agile helps with this). Reduce my emails, if you can, and reduce the people who just pop over to get my opinion on something. Stop telling everyone that they should not send me an email because it’s better communication if they come talk to me face-to-face. It may be better for you, but it’s death to me, and to my productivity (and isn’t that what you’re striving to maximize?). I want fewer emails too, but given the choice between a communication that I can attend to when I was going to take a break anyway and one that blows my concentration and makes me drop the threads I was juggling in my feverishly inspired brain, guess which one I’m going to take?
Now, it’s true that you also have to find a way to focus me. Programmers, like magpies, are notoriously easy to distract with shiny things, like new computers, new software, new web sites, and discussions about geeky hobbies like roleplaying and MMORPGs and Renaissance Faires. And, along those lines, we can get off track, chasing down something that seemed like a good idea at the time, but in retrospect turned out to be a giant temporal black hole. Getting back to how agile addresses these issues, that’s what “daily scrums” are for. It’s the chance for the programmer to say “well, yesterday I spent all day looking for a decent Javascript beautifier that would unravel this minimized code I’ve been staring at for the past week,” and the chance for someone else on the team to say “dude, I got one back at my desk; I’ll email it to you.” There you are: problem solved, distraction eliminated, yak shaved by proxy. Or perhaps they’ll describe the problem they’re stuck on and someone else will say hey, I’ve solved that before, I can help. Whatever. The point is to keep the coder on track and working towards the solution.
And, as I also mentioned in the agile theory post, we programmers are tinkerers, and it’s the responsibility of the business to help us from getting lost in that and never finishing anything. You have to be careful not ot take it too far of course, because some amount of tinkering is necessary to keep things running smoothly. It’s a careful balance, but you’ll get the hang of it. Give us some rope, and be prepared (but not anxious) to tug us back if we range too far.
But, other than that, there’s actually very little you have to do to get us to produce the software you want. In fact, the more you do, the more likely you are to make it worse. Programmers react to micromanagement by slowing down: you want to focus on trivial things? fine, I’ll focus on trivial things. Programmers react to attempts at measurement by getting picky and measuring everything in sight. Programmers react to bonuses based on lines of code by writing unnecessary code, they react to bounties for finding bugs by adding more bugs, and they react to having to meet detailed performance goals by adhering to the exact letter of the goals and completely ignoring the spirit. Businesspeople tend to find this more than annoying: they find it downright insubordinate. But think of it this way: first, a programmer is prone to taking things very literally (talking to computers all day, remember?), and secondly you actually pay them to find the most efficient solutions to thorny problems. Don’t get ticked off if they end up turning that ability against you when you try to control their workday.
In fact, getting the most out of programmers generally amounts to not pissing them off. Not treating them with respect, or not trusting them, pisses them off. Asking their opinion about something and then ignoring it really pisses them off. Asking them to produce shoddy software because you’re in a hurry makes them livid. Expecting them to do a lot of things at once and not understanding the simple fact that shit takes time (and also that nine women can’t make a baby in one month) makes them rethink their choice of employer. Agile will help you with a lot of this. Some of it, though, you just have work out on your own.
And it ain’t hard. We programmers are simple creatures, really. You’re just not used to us because we’re different from anything you’ve ever had to manage before. And here I’m going to be presumptuous and move from giving you advice on programmers to giving you general advice on management (but, remember: I’ve actually managed people, even people other than programmers). Robert Heller, a well-known writer on the topic of management, once said:
The first myth of management is that it exists. The second myth of management is that success equals skill.
Now, like any good quote, that’s going to mean different things to different people. But here’s what it means to me:
The first sentence merely means that most people treat management as an active thing, whereas they should be treating it as a passive one. Voltaire (supposedly) said: “The art of medicine consists in amusing the patient while nature cures the disease,” and the same applies to management. Much of the time, the best way to succeed is simply to get out of the way.
The second sentence means that you must be careful not to let yourself get caught in a feedback loop. If you undertake a style of management which is actually very horrible, and your employees succeed despite you, you may believe your ideas are validated. This is important to understand, I believe, because it answers of the question of “why haven’t people figured all this out by now?” If you’re a business executive reading this post and shaking your head and saying “man, this guy is crazy!” then I urge you to go find a programmer and give it to them to read. They will no doubt nod and mutter “oh, yeah, that’s so true” under their breath the whole time. The fact is, nothing I’m saying here will come as any surprise to any programmer working in America today (and probably not to the ones working in other places either). And yet business has managed to go 50 years without figuring it out. How? Are businesspeople stupid? No, of course they’re not. But management, like medicine, can seem like it’s working even when it’s doing more harm than good. Remember leeches? People thought they worked too. Those people weren’t stupid either. But, as it turned out, leeches were a pretty bad idea.
So rethink your strategies with your employees, particularly if they’re programmers. Don’t stand behind them and push. The definition of the word “lead” implies that you have to be in front. And not pulling either: just striding ahead, with confidence. (And a few donuts wouldn’t hurt either.) You don’t even have to look back that often. If you are a business with hard problems to solve, we’ll be following you. After all: solving hard problems is what we live for.
No comments:
Post a Comment