So you just became a build manager, now what?
Posted on Tuesday, January 5th, 2010 | Filed under build management, development, project management
(continued from here)
First and foremost, an organization’s choice to make build management a priority is a strategic one. So the role has to be filled by someone who can think and operate at that level, as well as get their hands dirty and do the work on a tactical level. It’s a careful balance of big picture vs. “stuff needs to get done today”. No matter how good you are, you’re not going to be able to do it all at once, all of the time, so planning and managing your time is critical, especially if you’re juggling a lot of different projects at once.
These are some of the key lessons I learned along the way.
Not too much, not too fast
Give yourself time to get your bearings and make sure you really understand the environment you’re in. Depending on experience and the complexity of the situation, this can take days or even weeks.
Once you feel ready to dive in, limit yourself to one project, or account, or application, and find something you can do in no more than a day, something that isn’t going to start a domino effect you won’t be able to control. The key concept here is bite-size. Whenever you notice something that just doesn’t look or feel right, but it’s too big or tangled up to tackle right then & there, take notes. When you run out of things to fix, go back to your list and find something new to sink your teeth into. Make a habit of this. It’s a great way to stay fresh and productive once you have everything working just right and things just run along smoothly. The worst thing you can ever do is nothing. Slow is smooth, smooth is fast.
Change is hard
Humans are creatures of habit. Most people aren’t wired for rapidly changing, dynamic environments. And most people that do will generally prefer a solid foundation of routine for balance. The decision to start investing in build management can only mean that there’s going to be some changes, and they can fundamentally affect the way people do their jobs, and how and to what extent they’re going to be held personally accountable for the quality of their work. I find that the trick is to just start changing small, seemingly innocuous things, and pretty soon teams are used to the new routine of continuous improvement. The secret to making this work is to not screw up. If you are occasionally human and stumble, eat your humble pie, fix what you broke and make sure you don’t make the same mistake twice. You’ll be surprised at how much you can get away with if you follow these simple steps.
If you can script it, you shouldn’t be doing it
Nothing destroys the reliability of any process faster than having it be manual. People make mistakes, to expect them not to is fundamentally unfair. If your process is going to be predictable, repeatable, reliable, and fast, it simply has to be automated. It’s also the only way you’re going to be able to implement continuous integration, continuous deployment, continuous anything.
If you can’t script it, you’re not doing it right
See above. I can’t stress enough how important this is.
If it breaks once, something automated should catch it if it happens again
There’s an old Dutch saying that roughly translates to: “even a donkey generally doesn’t knock into the same rock twice.” There are few things that will ruin my day faster than running into the same problem twice. Proponents of test-driven development will be familiar with the concept: if something breaks, write a test that catches it, fix the problem, and now your test passes. If the problem ever regresses, the test should fail again, and you catch it before it gets any further.
In production environments, operational issues should be caught and reported on by monitoring tools such as Nagios. Again, if it happens once, find out how it could and should have been caught sooner, and put the necessary controls in place.
It probably wasn’t your fault, but it is your problem to fix
Being the bottleneck means everything the team does crosses your desk at some point. Generally the only other person on the project who touches everything is the project manager, but he or she is most likely not nearly as technical as you, and won’t be able to zero in on the root cause nearly as fast as you can. Make a habit of not passing the buck. The faster everyone gets to the bottom of what went wrong, the faster everything gets back to normal.
This puts you in a position to drive root cause analysis in a way that helps prevent future problems, especially those of a human/organizational nature. I like this piece on a concept called “Five Whys” a lot. It’s simple and elegant. If you’re not using this, you should be using something very much like this.
Comments
2 Responses to “So you just became a build manager, now what?”
Leave a Reply
RT @rvanoo: So you just became a build manager, now what? http://bit.ly/92sQR6
RT @rvanoo: So you just became a build manager, now what? http://bit.ly/92sQR6