CTO acts as Individual Contributor (IC)

Question

This is a "Team / Tech Lead acts individually over leading a team" type question, but at a higher level of a CTO.

We're a small fully-remote business with a successful product solving several overlapping complex industry problems, but seen as unreliable and struggling to grow. It's hard to ignore much of this is indirectly due to the CTO we'll call Carl.

Carl is a talented and prolific super-coder with deep technical knowledge who built the entire platform himself - and an excellent Individual Contributor - IC - but has trouble with the larger picture and teamwork.

I see these main problems:

a) only Carl really knows how the platform works, what features it has, how to use it, etc.

b) he gets distracted, often by customers or salespeople who directly contact him

c) he has a do-ocracy approach and can act unilaterally and unpredictably

d) he often over-commits, or fails to commit, forgetting or trivializing agreed work

Think of Brent from the Phoenix Project, but he seems to LIKE being Brent.

The CEO might directly ask him to act on an urgent problem, he agrees to do it "next thing", and he'll get distracted with someone asking him something relatively trivial in Slack / email. Repeat the next day, or week.

Or a customer Slacks him with a feature request, bug, &c. Carl goes "what a good idea", and does it on the side without telling any of us, or any other customer, who needs and would pay for it. Or worse, he lets them down due to being over-committed / distracted by OTHER hidden work, us only finding out when the customer escalates.

People quickly learn "the only way to get something done is to get in front of Carl" - start a video call with him and customers, where he cannot ignore the problem and fixes it on-screen, sometimes in seconds. Frustrating for everyone - especially if it's a simple problem that's blocked them for months.

This impacts the entire business. We are often surprised by our own product; every day is firefighting; critical projects are so behind we largely give up planning, often even which fire to fight first; we're getting into trouble with the industry regulator; and so on. Some customers love him, he's their concierge AND a rock star. Others... do not.

The CEO is well aware of this, and that Carl is net-positive value, so tends to overlook this, even when it costs us. "Without Carl, there'd BE no business." We have tried:

• Change process / shield: prevent customers or salespeople from distracting him, change our use of Slack, use JIRA to track work, etc. No impact: they email him directly, and set up calls we find out about afterwards. We have found customers adding him to THEIR Slack, project calls, etc. as if he's their contractor, which he goes along with.

• Delegation: hire developers, product people, support staff, etc. to help and learn from him. Mixed: he tries, but sees them as a distraction instead of tools to increase his reach. He struggles to find them work, preferring to do it directly, and likes it when they are out sick / on vacation.

• Learn: write down how things work, so he's not the bottleneck. No impact: The platform is complex, he wrote it himself, and much of it lives in his laptop / his brain. Asking for documentation turned into a help system for each page in the platform, but apart from a couple of test pages, it's empty. Note that somehow he has spare time to write a custom help system, but no time to put anything into it.

• Split into workstreams: using the above. No impact: everything, from the help to the login system to the support email are, somehow, an in-house system only Carl understands. We are paying expensive contractors to do nothing as they wait for Carl to spec, review (or re-write) their work, which he has to wire up behind the scenes. We cannot even create a test server after years of trying; Carl's laptop is used for QA.

• Understand Intent: borrow from Situation, Behavior, Impact - learn why he acts this way, what drives him, his goals, etc. Mixed: He loves coding and solving technical challenges, and describes himself as "multitasking" or "being customer focused". Conversations then switch into fixing the problem in front of him - usually something he is way too talented for, but he clearly likes doing, especially when only he knows what to do and - he thinks - justifies working long hours to help them.

• Asking Nicely: like rolling dice.

What else can we try to change this behavior?

EDIT: I am a non-C-level staff with no equity or stake beyond an employee who wants them, and where I work, to grow and succeed. They are nice people to work with and have good humor, especially Carl. Been trying to learn the platform as much as I can, but it's trial and error and I've often looked an idiot with customers who know the platform better than we do.

Answer 1

If you're not C level or above yourself then I doubt that there is anything you can do. Carl likes being the hero and is allowed to play the role by the other C level people even though his overall actions are detrimental to your company.

Carl needs to be held responsible for his actions by people who are at his level or higher. And at the extreme that could even include being fired.

Fundamentally this is a company culture issue and those are notoriously hard to fix, but can only be fixed from the top down. Long term if you cannot stomach the current culture, then the only thing you can realistically do is to seek a different culture at another company.

---

While I say above that you probably can't change the culture, you can document Carl's detrimental actions and show how much $$$ he is costing the company. C level people should prefer to minimize waste money. However if you go down this route it will probably end up being a Carl vs you situation which is only resolved by one of you leaving - and it currently isn't likely to be Carl.

Answer 2

Today in ''Not your problem'': you are not high enough in the food chain to force changes, so there is nothing you can do. You have done your best, leave it at that. If the CEO and other higher-ups won't listen, it is their problem that Carl has created a monstrously big Bus Factor.

Answer 3

You need to start learning how the platform works. Without Carl's help.

You can't change Carl. You tried that, and you failed. Even an un-cooperative Carl brings great value to the company, so he can afford to do only stuff that's fun for him to do without risking his position. But you can change what you (= you, the CEO and the rest) do.

---

Imagine that, one day, Carl decides to retire. What will you do? You will frantically try to learn and understand how his platform works, how to support it, how to modify it, how extend it. It will be hard, you will struggle, but you will, eventually, succeed.

