John — or Being Held Hostage by Your Early Days Tech Lead
Part one of a series about the real complexity in Software Development: People.
If you’ve been in software development for 30 years, like me, you get a pretty good view on what’s needed to build great software.
I think I can say that I’m aware of a lot of best practices in SaaS software development, especially on Native Cloud.
It can all be pretty complex. As I said in another article, software development is a complex beast.
Now, if we rip the beast apart, and look at what those complexities actually are, it turns out a lot of the technical stuff might be complex, but at least, with a bit of investigation and determination, most of the time, you will get past what’s blocking you.
It’s all quite logical, and as soon as you understand the logic, it all just resolves and next time this same thing will be a piece of cake.
But let’s face it, until AI takes over, software is created by humans, and, even at minimal scale, there will be more than one of them teaming up.
And this is where it really becomes challenging.
Logical isn’t the same thing when it comes to human dynamics!
The reactions under one of my recent posts on LinkedIn triggered me to write a couple of things down that have to do with the human dynamics of building software.
The Story of John
Being held hostage by a Startup Lead Developer
Fractional CTOs are in the unique position to be able to compare startups in terms of people, products and processes.
In this story, the fictitious name ‘John’ is in fact referring to a number of similar Lead Developers, who have worked for ‘their’ startup since day one.
The Johns have typically built their first product, and have done so in a very individualistic way, since there was no budget to create a larger team, and since the founders, not being technical, just let them do as they liked.
It’s been a match made in heaven: the founders have no clue when it comes to technology, and let themselves be seduced by the “hero developer”, becoming highly dependent on John.
It’s true that John obviously combines acquired insights in the domain with knowledge about the infrastructure and architecture he created, and about every technical implementation detail.
However, there a few important aspects to John’s way of working that are not beneficial to the startup, and will hurt them sooner or later.
As the loner that John is, he’s used to have absolute autonomy, but he’s often not the visionary leader who takes into account the business needs for the longer term.
On top of that, John has never spent any time to share or document his knowledge.
Accelerate
Having a live SaaS product, that has gotten some traction and is generating some revenue, the founders are able to get a bit of funding in, and want to accelerate and professionalize.
The investor, however, is making clear that, to do this, they need to be aware of the unsustainable, risky situation with John ‘owning’ everything tech, and since they’ve seen this situation before, they suggest hiring a Fractional CTO to de-risk and grow the team.
As a first step, the CTO has interviews with the founders (who explain the history of things, and the request of the investor).
Then, the CTO takes a lot of time to get to know John.
Having had to deal with similar situations, he first tries to earn some trust from John, showing respect for what John has achieved on his own, and acquiring a sense of what drives John, why he did what he did, and how that relates to the business needs the startup had when he did.
So far, so good. It seems like John gets more at ease with the situation, and he regularly expresses the fact that he ‘can learn a lot’ from this new CTO.
Some time later, having talked to the founders, and having carefully considered what tech changes would be needed to address the current business needs, the CTO then discusses these changes with John, to get his perspective and ultimately, his buy-in.
John however protests.
Escalation
The CTO, by now, understands that the new direction of travel pulls John out of his comfort zone, and tries to empathetically address the issue, having dealt with this kind of situation many times.
The CTO adds as much detail and nuance as possible, and tries, in the most delicate way possible, to address John’s knowledge gaps and learning opportunities.
But John gets angry, keeps repeating his rigid standpoint, and starts picking fights.
John even uses ChatGPT to support his protest (which always works, because you can amplify any bias you want with it) 🤯.
John also has a way of talking to the board behind the CTO’s back, to stir controversy.
The board is panicking.
“We can’t have John unhappy! What if he leaves? He has all the knowledge!”
They plead to the CTO: “Please can you make sure we don’t lose John?”
Giving in to anger or threats creates an undesirable precedent, weakens the position of the CTO, and sends a message to John that he’ll get his way.
Net result: the startup is held hostage.
Breaking the Vicious Cycle
In these situations, the board needs to step up and be very clear on resolving the situation once and for all.
Ultimately, an open discussion with all parties involved needs to take place.
One that acknowledges the role John has played in the early stages, but firmly states that there can no longer be a dependency on one individual.
This discussion should be meticulously prepared, since John might try to hijack the meeting to vent his opinions again, creating chaos.
The board needs to clearly state the fact that they respect John, but have hired the CTO to get guidance on strategy.
Since the board is not in a position to assess the technical side of things, they need to follow through on the trust they expressed to the CTO.
Having the board putting the situation out in the open, addressing it proactively, is the only way to empower the CTO.
After all, there was a reason the CTO was hired.
Discussion
The original post on LinkedIn has around 200 comments by now (August 2023), some of which turned out to be filling in missing context, caused by LinkedIn’s post size limitation.
I’ve tried to correct this in this article, but let me give you a digest of some relevant reactions, so you don’t have to dig into the mess that is reverse engineering a LinkedIn post thread 😏.
- Some hardliners said: just give John 90 days to change, then fire him is he hasn’t improved.
A: sure thing. Pressure is needed, and consensus about it in the first place, but only combined with an effort to get everything documented and remove the dependency — which will also help in onboarding new team members. - It’s the startup management/company culture that has created this situation, so it’s not fair to blame it all on John.
A: agree, this is not about John, in isolation. It’s also about the many non-technical founders who simply have no idea, and who are lured into this trap. They could have gotten advice earlier, and they should have. - The Fractional CTO is leadership, so he needs to take action.
A: a fractional CTO never has the same mandate as a permanent CTO, and will always need buy-in from the ones that hired him/her, the founders, the board.
Epilogue
This is the first of a series about human dynamics in Startups and Scaleups. I’m writing way more frequently on LinkedIn, so follow me there if you like this!
And don’t forget to clap if you feel like it — and I mean click the ‘Clap’ button a couple of times on Medium 😏.
[EDIT]
See part 2 of this series: Jane — or When Your Genius Developer has Behavioral Issues and is Bullied by the Team | by Marc van Neerven | CTO-as-a-Service | Sep, 2023 | Medium
