This is a "developer acts individually over being in or leading a team" type question, but at a much higher level.

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 caused by the CTO we'll call Carl.

Carl the CTO is a talented and prolific super-coder with deep technical knowledge who built the entire platform himself - and an excellent Individual Contributor - but has trouble with the bigger picture and teamwork, due to these main problems:

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

b) Carl is easily distracted, often by customers or salespeople who directly contact him

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

d) Carl 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.

Carl is simultaneously the goose that lays the golden eggs and the kudzu choking everything off.

The CEO keeps a running list of "urgent Carl jobs" which Carl commits to with the breezy confidence of someone who knows they can hand-wave their way through anything. Sometimes he does them. Sometimes he'll get distracted by something trivial for the rest of the day, repeat tomorrow. Sometimes he'll describe at length what he is going to do... and then stall for weeks.

We find 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, 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 customers for months.

We are often surprised by our own product; critical projects are so behind we largely give up on them, often giving up on 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 seems to overlook Carl's behaviour, despite the problems it causes. "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.

  • 5
    What's your position? Do you have any equity?
    – AakashM
    Commented Jul 8, 2022 at 13:21
  • 17
    "The CEO is well aware of this" Excellent. What is the CEO doing about the problem they acknowledge is a problem? Commented Jul 8, 2022 at 13:59
  • I'm not a C-level staff. And the CEO is trying the things above. As the answers say, maybe I can only learn to live with it.
    – sabok61434
    Commented Jul 8, 2022 at 14:29
  • 3
    Are you documenting and tracking the individual incidents where Carl's behaviour is disrupting or otherwise negatively impacting people in the company or its operations? (including data which tracks how much of those peoples' time is lost for each incident) There's a huge difference between the CEO being aware of what's happening compared with having measurable statistics in front of them which translate into peoples' time and ultimately costs/overheads which the business are paying for. As you gather more data, the trends and raw costs ought to be visible over time Commented Jul 9, 2022 at 8:31
  • Why doesn't Carl think that he is a bottleneck and therefore a problem? Is this about the project still being his baby? Is he interested in things changing? Commented Jul 9, 2022 at 11:31

6 Answers 6


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.

  • 8
    "show how much $$$ he is costing the company" if this is not in their job description and the CEO still values the input of the CTO, this is a good way to get dismissed yourself.
    – Mast
    Commented Jul 9, 2022 at 5:55
  • 4
    @Mast Hence the very last clause of my answer
    – Peter M
    Commented Jul 9, 2022 at 14:35
  • 5
    I think some of these answers assume OP is acting alone, even if the question directly says otherwise, and is asking what "we", as in all others in the company, can do.
    – eis
    Commented Jul 10, 2022 at 6:36
  • 3
    This is it. I was in exactly the same situation a couple of years ago, except that my Carl's boss, our CEO, forced me to be the one to oust Carl despite Carl being my boss. But I was vocal about the problems and our CEO didn't have the guts to do it himself. Getting my Carl out saved the company, but cost me way too much in both personal stress and trust from others at that company. Don't touch this, and consider looking for a new job if it's clear Carl isn't going anywhere.
    – thatgirldm
    Commented Sep 27, 2022 at 17:03
  • Show Carl how much $$$ he is costing the company. Don't escalate. Put it to him that while he should be allowed to have fun, he needs to support the company also. Commented Feb 6, 2023 at 18:55

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.

  • 6
    Nitpick but I think you mean monstrously small bus factor, as it seems 1 person being hit by a bus is enough to crater their operations. Commented Jul 9, 2022 at 8:46
  • 1
    @SriotchilismO'Zaic The bus factor varies between not-quite-zero and 1. It's generally calculated as 1 ÷ (number of people under the bus which would cause the company to fail). It's a factor because (a) it's a nice name (b) it's used as a multiplier in probability of failure. Commented Jul 9, 2022 at 11:24
  • 9
    @AndrewLeach: [citation needed]. From Wikipedia : The "bus factor" is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel. Commented Jul 9, 2022 at 12:55
  • Would be worth adding what OP can do here: find another job.
    – bob
    Commented Jul 9, 2022 at 20:08
  • I've seen both versions of bus factor quoted. One will be >=1, one will be <=1, they're identical at one; this is not a problem that needs to be solved now.
    – keshlam
    Commented Feb 8, 2023 at 19:52

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.

  • 6
    This sounds good in theory, but the reality is that people like Carl move too fast and too recklessly to keep up with. Documenting what they do would be a full time job and would leave no time for one’s own development.
    – VGR
    Commented Jul 10, 2022 at 14:13
  • 2
    @VGR: Then they should get someone to do that job. It sounds like they have some contactors who are fiddling thumbs anyways. Apparently, documenting stuff is not something Carl is good at, so why waste his genius on something he's not good at, if he can do other stuff he is good at instead?
    – Heinzi
    Commented Jul 10, 2022 at 18:20
  • 3
    This is a great answer, and what we've been doing, but as @VGR commented, it isn't working well in practice. Still, it's better than "not my problem" so will keep at it - thanks.
    – sabok61434
    Commented Jul 15, 2022 at 14:03

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


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.

  • 1
    This. when the testserver is finally online OP could do his own development and testing. After that you can learn more about the product and the codebase step by step. Try to figure out the architecture and start documenting everything. get the other developers to document everyting too. with this OP can build knowlege and you might not need to wait for Carl anymore.
    – some_coder
    Commented Feb 8, 2023 at 8:42

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.)

  • From the description it looks like Carl is the one that would be making the decision to change processes to require review.
    – Yourn
    Commented Jan 24 at 20:08
  • You can't successfully manage upward in most cases. If the person setting the policy isn't willing to set a good policy, your options are to live with the bad one or move elsewhere. But TRY selling them on the advantages before giving up.
    – keshlam
    Commented Jan 25 at 0:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .