When a Programmer Holds the Code Hostage: The costs of a policy of appeasement

Article text:

The phrase “no brilliant ass-holes” gets a lot of lip-service around software companies, but the degree to which it is truly believed is only revealed during pivotal moments when a difficult decision has to be made. If you’re lucky, you’ll have avoided such dilemmas for most of your career, but you are unlikely to avoid them forever. Eventually some high-paid troublemaker will be in a position of influence over your team or your company, and you will have to decide how to address the acrimony that they breed. The challenge is exacerbated when the person in question has control of a critical code-base or is an irreplaceable resource: in other words, when they are holding a “hostage”. In such situations, most people — and most companies — will chose to turn a blind eye; they’ll try to put off the inevitable confrontation, hoping it will resolve itself.

The goal of this post is to outline the consequences of not taking action, or of delaying it, by relating one such experience from my own career, at a time when I was leading a multi-platform software team at B2C company. Like with technical debt, the pain of the eventual confrontation was compounded the longer the it was put off, until in this case the entire company ended up being held hostage. My example — one of many — should serve as a warning against what happens when a company tries to appease a hostage-taker.

As a technical lead, my own philosophy has always been to spread code ownership around the team as much as possible, to whichever team members feel they can handle it — regardless of tenure or seniority. This is the approach I was using at the aforementioned B2C company as well, and it was proving effective on all but one of the platforms. In this latter case, a long-tenured developer — who we’ll call “Martin”¹ — had taken full ownership of all architecture decisions and development on the platform, and maintained that control with an iron grip.

When I arrived at the company, the rest of his team were only being given menial or tangential tasks. He never allowed any of them higher-level decision making responsibilities on critical aspects of the code, and this was hindering their technical growth. Martin had also instituted a number of unusual (read: sub-optimal) design decisions, which he continued to defend, and which made understanding the code difficult. Obscurity served as an effective defence mechanism — anyone who wanted more ownership of the code had to go through him. This meant he would know what was happening and either shut it down or find a way to redirect it.

I spotted this toxic pattern fairly quickly, and had hoped to address it, but there was a problem. Despite being an individual contributor and reporting to me, Martin had tremendous clout and influence throughout the company. Not only had he been there since its inception, he was also the only one who could work with the critical platform, and all feature and bug requests had to go through him. To his credit, he was fairly responsive. When bugs showed up, at any hour of the day, he would drop what he was doing and push a fix. This established his credibility and was likely one of the reasons he was given the amount of leeway he had.

During one-on-ones I heard from his co-workers that they, unsurprisingly, didn’t like working with Martin. One or two of the juniors respected his intelligence and influence, but all of them expressed a feeling of living under his shadow, since they were not being given responsibilities that matched their skills. I tried to convince Martin to spread ownership around the team. Though he seemed to agree in principle, he never carried through. He asserted that only he knew how to manage the code-base — which was true, given its inscrutability — and he consistently pushed back on any architectural improvements from other team members that would make the code more accessible.

I’ll admit I was naive at the time. As a young, idealist manager who believed in fully developing my reports’ skills (that’s why I had gone into management in the first place), I didn’t yet realize the political consequences of confronting toxic team members like Martin. The back-and-forth between us escalated over time until it turned into all-out war. HR had to be brought in. The head of my own department — my boss — didn’t want to believe that Martin had to be dealt with quickly, because he didn’t fancy dealing with the technical repercussions of getting on his bad side.

This fear, coupled with Martin’s willingness and ability to address code problems quickly, became the carrot and stick that shifted upper management against my own recommendations. Martin also played dirty. He began to undermine my reputation at every opportunity, complained, gossiped and even lied, and ultimately, through his influence on HR and the execs, he scuttled my career as a lead at that company. By coincidence, around the same time the company lost a large chunk of its business, and so I and the majority of the engineering department were let go anyways. Martin, of course, was retained.

Although I soon moved on to a better position, I continued to keep in touch with former coworkers at the company, including his new manager who was a long-time friend of mine, and so I managed to learn the coda to this story. Martin continued to exercise control over the platform, until eventually the rest of his platform team unilaterally quit, citing Martin’s oppressive tactics as the explicit cause. Now the company was in even more of a bind than before. They couldn’t let Martin go, since he was the only remaining developer on that critical platform. When they tried to hire new team members, Martin — who was expected to be included in the hiring process — sabotaged the interviews, demanding interviewees answer ridiculous questions, and rejecting them based on spurious criteria.

