When people ask me what my job is, it is often hard to describe, even if they are in IT.

“Wait!”, I hear you say. “Didn’t that last post say you were a build manager????”. Sure it did, but that is oversimplifying it, I guess. That is what I want the focus of my role to be. But it is a little more complicated than that.

What makes my role so hard to describe to people is that it cuts across a range of different areas. You can often find people including these areas under titles such as “Configuration Management”, “Build Management” and “Release Management”.

If you break these areas down a little further, you generally get something that looks a little like this:

  • Build Management – Deals with making sure the build happens, and that developers have the tools and procedures they need to get software ready to test. Generally the more technical of the three areas, as typically you will need to know at least as much regarding software build processes as the developers you are working with. There is also usually a fair bit of scope for tool use and development, particularly in the Microsoft world.
  • Configuration Management – In the software development world, deals more with the provision and management of a Version Control System (think Subversion, CVS, SourceSafe etc). For those who work in small teams that keep a backup copy of their lifes work on a shared drive, you need one of these people. You will also find a horde of specialists like this clustered around ClearCase installations. Of course, on bigger Open Source teams developers will just use something like Subversion or Git, and get on with their job (not so fashionable in big business, as Open Source is inherently evil, right?).
  • Release Management – Depending on the environment this role can either be bad, or hell. Generally more an administrative nightmare, particularly in investment banks. Essentially you have to take half-baked, untested software from developers responding to irrational project deadlines imposed by managers, and convince a release management team (usually highly suspicious of anything coming out of development, for good reason) that the software really, really needs to go out, and no, its not going to break the network like last time. Oh, and yes, you have all fifty signatures in triplicate, including the janitors. Release management can also involve ensuring software is available to test for internal or external testing teams, which is usually the only simple, rewarding part of the role.

So which title best describes the roles I generally fill? It really depends on the team you are working within. I have worked in teams where the primary role is policing developers, ensuring software merging and branching is done correctly, and generally playing bad cop. I have also worked in teams where the focus has been generating tools and build technology to streamline development and release, supplying toolsets rather than enforcing them. Much more good cop. Much more fun!

I guess the best way to look at it is the ratio between Build/Configuration/Release management. Personally, I prefer a 50/30/20 ratio, but thats me. Masochist pedants tend to prefer dealing with the release portion of the workload. To be honest, after a few years in Investment Banking I would prefer forcing red-hot needles under my nails than work predominantly with software release oligarchies. Anyone who has also worked (past tense, there are more of those now!) in Investment Banking probably knows what I mean!

Anyway, I am going to keep calling myself a Build Manager, in the hope that I get to do more of the fun stuff!