At Group L, Stoffel oversees six first-rate programmers, a managerial challenge roughly comparable to herding cats.
The Washington Post Magazine, 9 June, 1985
Managing computer programmers (or software engineers, as some like to style themselves) is orthodoxly likened to herding cats. This analogy particularly amuses me.
There are some who consider it a bad thing that managing programmers is like herding cats. I believe this is because they make the mistake of assuming that the way to go about herding cats is to apply, to cats, the methods that are well established as effective for herding cattle. Applying those methods to cats merely annoys them, without materially improving the chances that they'll do what you wanted (indeed, it probably ruins any chance you might have had). When the cats in question happen to be bigger than you, annoying them can be very bad for your life-expectancy.
Likewise, if you attempt to manage programmers via the sort of
command-and-control hierarchy that is standard practice for managing factory
operators (albeit, I suspect, far from the best way to go about managing them),
you'll annoy them and they won't do what you want. Since, in practice, good
programmers are a more valuable asset to a company than any manager who's
failing to get his staff to do what was asked for, annoying them can be
a career-limiting step
.
If you ever find yourself tasked with herding cats, start by thinking carefully about what they're good at – sleeping, looking cute and doing cutely silly things, purring, terrorising small animals, shredding furniture and wall-paper – then at what you were actually tasked with ensuring they do. If the latter's something they're singularly poorly equipped to do (e.g. pull a sledge across the arctic), advise whoever told you to do that of the folly of their instructions and leave the cats alone. If it's something they can do but don't like doing (like looking after small children who haven't yet been taught how to interact with cats), you'll need to provide good incentives or they'll all go away (possibly shredding the small children first). If it's something they like doing (which matches fairly well to what they're good at) you can mostly leave them to it – they'll need very little herding. Of course you'll have to ensure they dispose of bio-waste in socially acceptable places (litter tray, flower bed) and keep them from fighting or tearing up the furniture, so you'll have to pay attention and be ready to intervene when necessary. Even then, you can leave quite a bit of that intervention to the other cats (but you need to be sure you understand which cats intervene usefully and which otherwise); and when you do need to intervene, you need to do so intelligently. Cats are pretty good at being cats: they have little need for anyone to tell them what to do.
If you get things right, you can likewise mostly leave programmers to get on with their job. The ones who're any good at it actually enjoy it, so your main tasks are going to revolve around ensuring they're well-informed about what's wanted of them and keeping anyone else from getting in their way or wasting their time with stupid demands for things better done by someone else (crossing the arctic). They'll develop their own opinions about which of their peers they respect: you need to give as much authority to these as they'll accept (and no more: they don't much like wielding authority), back them up (in a quiet but clear way) when they exercise it and be sure to communicate clearly and openly with them about what goals you're expecting your herd of programmers to achieve. Be sure to listen to your programmers, too – especially the ones the others respect. What they say you need might not be exactly right, but it's a big sign-post towards something you do need: discuss it with them and be imaginative about finding an affordable and effective way to meet their underlying needs. When they say you aren't going to get what you've asked for, pay attention.
If you want to manage people, in any kind of job, you need to understand their culture and, crucially, the mechanisms by which it awards respect. With dogs it's possible to command respect by establishing that you're mightier, despite your total inability to be good at dog-ish things like smelling, barking and chasing cars: with cats, mightiness doesn't win you respect, so you can't take that short-cut. In some socio-economic contexts, as among dogs, respect follows strength and/or power: but in programmer sub-culture respect follows demonstrated competence. If you aren't a skilled programmer, you aren't going to get programmers to respect your decisions about how programming should be done: so, instead, identify the programmers who can command that respect, give them the authority to make the decisions and make sure they know what objectives you need to see met. If you get that right, you'll be demonstrating competence at your job, which'll get you respect from programmers.
I'm inclined to suppose that most of the above applies to folk in other professions, too: you might be able to get away with bullying bossiness, but you'll probably do far better by making sense of, and co-operating with, the social dynamics of those you manage. Even when bullying gets you obedience, you can't rely on it to get you respect – whereas, if you treat those who're good at what they're doing with respect, and do your part even half-way sensibly, respect will follow: and respect can get you something far better than obedience. When folk respect you as to your part, and are confident in your respect for them in relation to their part, they'll often do the thing you actually needed done, without being told, and tell you what you really need done when what you ask for is mis-guided.
On a related, there are differences in how managers and staff use time, that can lead to conflicts when they interact.
Written by Eddy.