Managing Developers: Preventing Over-Reliance and Blackmailing

OK, we’re not talking about the criminal form of blackmail here – though that would be an interesting blog post. What we’re talking about is when a business becomes over-reliant on one or two key developers and they become aware of it, it can lead to a form of ‘developer blackmail‘ that makes managing team dynamics extremely difficult.

With deployment, methodology, programming style, UI colours and even the brand of coffee in the kitchen, they can take advantage of that reliance to become an overbearing voice of opinion.

Whilst they might be brilliant at programming and short-term solutions, that omnipresence can develop into a significant risk. It can negatively impact team functionality, harmony and psychological safety.

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

No great surprise that when I wanted to make that change, I started receiving serious pushback and simply couldn’t move them. And they were very well aware of it.

My managerial inexperience allowed this situation to become toxic and impact many other areas of the business, not to mention the sleepless nights in working out how to find a resolution.

This issue is not limited to smaller teams only

I experienced a team of 30+ where every six months, two developers would ask for a pay rise that senior managers were afraid to refuse.

You might simply call it market forces at play, but when building a team, it creates significant discontent.

On a bigger team of 100, I saw one DBA wielding absolute power over the database and an architect who designed a ridiculously complicated framework that caused extra (completely unnecessary) work for the team whilst, at the same, time reduced productivity.

Another recipe for much unhappiness!!

Mentoring viewpoint

We saw this problem within our coaching assignments here at CTO Academy. Commonly, the root cause of issues today can be traced back to one or two individuals.

Let me just point out that not all individuals in these situations are intent on being malicious. However, too much knowledge in too few hands brings a clear risk to the business of abuse and/or flight.

Risk Mitigation – Steps and Best Practices

Let me address potential solutions in two ways.

First, how to reduce the risk?

Second, how do you prevent it from happening again or at all?

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

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

Much as I’d like to think I’m irreplaceable, everyone ultimately is and, more importantly, absolutely needs to be “replaceable”.

Therefore, to isolate points of weakness, you must analyse these three areas:

1. Knowledge. Is there knowledge in the developer’s head that no one else knows or would take them a long time to find and understand?
2. Productivity. Are they significantly more productive than other team members and thus would slow down the roadmap?
3. Deployment and Customer Facing. Are they the person who 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.

Key steps in mitigating the risk associated with ‘developer blackmail’

• Automate as much as possible. This has two effects:
  • Removes reliance on an individual’s knowledge.
  • 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. Instead, focus on these three areas:
  • Disaster recovery plan. Put together a plan to recover from a disaster in 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. This will standardise the code and thus make it difficult to identify who authored what. Standard practice and layout make 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 there are not enough people, then look for the budget to hire people to double up starting with the high-risk areas first.

Additional proven practices in managing developers

Get Buy-In From Your Team

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

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

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

To prevent this from happening:

A) ensure the implementation of quality processes right from the start, and

B) automate as much as possible (eg, code analysis and deployments).

This applies to all business sizes, from start-ups to international corporations.

Know What is Right for You and Your Team

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

I’ve had to replace entire teams on two occasions because 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. Now, while compromise is important, if you know something is not right, then remain resolute and enforce what’s best for the business. In other words, don’t allow individuals to effectively try to blackmail the organisation.

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

CTO Academy – Discounted Offer

Now, I won’t lie to you; this can all be pretty overwhelming. So if you’re struggling with this or any other managerial dilemma, then consider joining CTO Academy. As a member, you can tap into our wide range of leadership resources and global community of senior technology leaders at any time.

And just for reading this article, we are giving you 20% off of our annual Membership package subscription.

Find out more here and if/when ready to sign up, use the checkout coupon my20%reward to take advantage of that discount.

Hope to see you soon.