One candidate confronted him on the absurdity of his approach to code design during their interview. Since he had never been forced to accept feedback from anyone on his design choices, it is likely he genuinely believed that his approach was the right one, and so when candidates mentioned best practices that didn’t align with his “expert beginner” philosophies, he rejected them. Either way, the hostage situation was now complete — he had become a bus-factor of 1.

In the end, management’s attempt to appease Martin and get on his good side, driven by fear of him quitting, didn’t soften his hard-line stance — it only validated it. I had originally blamed myself for not finding a better solution to the conflict between him and his team. But now I realized that Martin never wanted to play nice. He was playing a game of power, and didn’t intend to lose or to forget what game he was playing. He cared more about winning than management cared about the long-term success of the engineering department.

Martin also suspected that he wasn’t going to be fired by the weaklings in the upper echelons, including the CEO, so he knew he had all the leverage. When the rest of the team quit, they lost their only opportunity to balance the scales. The more they waited, the harder the decision got, until it was nearly impossible to address, and they had to accept an uneasy truce working under the same roof as the tyrant. The last piece of news I heard about this situation was that the engineering team had been downsized even further, and Martin and his manager were the only two remaining engineers on the product. Martin had won.

I have since seen this same pattern play out in another company as well; it begins with fearful management, unwilling to confront a difficult developer who refuses to collaborate, who doesn’t want to lose power, and so maintains a stranglehold on a critical piece of infrastructure until it is too late. The execs end up having to concede to all his demands. Their short-sightedness mistakenly glorifies and provides justification for a philosophy of appeasement; their desire to procrastinate on a difficult confrontation until some unspecified later time (perhaps when it becomes some other manager’s problem), ends up poisoning the rest of the team who then leave for greener pastures, thus solidifying the hostage-taker’s position. When said hostage-taker amasses enough money and experience to leave — which they undoubtedly will — the company is left up a certain creek without a paddle. But why should they expect such a person to do differently, to show gratitude for all the concessions the company has made over the years, or sympathy for the bind they are leaving the company in?

My guess is, when the time comes for Martin to leave, he will start making increasingly more untenable demands from his superiors, and when the execs inevitably push back, he will use that as moral justification for quitting and leaving them high and dry. Not that the moral justification is even necessary— it would merely be a way of enhancing his own self-perception as the party on the side of right.

How do such hostage situations take root in companies? Why do managers and even execs embark on a strategy of appeasement, sacrificing long-term security for short-term ease? In my estimation, managers hesitate to address such problems because they know they will end up “heroically” putting their career on the line when it seems no one else will. Why help a company that is ready to throw them under the bus for making tough choices? It is a case of the tragedy of the commons. Even if some brave soul tried to address the hostage-taker and managed, kamikaze-like, to take them out, their own job and credibility would likely be ruined with it. So most prefer to juggle the hot potato until they can pass it to the next person, and make it their problem.

Indeed. Makes it more work to filter the handful of good or even great articles from the 99.99% that use this platform for its apparent ease of money grubbing.

What don't you like about medium?

That entirely depends on how well code reviews are managed. I've worked with a "Martin" in the past and we did manage to move to a system where 2+ reviewers were required but it simply got to the point where no one would "rock the boat" because he'd simply brush off every comment made, or call you up to have a long rambling conversation as to why he made the decision he did and how you're wrong and he's right, and given his position in the company you couldn't complain to anyone else about him because he was more valuable to them than you were.

We tried to put more and more blockers in front of him to attempt to encourage him to play nicer, but these were only temporary solutions to the bigger problem of "Martin" himself.

If the code base is arcane enough, code reviews won't matter. You just won't understand at all what is happening there. And the "Martin" will probably pressure you to accept anyway by telling the bosses "I can't work, they won't accept my code reviews".

If your hierarchy is trying to destroy the product you create, just leave. You are not the main stackholder, and do not get benefits from the well-being of your product. The only things that should be importants as and an employee are “is my job interesting” and “are the work conditions great”. If you have to fight your management, they have already lost you because they just broke your trust, as well as the second point.