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?