Get the most from Notes®

Several years ago I was working on a new software release for a previous employer when the CTO came into my office asking a favor. He wanted me to let one of the developers on the project implement a feature “his way”. You see, the issue was that he found what he thought was a clever way to implement one of the new features required by the users.

The problem with letting him do things his way was that other developers on the project felt it simply wouldn’t work. More importantly, the business said this solution failed to meet their requirement. The proposed design was pretty cool, but we really needed something that would work AND met the needs of the business.

So why was the CTO so adamant about this? It turned out that this particular developer possessed some unique knowledge because he had been with the company for a very long time and worked on many business critical applications over the years. The CTO was afraid that he might quit if he didn’t get his way on this new project.

I couldn’t believe what I was hearing. Essentially, the CTO wanted to let the project fail in order to retain this guy. Incredible!

I spent a lot of time working with the VP of Development to find a way around this with no real solution in sight. As it turned out, the guy quit within a week. Whew! That was a close call.

In telling this story since then, I’ve come to realize that my experience is not unique. Projects are often held hostage by a key member of the team. So what can you do to prevent your project from turning into a complete disaster when it is being held captive?

There are a few things you can do, but it is important to recognize that losing those sorts of people doesn’t usually end up being as painful as you think it’s going to be.

Following is a short list of suggestions:

• NEVER allow individuals to hold projects hostage to their expertise, experience or knowledge. It is a rare project that ends in success when this happens.
• If a hostage situation occurs, remove the problem immediately. Project delays and challenges will only increase until the problem is addressed. It’s better to make this change on your terms instead of theirs.
• Contact the business immediately to let them know what happened. There may be a delay in the project because of it, but do your best to minimize any negative impact this might have on the schedule.
• Recognize (to the team and yourself) that removal of a key resource may slow a project down at first, but a well managed team will recover quickly and produce a much better result in the long run.

I’d love to hear your ideas on this. Have you been in a similar situation? If so, what did you learn that might be helpful to others who find themselves in a similar situation?