Ever been blackmailed by a developer?

OK, we’re not talking here about the criminal form of blackmail – though that would be an interesting story to hear about.

What we’re talking about, is when a business becomes over reliant on one or two key developers and trouble ensues …

If you’ve ever been a CTO or senior technical manager, then you might have experienced a form of ‘developer blackmail’ whereby a company finds itself over reliant on one or two developers, and they take full advantage.

With deployment, methodology, programming style, UI colours, even the brand of coffee in the kitchen, they will have a strong and dominant opinion.

Whilst they might be brilliant at programming and providing short term solutions, over reliance on key individuals can become a long term risk.

Early in my career, I started a project, hired a good developer and soon became reliant on him. I saw the danger emerging so tried to protect my risk by attempting to change their contract termination period.

No great surprise then when I wanted to change I received some serious pushback and simply couldn’t move them on, and they knew it. Because of my inexperience, it took some time and the occasional sleepless night to resolve.

Not Just For Small Teams

This is not exclusive to small teams.

I’ve seen a team of 30 where every six months, two developers would ask for a pay rise and senior managers were too afraid to refuse their request. I guess you can call it market forces but, when building a team, it creates significant discontent and risk.

On a bigger team of 100, there was a DBA who wielded absolute power over the database and an architect who designed a ridiculously complicated framework, that caused extra unnecessary work for the remainder of the team, whilst significantly reducing productivity. Not a recipe for much happiness!!

You can find some more amusing anecdotes can be found at https://thedailywtf.com/.

Mentoring Viewpoint

We often see this problem when stepping into help mentoring some of our clients, where the root cause of their issues today, can be traced back to one or two individuals.

That is not to say that in all such scenarios the individuals are incompetent or in anyway malicious but clearly, as with most roles within a company, over reliance leads to significant risk.

Mitigation of Risk

Let’s deal with this in two ways ….

First, how to reduce the risk?

Second, how to prevent it happening again or in the first place?

In an early business where I was the critical developer, we analysed the risk of what would happen if that proverbial bus ran me over (probably being driven by one of my business partners at the time!).

We highlighted what we would need to happen in the first 24 hours, month and longer term.

Much as I’d like to think I’m irreplaceable (Ed: he’s not), everyone is and needs to be replaceable.

Any similar process within your team needs to isolate points of weakness with three main areas to be identified;

Knowledge: is there knowledge in the developers head that no-one else knows or would take them a long time to find and understand?

Productivity : are they significantly more productive than other team members and thus would slow down the roadmap?

Deployment and Customer facing: are they the person that does the deployment and/or set up the customer facing systems?

If you’re in the middle of this dilemma then there is no magic bullet for an overnight solution but, there are steps you can take to start mitigating the risks;

Automate as much as possible – this has two effects
a. removes reliance on an individual’s knowledge
b. places the knowledge within the process and system

Improve your important documentation. This should not be dry design documentation as no one ever reads it, but 3 areas should be addressed;

Disaster recovery plan : put a plan together to recover from a disaster of your live systems. This could mean restoring a new installation in a new data centre and restoring backups.
Architectural Diagrams : high level diagrams of how components interact allow someone to get up to speed very quickly
Comment Code : no need to go overboard but make sure there is adequate documentation on key algorithms. Code analysis tools can provide some feedback.

Implement code quality metrics to standardise the code so that it is difficult to identify who authored what. Standard practice and layout makes it much easier to understand code particularly when new to it.

Spread the load/responsibility across the team. If you have enough people, you may be surprised who steps up to the challenge. If not enough people, then look for budget to hire people to double up starting with the high risk areas first.

Get Buy-In From Your Team

If you’re running an existing team, then the team should buy into these changes as it will make their lives easier allowing them to concentrate on the more “fun” stuff of actual development.

If members are opposed, then by natural attrition they will likely move on but for the more entrenched you may have to help them move.

Be aware that you may have to account for extra costs in the short term, such as recruitment fees, a short term loss of productivity and upheaval within the team.

To prevent this problem from happening in the first place, make sure that you implement good processes at the start and automate as much as possible, such as code analysis and deployments. This applies whether you are a start up to a big international corporate.

Know What Is Right For You & Your Team

Many people do not like change so be prepared to stand up to your convictions and impose your authority.

I’ve twice had to replace entire teams as they were so entrenched. Both times caused significant upheaval but, productivity increased and the respective companies were free to expand.

On other occasions, I have had to deal with more confrontational situations and whilst compromise is important, if you know something is not right then remain resolute for what is best for the business, and not allow individuals to effectively try to blackmail the organisation.

Put steps in place to avoid over reliance but if you find yourself inheriting this problem, apply a strategy for negotiating the roadblock and be aware that it might not be easy and could take many months to implement but when it’s done, the transformation could be remarkable and you’re more likely to have the backing of your team and the wider business.