Build Masters

Build Masters (also known as librarians) are a key resource on any software development project. The key deliverable for any software development project is the system or application under development, but that system or application is built from the software in the source library so I would argue that the items in that library are the key deliverables for the project. The system or application can be re-built from the library if anything goes wrong but you can’t rebuild the library from the system or application. The source library is under the care and control of your build master or librarian which makes them a key resource for your project.

Mature organizations that already support software systems will have an operational person in that role, but that doesn’t necessarily mean that they will be available to your project. Organizations that are venturing into the world of software development and support for the first time won’t have this person in place which means the project manager must seek the right candidate out and groom them for the role.

The reasons for choosing a build master already in place to take that role on your project are obvious but it won’t hurt to articulate them here. The build master has experience in the tool suite available for managing the source library and performing builds, they are familiar with the standards, guidelines, processes, and procedures your organization has adopted to lend discipline to the activity, and they are familiar with the organization both on a personal basis and a political basis. For all these reasons you want this person on your project if at all possible. Whether or not you get the person on your project will depend on the perceived importance of your project in relation to any other projects your organization is performing and the operational activities that constitute the build master’s "day job”. The decision on the disposition of the organization’s build master will rest with someone outside your project, probably with the head of the IT organization. Your job is to state the importance of your project using the business case and communicate the importance of a good build master to the success of the project. There is one other bargaining chip you have in this negotiation: someone on the project team who would be an acceptable replacement for the build master.

If you are unsuccessful in engaging the resident build master/librarian, or your organization doesn’t already have one, you’ll have to identify someone who is a fit for the job and groom them for your project. Grooming the build master in the requirements of your project is actually a job you’ll have to take on in any case; familiarity with the function on other projects, or the operational environment doesn’t mean the resident build master won’t need training in the unique requirements of your project. Let’s assume you can’t have the organizational build master and examine the criteria you should use to choose a good candidate.

I would argue that the most important criterion for your build master is not a technical one. It is that the person has the ability to assert themselves and hold developers to the standards set for them in terms of use of the source library, testing standards, etc. This ability is critical and without it your development environment will turn into the Wild West where the most forceful personalities impose their will on the build master and other developers. Regardless of whether you identify someone for the role who is an existing team member, a member of the organization, or have to engage someone externally, look for this ability. The best way to ensure your candidate has it is to seek evidence of it in past roles. Those roles don’t necessarily have to be as build master but should be in some leadership role. Lead developer, code review moderator, design review moderator, and database administrator are a few examples of roles where an ability to be assertive can be demonstrated. Have your candidate describe situations where they have demonstrated their ability to be assertive when interviewing them.

Experience with the role of build master will be important if you’re engaging a person who is external to your organization. Look for someone who not only has experience with the same tool set as your project, but also has experience with the size of project you’re managing, the standards, guidelines, processes, and procedures your project uses, and with your type of organization.

Your build master should have the ability to remain calm under pressure because build master is a role where lots of pressure will be felt. Experience is the great teacher in this area so once again, you need to look for roles which allow the candidate to demonstrate that experience and then have them describe instances where they have demonstrated it during your interview.

When engaging someone from within the organization, look for someone with experience with the tools your organization will use for your project. These tools will include source library tools, compilers, continuous integration tools, test tools, and relational databases. This experience can be gained as a developer in an environment that used the tool set your project will use. Also look for a demonstrated ability to install new software in test and production environments, which are important components of the build master role.

You will have to train a person who is new to the build master role, no matter how much experience they have with the tools, rules, and being assertive. This is where your negotiation abilities will come into play. The best person to provide the type of training your new build master needs is the organizational build master. Look to engage your project build master early on in the project and have them shadow the organizational build master as they do their work. This coaching should also bring to light any deficiencies in your new build master’s skill set you did not foresee. Meet with the organizational build master after the first build and deployment of an operational system, or system from another project, to evaluate your project build master’s abilities. Develop a training roadmap to make up any deficiencies identified.

Once you’ve selected and trained your build master, seek and accept their input into the definition of the processes and procedures that your project will use to build the system. Their input will be especially helpful in the area of code freezes, test data, ready to build criteria, etc. Your build master will have to implement and enforce the processes and procedures that are defined for your project so they should be comfortable with them. This is especially true when processes and procedures must be executed iteratively which is the case for just about any Software Development methodology other than Waterfall.