Skip to content
Management

Imposter Syndrome Is Real

The team kept moving without me, and I decided that meant I was failing

I have a PhD in a corner of computer science adjacent to knowledge graphs. I have shipped machine-learning systems that people paid for. I have led teams through work I was proud of. Until this role, I had never been the person responsible for the whole thing: the product, the platform, the people, and everything around them that nobody else was going to do. For the last year I've been exactly that person, and most weeks there is a moment where a voice in my head says: a real CTO would have this under control.

The awkward part is that sometimes the voice is pointing at something real. Reassurance does not tell me what it is. It also does not help me separate a gap I need to close from the much larger story I'm telling myself about that gap.

The team moved without me

I wrote in the first post about bringing people I already trusted, precisely so they could run with work while I was not looking. That is what happened. While I was setting up the entity, running payroll, talking to auditors and reading vendor terms, they were building. There were weeks when I could not have told you in any detail what was in the last ten pull requests.

I had wanted exactly that. It still felt wrong. The picture of a CTO I carried in my head knew the codebase, had opinions about every design choice, and could answer any technical question in the room. I had never actually been that person, even in a much larger company. But the standard sat there anyway, and every week I spent on an invoice instead of the architecture was a week I fell further behind it.

Then they started doing my job

The uncomfortable part came later, and it was quieter than any incident. I started noticing people taking the initiative on things that were mine. A decision about what to prioritise next. A call on how one part of the system should fit with another. A conversation with a design partner that I should have had first. Nobody was overstepping. They were filling a space I had left empty because I was busy somewhere else.

Each time I noticed, the voice had the same reading: if you were good enough, there would be no space. Someone else is holding the picture because you are not. The team is working around you.

I believed that reading for longer than I should have. It was plausible, it matched how tired I was, and it arrived with evidence.

What the feeling got right

Trusting a team to run is not the same as leaving it without direction. The people I brought were excellent at taking a problem and moving it forward. They still needed someone to hold the whole: where this was going, what mattered most this quarter, which of two good ideas we were doing first, and how the piece they were building fitted with the piece somebody else was building. Nobody else could hold that, because nobody else was in all the rooms I was in.

When I did not hold it, the team made local decisions. Each was reasonable on its own. Together they did not always add up, and I would discover that late, usually when two reasonable choices met each other in the same codebase. The initiative was not the problem. My absence from the decisions that only I could make was.

So the gap was real. I had been treating trust as if it removed the need for direction. It does not. It changes what direction looks like, from checking the work to saying clearly where the work is going.

What it got wrong

The conclusion. The feeling turned "I have not been doing part of my job" into "I am not able to do my job". Those are different sentences, and only the first one has a fix.

People taking initiative in my space was the team working the way I had hoped it would. It was also the most accurate possible signal of what I owed them. A team that had waited for me would have been worse, and less honest. They were telling me where I was missing by doing the work themselves, which is what I had hired them to do.

The feeling was also measuring me against the wrong standard. The person who knows every line of the codebase is not the job. The job is holding the picture that lets ten other people make good decisions without me in the room. I had been failing at that, not because I was unable to do it, but because I had not yet recognised it as the thing to do.

What has actually helped

The most useful change was deciding which things only I could hold, writing them down, and saying them out loud on a schedule. Direction. The order of priorities. How the parts fit together. The commitments we had made to people outside the company. Those are mine, and the working agreement we wrote later made that explicit.

When someone picks up something that was mine, I now try to name it rather than let it drift. Either I hand it over properly, in which case it is theirs and that is delegation rather than failure, or I take it back and say why. Silent drift is what turns a healthy team into evidence that I am being replaced.

I keep a list of things I got wrong and gaps I found. It is shorter than the voice suggests, and most entries are specific enough to do something about. A missing decision becomes a conversation to have this week. A missing fact becomes a note. Looking at the actual entries is more useful than replaying a general feeling of being behind.

I also try to separate something I have not done from something I cannot do. Most of what the voice brings me is in the first category.

Some weeks self-doubt makes me check things twice. Some weeks it just makes me tired. I don't want to make a virtue of that exhaustion, or treat feeling out of my depth as a requirement for growing into the role. I would be glad to do the same work with less of it.

Writing here is part of the same effort, the learning in public I set out when I started this series. Explaining what I misread forces me to work out what I actually misunderstood, and gives someone else a chance to correct the explanation too.

I still feel it some weeks, usually when a decision gets made that I should have made. I want to get better at hearing that as a question about where I was, rather than about whether I should be here.

A few useful reads

  • Charity Majors, The Engineer/Manager Pendulum. Useful for thinking about the change in work underneath a change in title, especially when you are still measuring yourself against your previous job.
  • Camille Fournier, The Manager's Path. The later chapters describe the part of the job I was not doing: holding direction and the whole picture while the team moves without you.
  • Ruchika Tulshyan and Jodi-Ann Burey, Stop Telling Women They Have Impostor Syndrome. A reminder to examine the environment before offering someone confidence advice.

The opinions and views expressed on this blog are solely my own and do not reflect the opinions, views, or positions of my employer or any affiliated organizations. All content provided on this blog is for informational purposes only.

I also offer consulting and mentoring in AI strategy, engineering leadership, and scaling teams. Get in touch if I can help.