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.
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!!
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.
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:
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.
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.
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.
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.
90 Things You Need To Know To Become an Effective CTO