There is a strange phenomenon that often times the person perceived as the most valuable in a software group may be the one that needs fired the most. I´ve seen it more than once and this fictionalized conversation gives a sense for it.
Consultant: "Who would you say your most valuable employee is?"
Manager: "Without a doubt that would be Mark. He´s in charge of our billing analytics system. We brought in {big name consulting company} to develop it two years ago and Mark was our in-house expert. We have an in house team that works on it now and Mark heads that team."
Consultant: "I see that version 1.6 of the billing analytics system was canceled and version 1.7 is way behind schedule. It also looks like the bug closure rates are much lower than any of your other projects. What´s going on?"
Manager: "We´ve had a rash of bugs ever since the first release. {Big name consulting company} left us in bad shape and we´ve had to be continuously fighting fires since then. It´s really hard for that team to make much progress. What we need are a lot more resources."
Consultant: "The team already has 10 programmers. That´s about twice as large as any of your other teams."
Manager: "It´s a lot bigger project."
Consultant: "What would happen if Mark left the company?"
Manager: "Frankly, we´d be in a lot of trouble. Mark is the only one who knows that code and it would take a long time to get someone else up to speed."
Consultant: "What about the other people on that team?"
Manager: "Sue is probably the next most knowledgeable. She gets most of the bugs fixed outside of the core analytics engine, but I´ve asked her and she says she hasn´t the slightest idea how the analytics works. Right now Mark is the only one who knows that stuff which means he ends up being the bottleneck on a lot of issues. That was one of the reason we canceled the 1.6 release."
That´s enough to give you the picture. It´s a very common situation. There isn´t enough data to tell what the core problem is for sure. It´s possible that the code is really, really bad and Mark is bailing as fast as he can but the boat is sinking. It´s possible that it actually is just badly understaffed. What is certain, though, is that Mark is in over his head and he isn´t doing anything to change that (or can't). This is certain because two years is a lot of time and Mark has ten people that work with him but none that can help him. Things have gone horribly wrong.
Now, Mark may just not know how to change things. He may be the kind of person that always does the urgent before the important (like most people), and he may simply be unaware of how to get himself out of what he´s gotten himself in to. Regardless of which one of these it is though, Mark needs to be "fired" from this project. By this I mean that someone else must be brought in who can think outside of the box, who can look for refactoring opportunities, and who will get other people involved. Alternatively, Mark can be encouraged to do these same things, he can be his own replacement, but that almost never works.
The manager has looked out at Mark and seen a drowning man and said, "Wow, he´s really working hard. Look at all that splashing; he must be a great swimmer." The manager has also mistaken the importance of Mark´s project for the importance of Mark. Since Mark is the bottleneck of the most important project for the company Mark is the most important person at the company. In this case the person who needs fired is not Mark, but the manager.
This is really a situation where we can apply the well know definition of insanity: "doing the same thing over and over again and expecting a different result." Mark and his manager need to make fixing the core problem more urgent than fixing the problem of the day, and if they can´t find a way to do that then they need to ask for help from the outside. Maybe Sue can take three weeks and identify as many refactoring elements as possible in the code, maybe someone from another team or from outside the company can be brought in, but something needs done.
As a final note, it may also be possible that Mark is actually a truly bad engineer and I mean it in both a technical and moral sense. I have more than once encountered a Mark who has literally put himself in this position on purpose (and admits it). This "evil" Mark is the one who has made himself the most critical person by virtue of having the worst code in the most important spot (on purpose). If you´ve never seen this, be glad. It´s a truly ugly sight and that person does need fired.
| 
