Home | The business case for hiring a build manager

The business case for hiring a build manager

Posted on Monday, January 4th, 2010 | Filed under build management, development

Lately, I’ve been thinking a lot about the discrepancy between the number of people in my network telling me “we could really use for you to come in and sort out  this mess of ours”, and the number of actual build management jobs/contracts that seem to be actually out there.

In the past, I’ve come across a few cases where the position seemed so hard to recruit for, that a company would simply not bother to advertise the vacancy, and instead rely on either filling the position internally, or have someone referred to them. Over the past year, I’ve come to realize that this is simply not the predominant case.

The real problem seems to be that on the operational level, people understand the value a build manager brings to the table, either intuitively or by experience. On the decision-making level however, while that same understanding may also exist, the challenge is quantifying the benefit to justify the expense. Since

1. a build  manager isn’t always perceived as contributing to the deliverable (software), but
2. is billable (contributing to the client invoice),
3. the cost (i.e. salary) is obvious,
4. there is a generally accepted (at least in the agency/consulting world) non-monetary cost of teams working long days and even weekends as a result of those inefficiencies that would typically be mitigated by hiring a build manager (seeing as how non-trivial overtime compensation is rare, even in cases where the client is getting billed for these hours), and
5. the accountability for hiring a build manager (salary) and the cost of not doing so (project inefficiencies, overages, shrinking margins, etc.) is generally with different people (e.g. management and project management respectively),

decision-makers are generally reluctant to explore the fuzzier benefit side of the equation, because all they see clearly is how much money it will cost in salary, which is all they’re likely to have to explain themselves for.

So let me try and summarize:

• The principal job of a build manager is to automate him/herself out of a job. Predictable builds make for predictable results, which makes setting and meeting deadlines a whole lot easier.
• If you can actually count on X amount of work taking Y amount of time to complete, without the process of moving changes through the various test environments to production becoming a problem in and of itself, you can count on your margins, everyone makes money, and everyone gets to go home and have lives.
• Happy employees don’t quit, so you can count on reduced turnover.
• Since you can count on your timelines better than before, you can now be more aggressive in your estimates, making you more competitive when bidding on projects.
• Better value for money makes for happier customers. Happy customers don’t shop for better deals. Now you can count on losing fewer clients, and having to spend less time and money attracting new ones. Your sales and marketing teams can now actually focus on growing your business, rather than fighting to sustain it.

Now obviously, there is more to it than simply hiring someone marketing themselves for the role, or claiming to have the experience and/or expertise. So you will need to understand what you’re actually going to be expecting your build manager to do for you. Give them too little control, and they’ll be limited in what they can do to help. Give them too much responsibility, and they’ll be stretched too thin, and things start slipping through the cracks. In my experience, in small to medium-sized organizations, your build manager needs to have control and ownership over at least:

1. Your version control environment(s), including but not limited to tool administration, branch/merge processes, standards and best practices.
2. Your automated build / continuous integration environment(s).
3. All Test, QA, UAT, etc. environments; this is critically important: if developers are permitted to manipulate these environments unsupervised, you will lose predictability of your process, which will severely limit and ultimately defeat the purpose of having a build manager in the first place. You do not want your build manager to be reduced to a crisis manager.
4. All builds and deployments to all non-development environments; again, this is critically important: the only way to guarantee that the process works, is to enforce it at all times. If the process is too restrictive, it needs to be adjusted, not circumvented.
5. In the case of web development, and if at all possible: setup and configuration of the production environment. All other environments are ultimately derivatives of this, so it’s ideally where the standard is set.

At this point you may think to yourself: that’s an awful lot of responsibility for one person to carry. And you’d be right, it is. Which is why filling the position with a relatively junior developer, or worse, on a rotating basis, simply will not do. It is just a terrible idea on so many levels. You need someone with the obvious skills to do all of the above, and command the respect and deference of the team. You also need a strong enough personality to stand up to, and deal with any conflict or disagreement that is bound to occur in any high-pressure environment. And you need someone who does not already have an established place in the development team’s pecking order, unless that place is firmly at the top.

A build manager is a gatekeeper and, as a natural consequence, a potential bottleneck in the process. This takes a lot of practice, confidence, patience, humility, and ultimately a bond of mutual respect and trust that can only be forged over time. And last but not least, you need to expect some growing pains.

(to be continued)

Comments

• About

  DGB is the brain child of me, Rob van Oostrum. I am a 14-year industry veteran. Today, I focus primarily on Build Engineering, Release Management and SCM, but I am known to dabble in the occasional Java/J2EE development project.

• Links

  • Rob on LinkedIn
  • Rob on Twitter

• Search

• Admin

  • Log in
  • Wordpress
  • XHTML