Summary
Two radically different philosophies to the management of software developers. Which one do you favour?

Advertisement

Recently my wife and I were discussing the next few years, including what kinds of work I'd be taking on after
my current stint: I'm currently splitting my time between helping a client's team redevelop a successful, but
aging, data manipulation product to be able to handle data sets up to 4 orders of magnitude larger that it can
currently manage, and working on my next book(s). Both activities are highly demanding, very rewarding, and
probably going to complete early next year. Lucky me! ;-)

After that, my current (modest) plan is to do some hard-core consulting to the banking and finance industry here
in Aus, hopefully helping them to boost the performance of their trading systems by substantial amounts.
(Working on high-performance high-robustness networking systems is what most whets my development appetite.)

But after that, perhaps towards the end of next year, I said I'd like to take on a new development team, but do
so on my terms. (These terms will be explained in a moment.) Having just come out of a position of being
involved in the management of a development team in a struggling organisation, with all the stresses that that
entails, my wife naturally enquired as to why I'd consider going back to that. She makes a good point, because
it was a hell of a cat-herding, management-juggling, technology-obviating 18 months. (Helping developers to
learn and improve is what most whets my managerial appetite.)

The question of why I'd like to try it again - after my product redesigning, book writing, bank optimising,
library releasing fun in between - boils down to what I have lamely termed down the years (in conversational
rants on the subject with anyone who'd listen): the Equine Management question. A friend recently
suggested that I put it down on electrons somewhere, so here goes. Please come along for the gallop ...

Equine Management

In The Mythical Man-Month, Fred Brooks comments on studies showing that within groups
of experienced, competent developers there can be productivity differences of up to 1000%.
Furthermore, the quality of the produced software can have similar disparities. Brooks comments that software
produced by experienced, competent developers can have performance differences of up to 500%.

From personal experience, I can certainly say that I've experienced groups of developers with productity and
quality - not that software performance is the only, or even the most important, measure of quality - ranges at
least as large as this. Where I would demur - again, based on personal experience - is in stipulating that the
large ranges encompassed "experienced, competent developers". (Again, more of this in a moment.)

Being keenly drawn to simplicity in managing life, I am given to applying deductive reasonsing from facts to reach
conclusions regarding human behaviour. In this case, I believe that the critical role of any software
development manager is to ensure that his/her development team is populated with individuals who are towards the
upper end of the performance range. This may be achieved by a variety of means including, but not limited to,
recruitment, education, and mentoring. But that's just the tip of the ice-berg. Crucially, having a team
populated with high-performing individuals is no more permanent than the optimal conditioning range of the
musculature/brain/aerobic-system/etc. of an elite athlete. As soon as you allow it to, it will erode. Being a
developer who is capable of inhabiting the upper bands of these metrics, I am all too aware from experience how
easy it is to fall down the ratings, through fatigue, bad management, lack of appreciation (more often peer approval,
though money is a factor) and boredom.

Racehorse Management

What I call the Racehorse Model of Development Management recognises the wide range of possible
performance of software developers and the concomitant opportunity for an organisation to prosper, and attempts
to give them the best possible circumstances within which to produce at their best. Given that software costs
are a significant factor in (almost?) all software development organisations, dramatic increases of the order of
100-1000% are to be sought, and valued, most highly.

Racehorses get the best hay, they get to come in at night, they get the best medical care, they are brushed,
massaged, trimmed, cosseted in all manner of ways. But on race day they have to run. Very, very fast. And when
they're old and past-in they're sent off to stud, where they can "pass on" their abilities so that the next
generation can go even faster.

Carthorse Management

The converse approach I call the Carthorse Model of Development Management. Carthorses are
(comparatively) big lumbering beasts tasked with pulling big loads on slow carts. They aren't cosseted, groomed,
massaged, and they don't get to eat Marks & Spencers imported New Zealand carrots peeled by albino virgins
with diamond knives. And, worst of all, nobody expects them to get their job done with any speed or grace.

Carthorse managers don't bother too much about the working conditions of their developers. They fuss about a
developer being in the office between the hours and 9 and 5, and yet won't provide these developers with extended
periods protected from interruptions (and that includes meetings!) during their day that would allow them
to actually be productive, as opposed to just being present. They wouldn't dream of offering the developers a
day at home to research a new technology/language, just in case it "might look bad". They don't battle for
better conditions for their developers because they simply don't understand that better conditions will lead to
productivity increases orders-of-magnitude greater than preventing them from having access to the internet just
to stop the occasional email to their friends

I've encountered Carthorse managers many times in my consulting career - in my earlier, salaried career, I
didn't identify them as such; they were just people whose inexplicably arbitrary interference I detested - and
in my experience they fall into two camps. Either they're people who've never been software developers, and
simply don't get it: it's kind of like putting an accountant in charge of a school or hospital (or a software
developer in charge of a football team). Alternatively, they're software developers who, by dint of personality or
immaturity, have poor social skills and are often paranoid about subordinates outshining them. In both cases,
one wonders why they have been put in that position. Like as not, it's a manifestation of the Peter Principle, whereby (usually) smart, talented
people are promoted one step beyond their competence. And once there, there's no going back.

The best thing one can do for such people is to buy them a copies of The Mythical Man-Month and PeopleWare
and cross one's fingers. The best thing for any racehorses that find themselves being
managed in such a way is to find another position, before you find yourself wearing a harness
pulling a big cart!

Wild-Horse Management

Before I (briefly) outline the characteristics of racehorse management, I would observe that there's a third,
accidental, school of development management: Wild-horse Management of Software Development (a term
recently confected). Such teams tend to be subject to ad-hoc management, often under managers that have other
responsibilities. Some may be geographically diverse. Some I've encountered had developed within companies whose
main activities are outside software development; others where the founding software developer has become CEO,
CIO and chief cook and bottle-washer, leaving the team to fend for themselves.

Where
racehorse management (if done well) will tend to produce outstanding results, and carthorse management
will tend to produce very average results, companies utilising wild-horse management may vary wildly in how well
they produce software. I suspect this is due to the differences between potentially highly productive developers
when left to their own devices: some will perform highly in isolation, others may flounder for lack of contact,
intellectual exchange, and recognition/affirmation.

In my personal opinion, wild-horse teams need to evolve - hopefully to racehorse teams - to really achieve. If
you fail to start their evolution in that direction, you may find that they dissipate entirely or, equally
undesirable, someone else in the organisation will force-evolve them into carthorse.

Applying Racehorse Management

So what exactly is Racehorse Management. Well, I'm not sure exactly. Since this is as yet a personal
model, and this is the first time it's been given any kind of write-up, it's more of a case that I know
it when I see it. However, there are some defining characteristics that can be stipulated now:

Motivation Developer performance is valued more highly than automated performance. Sure, a new design
tool might bring productivity increases of 10-100%. But correctly motivating your developers can bring increases
that may be an order of magnitude more significant.

Quality is valued All aspects of software quality - robustness, correctness, discoverability &
transparency, efficiency, expressiveness, flexibility, modularity and portability - are valued. The software
produced by such teams may be said to be beautiful.

Team Spirit is valued Racehorse teams enjoy high levels of team spirit. Note: this doesn't always mean
that they have deep affection for their employer - though they will always have more positive feelings than
negative - but they will have it for their team.

Discussion is valued In racehorse teams, developers have regular debates about technology and practices.
They challenge each other, including their manager(s).

Down-time and research is valued In racehorse teams, developers have time to spend reading on tangential
matters, and doing research.

The managers and team leads are humble Managers and team-leads of racehorse teams are not ignorantly
autocratic. They respect the talents and experience of each team member. By the same token, they are not afraid
to lead in the technical areas in which they are superior.

Work smart Racehorse teams use modern development practices, and automate their work as much as
possible, in order to concentrate on using their very expensive greyware for the things that computers can't do.

Compensation It almost goes without saying that, if developers' productivity is several times higher
than the average, they will be paid substantially more than market rate.

Aptitude is the key Ludicrous notions that old/female/badly-dressed/differently-accented people cannot
write beautiful software find no home in race-horse teams.

Development is respected In racehorse organisations, the development team is not seen as the socially-
inadequate grease-monkeys of the organisation (even when they are socially inadequate). Software development is
respected for the pivotal role it has in the overall success of the organiation.

They shoot horses, don't they!?

All the foregoing might seem relatively obvious for any modern team. However, there's one final aspect that
we've not covered, and which you may be wondering about. It's one that I deem as essential to the model. If a
developer is consistently, and irretrievably, under-performing, you have to be able to expel them from the
organisation. And not with months of "performance management" and all that (mutually) soul-destroying rigmarole.
Of course, this should not be done without consideration or compassion, but it has to be done. Slow race horses win no races, but they still eat hay.

Summary

In summary, I shall defer to far greater experts than I, the authors of PeopleWare, Marco and Lister, who say
(from PeopleWare, of course): "a manager's job is not to make people work, but to make it possible for people
to work".

And for me?

Well, I'm a realist. I know that there are precious few organisations here in Australia with the foresight, the
scale and the finances to create truly world-class teams on the basis outlined in this article (and that
includes the ability to easily get rid of irretrievably underperforming developers). However, if any come
knocking on my door next year wanting to build world-beating software, I'll let you know how it goes.

> But the real challenge: how would one go about finding> such organisations?

I don't know. To be honest, I don't know if they even exist. Even really big and outwardly progressive companies may be less forward-thinking than they might appear. I'm inclined to believe that the smaller the company, the more open-minded, but less open-pursed, they are likely to be. Perhaps it's a catch-22?

> In your experience, are there countries where they tend to> occur more often than others?

I assume that this is more likely to be found in the US and, somewhat less so, in Europe simply due to the size of the populations and the level of advancement of the software development industries. It's not to say that I don't think such companies can exist here in Australia, for instance, just that the scale and capacity suggests a likely lower incidence.

But, hey, if anyone from Mac bank, or Telstra, or any of the other companies with serious requirements and deep pockets are listening, give me a call. :-)

As it happens I am reading "Behind Closed Doors" (http://tinyurl.com/6kv9m9) right now and I think that you'll find it to your liking. It is a book about how to manage software developer teams, written for the engineer turned manager.Adi