The Chief Development Manager was originally published on April 4, 2007.

"Wait a sec," whispered Chris’s coworker David, "he can’t possibly think this will solve the Build Problem? His idea is completely absurd!"

Chris nodded slightly, clearly uncomfortable to be part of a conversation taking place in the middle of a meeting. Especially a meeting being held by the Chief Development Manager. While some managers like to lead by example, and others like to lead by befriending, the Chief Development Manager liked to lead by fear.

"I mean, seriously," David continued, "this will only make the problem much –"

"Oh I’m sorry," the Chief Development Manager barked, callously, "were you guys trying to have a meeting in here? Because, if I was interrupting you two, I can stop. And I’m sure all the fifty-three other developers sitting here have nothing better to do than wait for your little meeting to end."

David and Chris stared blankly, mouths agape.

"Oh. You’re done? Great! Let’s continue, then. That okay with you?"

That was exactly what Chris was trying to avoid. The Chief Development Manager was known to act condescendingly like that. In fact, Chris had witnessed similar outbursts like that in the past. He wasn’t too thrilled to be at the center of one this time around.

I wish it could be said that, deep down inside, the Chief Development Manager was a nice guy and just liked to dish out tough love. But he wasn’t. He was a cantankerous, spiteful little man who wielded a lot of power and used that power to make everyone around him miserable. And his latest idea – the new Build & Deploy Process – was just another step in that direction.

David was right, the new Build & Deploy Process was ridiculous and, with the hundreds of developers spread across four offices around the world, it could never work. But the Chief Development Manager had staked his reputation on it and had sold it to his higher-ups as The Solution to all of their build problems. It didn’t matter what anyone said, they were using his process.

The new plan was to have a fixed build schedule with strict deadlines. If a developer didn’t get his change in by 3PM Tuesday, then that change wasn’t going. No excuses, no exceptions. And to manage all of these changes, there would be a single Excel spreadsheet on a network share drive that each developer would be responsible for updating. They’d have to add a row for every file changed and include its path, the issue number, and the reason behind the change.

To almost no one’s surprise, the first build using this new process was a complete disaster. Most developers spent all of Tuesday fighting over the change spreadsheet, desperately clicking it and cursing the "this file is currently in use by..." dialogs. With all the haphazard updates, the build wouldn’t even compile.

The second build, the third build, the fourth build – all suffered the same problems. 200+ developers trying to a share a single spreadsheet around a hectic build schedule just didn’t work. The Business was getting a bit fed up with the lack of working builds on their test environments and went straight to the Chief Development Manager for an explanation. As you may have guessed, the Chief Development Manager passed the blame right on down to the development managers and even the developers themselves. He expressed concerns that they might even be trying to sabotage his system.

"This is complete bullshit," David complained to Chris, as they sat in another developers cube, "does executive management actually believe that? I’ve put in a helluva lot of hours this year, and this is just going to kill our bonuses! I’m going to say something. This just isn’t right!"

Chris agreed, but cautioned his coworker about raising a stink. Everyone knew that the Chief Development Manager was not one to be messed with. But David ignored Chris’s advice and started gathering a small group of developers. Together, they would set up a meeting about the Build Process, invite executive management, and directly confront the Chief Development Manager. They would not put up with his blame-passing laying down.

As you also may have guessed, the Chief Development Manager covertly told executive management that their attendance at a meeting about the Build Process was a waste of their time, and that he’d distill the results to them later. David and his fellow developers waltzed into the conference room expecting a big confrontation, only to find the Chief Development Manager calmly sitting down, feigning eagerness to listen to their complaints.

Before he even let David finish his first sentence, the Chief Development Manager snapped that the meeting was a complete waste of his time, as well as everyone else’s. He forcefully declared that there was nothing wrong with his system and that he didn’t appreciate lowly developers telling him how to do his job. The meeting was officially adjourned when the Chief Development Manager stormed out of the conference room.

A week later, the Chief Development Manager approached David and each of the other developers from the Build Process meeting and apologized to them.

I’m kidding. He fired them on the spot. As security led them away, one at a time, every developer knew why they were let go and who made it happen.

The next day, the Chief Development Manager sent an email to all developers letting them know that, effective immediately, a third-party build management system will be used to manage changes. A slightly different email went to the executives, informing them that the problems behind the new build process – i.e., the developers he just fired – were now solved.

While this may seem like a rather depressing ending, I will share with you an email that Chris received a few weeks later. It was from David. "Chris, my new job is fantastic. And best of all, there’s no Chief Development Manager."

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!