You need to start doing that now. It's a lot easier while Carl is still around, even if he decides not prioritize knowledge transfer and keeps doing only fun stuff.

Now start working as if Carl had already retired:

• The next time the customer has a problem that's blocked them for months, don't wait for Carl to do his ten-second magic to fix it. Get your hands dirty and try to find the root cause of the issue. Use help from your colleagues. If you get struck, feel free to ask Carl for a hint, but don't hand over the issue to him. The main goal is to learn, not to solve the problem.

• Start documenting stuff. Carl wrote a help system, but it's empty. Well, stop staring at those empty pages, fill them with content! Find out how stuff works, using every resource you have available: Trial and error, reading code, reading tests, yes, even asking Carl for a few words of wisdom is fine.

• Don't wait for Carl. A contractor wrote code that needs to be reviewed? Review it! Do it to the best of your abilities. No, it won't be as perfect as if Carl had done it, but it's a start, it unblocks your process, and you'll learn. You'll make mistakes, but mistakes are great: You can't learn from being perfect. You learn from making mistakes.

As I said above: It will be hard, you will struggle, you will make lots of mistakes, but you will learn. And eventually, you will understand how the system works. Carl will still be valuable single contributor, but he won't be the only one any more.

The CEO is well aware of [these problems].

That's great, because you'll need the CEO's approval for this change. Think it over, talk to the CEO, and then have a meeting with Carl. Tell him what you plan to do. If his personality is like you have described him, he might even be delighted: He can continue being the rock star that gifts the mortals around him with invaluable words of wisdom and great pieces of code, but you take away his burden of being the only one who can actually get work done.

Answer 4

A good developer does not equate to a good leader.

There isn't too much you can do besides maybe talk to other C executives to see if they can talk to him as it sounds like he isn't a good fit of leader (from what is mentioned). He might be willing to change role to one that is more developer focused and less leadership focused, but there are lots of complexities around this like benefits, losing control of 'his' project, business stuff, etc (and if OP could even initiate this).

What you/others can do:

• document: when you/others do things, document it. When you/others sit in front of him...he fixes it on-screen document what he does, if you can see the screen. If not ask questions: How did you do that? Why did you do X and not Y? Then document it

• delegate: reach out to other developers when you have issues-don't let him delegate, have others delegate. You mention Jira, so have tickets assigned to other developers. Its not perfectly clear the type of system you have, but I'd imagine you have a repository of code of sorts (git, svn, etc) and developers that are familiar with the framework(s) in question. They should be able to at least attempt a solution.

  • if the contractors are expensive and do nothing, they are being overpaid. Lots of systems are monolith. Parts can be broken up (front-end, back-end, admin view, customer view, page 1, page 2, etc) and worked on in parallel/tandem. If a giant rework is required-why can't multiple developers be involved in that instead of one person?

• define role: OP didn't mention role/equity but what should the CTO be doing? Are they meeting their responsibilities? Are they in the meetings they need to? If they are distracted by others, make sure they are distracted by the right things (plan events): important meetings, overview technical discussions, business meetings, etc

Answer 5

Target the test server first.

The other answers are good, your description is good, and it's not an easy problem. This is a supplemental answer. Of the entire attack surface you've described, the test server is easiest thing to target. I am assuming that source control is used in a usual and routine way.

• Developers already need to build the environment locally. They have a lot of the tools and knowledge needed to build a new test server on an independent box.
• Troubleshooting the setup of a working QA server will flush out important information to know and document. Some of this probably lives on Carl's QA server and in production: capture it in a separate config source control project. This will need to include the magic wiring.
• Once setup, it takes Carl off the critical path for testing and production releases. He will still probably do some releases based on his own QA server, but as long as it's the same source control, that's fine.
• Carl will be too distracted by the crisis du jour to consistently gatekeep the server once setup.
• Once setup, it can make easing the code review bottleneck easier. Eg make a rule "if it has waited on Carl two days, two other developers can review instead". Then it can be tested in the QA environment and still released, pointing to the urgent customer need to justify it.

The eventual target would be for Carl to be a hyperproductive developer, who jumps around fixing things, but doesn't block other people any more.

Answer 6

Are you using a change control system?

If so, set it so EVERYONE's changes must be tested and approved by peers before being merged into the main development repository. Require that EVERYONE's code be submitted with a regression test that shows the problem before the change was made and the fact that it functions afterward. Require that EVERYONE's code pass a full regression suite before being merged, or include and explain changes to that suite.

Everyone includes Carl.

That way at someone gets to see, check, and hopefully understand his change, in isolation, before it becomes part of the shared codebase. They can request that it be better explained/documented, or add documentation themselves and ask Carl to check that they've understood it correctly. They can look at the regression test to see exactly what case it's intended to address. They may even spot bugs or oversights in the code that Carl missed.

It doesn't address the fact that he's jumping the gun on things which may not be at a priority level where anyone else would address them. But it helps ensure that he works with the team rather than around it.

This will also help the rest of the team write better code and documentation.

If you aren't using a change control system, FIX THAT. You need one for any project with multiple developers that exceeds a few hundred LOC, and it's best practice even below that line.

(By the way, you should also be using an issue tracking system which lets everyone get involved in the prioritizing process and which displays the relative priorities clearly, and see if you can get Carl to put his issues into that. This may help him see whether he's actually working on what everyone thinks is most needed right now -- or help him convince you that his change really is more important than you might think. IDEALLY, it's nice to have issue tracking and change control linked to each other so you have a history of which changes addressed which issues.)