The Executive Brief
My CTO friends will often discuss how to handle underperforming employees with institutional knowledge leaving their teams. In fact, it’s so common that we’ve started to joke that this is the secret initiation into our CTO club.
What I noticed during all of those conversations is that for Rock Star CTOs, this kind of employee leaving wasn’t a problem. It was just another detail to be handled. But for less experienced CTOs, it was a Big Freakin’ Deal™.
For many CTOs, there is a genuine fear (or at least something bordering on it) that when someone with deep institutional knowledge leaves that things will come to a grinding halt or even collapse all together.
That’s when I started to think about how different CTOs handled the leaving of key employee who might be underperforming and that’s what I’ve tried to distill here.
Enjoy.
Btw, before you dive into it, here are the most interesting bits in technology from the last week.
Tyler Perry halts $800M studio expansion due to AI advancements. "All of that is currently and indefinitely on hold because of Sora and what I’m seeing," he said in an interview. "It’s not just our industry, but it’s every industry that AI will be affecting, from accountants to architects.”
Mr. Perry is not wrong. If you’re not looking ahead on how AI will affect your industry, company, team, or even your own job, you’re behind the curve.According to AT&T, a massive outage to their wireless service was caused by “an incorrect process used as we were expanding our network.”
The cynical side of me notes how they put the positive spin on it by framing the outage as a byproduct of network expansion. Meanwhile, the engineer in me is screaming “Change management! Maybe you’ve heard of it! It’s kind of a thing!”Change Healthcare, a subsidiary of UnitedHealth has been down for days due to a cyberattack. UnitedHealth said it identified a “suspected nation-state-associated” actor behind the attack.
Nation state attackers are going after a broader range of targets. CISA has been beating the drum about China, Russia, North Korea, and Iran for a while now. Adding to the lengthy list of reasons your CISO has trouble sleeping, Microsoft and OpenAI are reporting that nation states are weaponizing AI for cyber-attacks.
Poll of the Week
Let us know how we are doing! We’re always looking to improve our content, so your voice is important. Take a moment to respond to the poll or leave us a comment.
Institutional Knowledge is Overrated
I’ve had many conversations with CTOs who are too afraid to make a change with 1 or 2 of their resources because these individuals have a massive amount of institutional knowledge.
These folks may be bad at their job, or not fit with the team culture, or just have a difficult personality, but many CTOs think, “we can’t risk losing their institutional knowledge or something will crash and burn!”
Not being able to exit under-performing but knowledgeable staff has paralyzed many CTOs at one point or another in their career.
Even I’ve dealt with a similar experience.
For example, one time I thought, “what happens if we lose Jim? (Not his real name, btw.) He’s been on the Engineering Team the longest out of anyone. No one else knows how to fix the system if it crashes.”
This was followed by slightly panicked thoughts of figuring out ways to get Jim to stay at any cost. “We need to keep Jim happy!” I thought.
I remember believing we’d fall apart if Jim left. But when he did leave, we got through it. It wasn’t an easy time. But we were totally fine several months later.
In my experience every instance that a technology leader has cited institutional knowledge as a reason to keep a person who wasn’t a fit with the team, it has always turned out (after eventually moving them out) that the turbulence caused by them leaving was grossly over-estimated and that ultimately everything was totally fine.
This is because institutional knowledge in Product & Engineering Teams is completely overrated.
Whether it’s knowledge about the domain, the product, or the technology, there is rarely a scenario in which one very knowledgeable person leaving ruins everything for the company.
These days it’s too easy to document systems and processes and share with others in highly accessible forms (e.g. Confluence) for any one person to be that critical.
Of course there are caveats: for example, you may have a startup scenario where one person is solely responsible for a unique algorithm that is the heart of the new product you’re building. Lose her and yes, it’s going to set you back.
But again, as with my own example, it’s a matter of lost time, not an existential threat. Meaning, if you’re in a $30M, $40M, or $50M or larger business, no major calamity is likely to befall you.
It’s too easy to find someone these days (like a contractor for example) to fill in and “keep the lights” on while you figure out the right permanent solution.
30 years ago, however, that the situation was a bit different.
There were far fewer engineers in the world, first off. Product Management didn’t even exist. Documentation, if it existed, was buried deep in the code itself. There were no systems like JIRA or Confluence. The Internet barely existed so you couldn’t share information as easily. The reverse engineering & code analysis tools weren’t nearly as good. And knowledge of different technology stacks only existed either in the minds of developers or just a handful of hard-copy books. Domain expertise was hard to come by too. It was rare even to capture it in books. There were no “FinTech 101” or “HealthTech 101” online articles like we have these days.
Back then institutional knowledge was a big deal because it was hard to come by.
Nowadays, CTOs should view institutional knowledge as overrated and not be held hostage to it unless it’s a special circumstance (as exampled above).
Here are a few ways to insulate yourself further from the impacts of the loss of legacy / institutional knowledge.
Tips to Protect Yourself from the Loss of Institutional Knowledge
First and foremost, every member of the team should be documenting everything they do, no matter who they are. GitLab is famous for this. The GitLab CEO has published his own documentation on their public site in the GitLab Handbook. There is also an excellent article on the Atlassian blog called How to create a culture of knowledge sharing that details how organizations can shift to a culture of documentation.
Have everyone make a “If I Get Hit by a Bus” personal recovery plan (which is different than pure documentation). The concept is popular, even outside of engineering. There are books like this and this written on the topic. Founders seem especially concerned by the prospect (see this, this, and this).
Every few quarters have a big clean-up sprint or two where people organize the product or tech stack in better ways and clean up their common files.
Run table-top exercises as part of Disaster Recovery & Business Continuity Planning which factors in scenarios of some key people leaving.
Once a year think through your personal mitigation plan if someone critical leaves. Having this in your back pocket is going to give you a lot of confidence.
Get better at evaluating your team. 9-box is a pretty good framework to run a couple times a year. You should know clearly where everyone on the team stands so you’re clear about the value of legacy staff with institutional knowledge.
Be kind. Be respectful. Reward people well for their hard work. But never give anyone the impression they are indispensable, because the truth is no one is.
Closing Thoughts
Be kind. Be respectful. And reward people well for their hard work.
But never give anyone the impression they are indispensable because the truth is no one is - not even people with institutional knowledge.
I hope these ideas gives you a fresh perspective on how to think about institutional knowledge in your team and dealing with folks who know “where the bodies are buried” but might be underperforming.
It is certainly a difficult decision when deciding to move or exit someone like this, but it will come up sooner or later in your career.
But don’t fall victim to the old way of thinking.
Rest assured that as modern CTO you can handle these issues swiftly, assuredly and without fear.
Here are some other articles from Technocratic that you may enjoy as well: