Retrain Your Code Czar

© 1999 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Many software organizations have two classes of technical staff: normal employees and royalty. The royalty-those kings, queens, and czars of software development-initiate central controlling project roles. They see a dire project need and act on it, though no one asked them to.

Royalty believe they provide unique project and product skills for the organization. They may, but, in my experience, their controlling actions prevent the project and the team from developing products and cohesive processes.

When one team member takes on the royalty role, it prevents the rest of the group from learning what she already knows. The team becomes fragmented and can't work together; the problems that created the royalty become even worse. Royalty delay projects because they interrupt the normal development loop of creating the product, testing it, fixing it, integrating it, and getting feedback. The royalty must stay in their chosen role, because the participants eventually come to believe that the project cannot make any progress without them.

FOR EXAMPLE

I recently worked with a code czar. His official job responsibilities were to

develop and unit-test a specific part of the code base,
check in all the code, and
build the system on a periodic basis.

In addition, the czar had several self-appointed responsibilities:

Review the code and make sure he liked the style and variable names. This created project delays because the other developers couldn't continue to write code or even design. They had to wait for all the sets of changes to be checked back into the source file before checking the code out again for development. Then, the developers were not always able to recognize their own code, because the czar had changed it.
Decide which components got checked in when. The czar spent time performing merges, further delaying the project. He found mistakes and fixed them, without explaining the problem to the original author, so the developers did not learn from their mistakes. They repeatedly made the same or similar mistakes and defects were reintroduced.
Wait to create builds until he thought the testers were ready. Since any build was missing at least one component, the developers could not easily test their software with others' changes. Most of the developers stopped trying to do proactive testing and waited until the czar created the build to test their work, delaying the testers even more.

The czar's actions slowed development and created rifts in the team, thereby delaying the project's progress. While no one liked these project consequences, not even the czar, he was concerned that the potential code problems would be worse than the current project problems if he relinquished some of his controls.

The project was under time pressure. As the project manager, I asked the czar why he insisted on working this way.

"Well, I want to be in the middle of everything that goes on here. I want to be able to say when and what we ship. I want to be able to stop shipment, because we don't always know what we're shipping, and I want to make sure that any product with my name on it is something I'm proud of."

I agreed with him about producing a product to be proud of; I just disagreed with his methods. I manage projects by defining release criteria (J. Rothman, "Of Crazy Numbers and Release Criteria," Computer, Dec. 1998, pp. 127-128) and working towards those criteria. I explained my position and asked what he wanted to do.

"I want to keep doing what I'm doing."

He was delaying the project, but he said he didn't care-he didn't trust anyone else to do his jobs correctly and wanted to continue working as he had been.
The czar was capable of being a major contributor to the project and the organization, but the way he contributed undermined his co-workers' self-confidence and productivity. As project manager, I clearly needed to change the situation.

First, we argued about it. He threatened to quit; I threatened to accept his resignation. Following Weinberg's advice (G. Weinberg, Psychology of Computer Programming, Silver Anniversary ed., Dorset House, New York, 1998.), I was ready to get rid of my "indispensable" czar. He stormed out. I went to see the project architect, and asked how badly it would affect the project if we lost our czar. The architect's face looked grim when he explained that the czar had the only complete copy of the code at his house. I blanched. Time for another solution.

I decided to reassess the problem and possible solutions with a problem statement:

The czar is delaying our project.

I write problem statements when I'm working on something and I want to make sure I've considered the whole problem. However, my statement was too simplistic. Though some of the czar's actions were delaying the project, he did provide valuable services. To really define the problem, I had to be specific about what was slow, what activities the czar performed, and how he performed those activities. I decided to rewrite the problem statement:

The czar is providing specific services to the project that we need: merges, check-ins into the configuration management system, and code review. It is the way he provides these services that delays the project. We want to keep these services, whether or not he provides them, and make the project go faster.

This new problem statement acknowledged his contributions and specified my goal to speed up the project. I asked the czar again to help solve the problems. He resisted and I finally told him that I didn't care if he remained on the project-he could quit. If he was going to remain on the project, we had to talk about these problems and how to resolve them. He did want to remain on the project, so over the course of several conversations, we came up with these problems and potential solutions:

The current version of the source code was at the czar's house. The project team was delayed by lack of access to the source code. We decided to buy another commercial CMS, put it on everyone's desktop, and train the staff to use it so we could maintain the source in the office. The czar helped migrate the source into the new system. Each developer is now responsible for checking out the correct version of the code and testing it before checking it back in.
Some of the code was well-written and some was bad, but all the developers needed feedback on their code writing and exposure to the rest of the code base. We decided to schedule code walkthroughs that had two effects. We showed the entire organization how good code was written and we helped the entire team learn the product.
The czar's components were behind schedule. We agreed that I would recognize the czar for doing only his development job and not the secondary, royalty responsibilities. I would impose the same penalties on the czar as the rest of the team when he didn't deliver product components on time.
We needed to make objective ship decisions that everyone could understand, and we needed a team-based assessment mechanism, instead of trusting one individual to make all the decisions. On previous projects, the team shipped because it had a target date, without assessing the project's progress. We instituted objective release criteria and monitored them weekly. I then checked in with the czar periodically to ensure that he understood and was satisfied with the team's decisions.

By openly addressing these problems, we solved a variety of project and people issues. Buying a public CMS tool eased a few of the people problems, such as resentment toward the czar for his attitude and behavior. Public code walkthroughs gave all the developers a chance to see how other people's code looked. That gave the team members incentive to review their code before the walkthrough and see where they should improve it. The czar had to work hard to bring his components in on time, but we used his actions as a model for others. With objective release criteria, we had much less opportunity to blame each other for incomplete project pieces. We worked as a team to identify problems and come up with solutions.

WHY ROYALTY?

Projects have royalty for a reason, maybe several. Royalty are generally dedicated and talented employees. One common royalty scenario occurs when a technical founder creates a product and continues as a technical contributor on a future product release. The founder is used to making the decisions, not working with others. The founder may not understand how difficult he is to work with as royalty.

When you move people from royalty positions to normal staff roles, you need to find alternative ways to reward them. Previously, they were rewarded with the respect and responsibility of the royalty role. Your royalty need to be retrained to accept rewards as part of a team.

If you have royalty on your project, investigate the functions they perform. Decide whether those functions are required in your project and how else they could be provided. The czar on my project required a lot of time and energy to convert to a contributing team member, but not every czar requires this investment from a project manager. As a manager, you must involve your royalty in the decision-making process; otherwise, they might attempt to sabotage your efforts.

RETRAIN YOUR ROYALTY

You can retrain your royalty. My first, direct approach wasn't successful because the czar saw it as a personal attack. I needed to consider the reasons for his actions. After restating the problem statement, I took a more subtle approach. I worked indirectly with the project team to change our processes, and I addressed how participants were recognized for their work. I continued to recognize positive and successful project work from the czar, as I did with other project participants.

ACKNOWLEDGMENTS

I thank Don Gray, Karen Mackey, Steve Smith, and Jerry Weinberg for their valuable contributions to this article.

Johanna Rothman observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.

What can we do for you? Go to: Writings and Presentations, Chronological Listing

Retrain Your Code Czar

FOR EXAMPLE

WHY ROYALTY?

RETRAIN YOUR ROYALTY

ACKNOWLEDGMENTS

ROTHMAN CONSULTING GROUP, INC. Johanna Rothman, President

ROTHMAN CONSULTING GROUP, INC.
Johanna Rothman, President