The Case For Better Management

by Krishna on March 8, 2010

Stephen Forte makes what he thinks is a case against having "rock-star" developers in a team. You can read the post, but, in short, there was a programmer “John” on his team who picked coding arguments with the rest of the team. The final straw was that John burnt the whole team by directly moving his changes to production without going through the QA process and bringing down the site.

Stephen’s example is not very strong. A great programmer, by definition, should be someone who also understands and advocates good build and deployment practices. John was not such a person. It is also quite possible that a lower-grade programmer could have made the same error if they were under pressure from some management big-shot. You have to blame the incentives here.

In any case, these kind of train wrecks are easily preventable. An analogous example is locking the door if you are in the bathroom. Yes, people should knock before they try to enter it. But you cannot force everyone to follow such “best practices”, especially what is foremost in their mind is not the prospect of causing embarrassment to another person. Instead, what you can do is prevent someone from causing damage if it is really important to you.

So with respect to production servers, the simplest solution is to lock down access and grant it only to people who have a stake in following the process. This small group usually includes the system administrator responsible for the box, the project manager (or team leader, as the case may be) and the QA manager. All others, especially programmers, are more motivated to say that the work is done than to prevent any damage because of a mistake.

I am actually not in favor of providing access to the lead programmer, either, even if they are very experienced. The path should go through QA, who test the build or patch on a Test server that is as similar to the production server in terms of capability, environment and data as possible. One QA person is in charge of delivery and they sign off on releasing the build.

In a smaller organization, there will some overlap between roles, but do ensure that the person in charge of QA has the responsibility and sole authority for releasing code to production. That person should be independent of any influence by managers to speed up delivery of projects before adequate testing is done.

The other step is to be absolutely uncompromising about crossing management lines. There has to be one person (whatever the title) who has the authority and responsibility for accepting tasks for the development team. I am using those 2 keywords again, but what it means that only one person can accept a new task from someone outside the team, and once they accept it, they are fully responsible for it. This person maintains the backlog and if any manager wants to circumvent the hierarchy and talk directly to a developer, they will own it including breaking the schedule of other managers, crashing the servers and so on. And also, perhaps most important to them, that the task would be dropped without notice once the backlog manager learns about it.

Now, Stephen defines a rock star developer as “someone who, while talented, thinks that they are the ultimate guru and that everything should be done their way.” As I see it, you have hired a manager when all you needed was a programmer who can follow instructions. There was already a manager (you!) on the team. John doesn’t belong. His personality is such that he should be leading the team and swimming or sinking with the decisions he makes. But he probably doesn’t have the necessary resume to land that role in any company yet. In the meantime, he is a nightmare on the team because he tries to manage his peers. That is the real problem.

The difficulty in avoiding such hires is that during the hiring process, the rock star developer is sometimes indistinguishable from the talented, easy-going developer. Both are bursting with energy and ideas, some of which are actually pretty good too. You only learn the full extent of their behavior after a few weeks. The easy-going developer is comfortable with accepting authority and there is a give-and-take with respect to ideas. The rock star developer doesn’t understand why compromises are sometimes necessary and is quick to condemn differences in opinion as stupidity or evil. We all do the same to some extent, but the rock star developer’s condition is almost pathological.

The obvious route is to let the developer go, but if you don’t have a choice (in the short term), then one way to handle them is to divert them into tasks that require heavy lifting in research and development. They are now isolated from the rest of the team and the day-to-day grind, but they are kept extremely busy because they have to deliver something that works. This is something that I suspect rock star developers like, because they get to play the full court from analysis to recommendation. However, ensure that you have set the right parameters for accepting the outcome of the research so that you don’t get a recommendation that you will be forced to reject, thus exacerbating the problem.

Comments on this entry are closed.

Previous post:

Next post: