This is a "team lead acts as an individual and doesn't lead the team" type of question, but at a much higher level.

We're a small fully-remote business with a successful PaaS solving several overlapping complex industry problems, but we're stuck, and seen as unreliable. It's hard to ignore that's mostly due to the CTO we'll call Carl.

Carl is a talented and prolific super-coder with deep technical knowledge and built the entire platform himself - though weaker in other areas, notably teamwork and the bigger picture.

There are three main problems:

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

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

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

Think of Brent from the Phoenix Project, but here I think he LIKES being Brent.

For example, often the CEO asks him to act on an urgent problem, he agrees to do it right after the call, and he'll gets sidetracked with someone asking him something in Slack / email. Repeat the next day. Urgent problems get ignored.

Or a customer Slacks him with a feature request, bug, etc. Carl goes "That sounds a good idea!", and does it without telling any of us, or any other customer, who need and would pay for it. Or worse, he lets them down due to being over-committed / distracted, us only finding out when the customer escalates.

People learn "the only way to get something done is to sit in front of Carl" - schedule a call with customers, where he 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; critical projects are so behind scheduled we've effectively given up planning; every day is firefighting; 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. We have tried:

  • Change process / shield him: prevent customers from distracting him, change our use of Slack, use Jira to track work, etc. No impact: they email him directly, set up calls we find out about afterwards, etc. We have even had customers add him to THEIR Slack, Jira, team calls, etc. as if he's a contractor for THEM.

  • Delegation: hire developers, product people, etc. to help and learn from him. Mixed results: 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 himself, and likes it when they are out sick / on vacation.

  • Document: write down how things work, so he's not the bottleneck. No impact: The platform is complex, 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 parallel workstreams: using delegation 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 review (or re-write) their work, which he has to wire up behind the scenes. We cannot even create a test server; 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. Inconclusive: 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.

  • 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 up a bit and succeed. They are nice people to work with and have good humor, especially Carl. As a stopgap, have been trying to learn the platform as much as I can (as an answer suggests), but it's trial and error and I've made myself look an idiot in front of customers who know the platform better than we do.

  • 4
    What's your position? Do you have any equity?
    – AakashM
    Jul 8 at 13:21
  • 11
    "The CEO is well aware of this" Excellent. What is the CEO doing about the problem they acknowledge is a problem? Jul 8 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
    Jul 8 at 14:29
  • 1
    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 Jul 9 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? Jul 9 at 11:31

5 Answers 5


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.

  • 7
    "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
    Jul 9 at 5:55
  • 2
    @Mast Hence the very last clause of my answer
    – Peter M
    Jul 9 at 14:35
  • 4
    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
    Jul 10 at 6:36

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.

  • 3
    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. Jul 9 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. Jul 9 at 11:24
  • 4
    @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. Jul 9 at 12:55
  • Would be worth adding what OP can do here: find another job.
    – bob
    Jul 9 at 20:08

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
    Jul 10 at 14:13
  • @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
    Jul 10 at 18:20
  • 1
    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
    Jul 15 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.

You must log in to answer this question.

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