I was a co-founder and CTO. Then I took a job as an engineering manager, which most people read as a step down. Nobody has asked me about it directly in an interview, and I am fairly sure everyone has wondered. So here is the actual answer.
11 May 2026·14 min read
On paper it reads like a demotion. Chief Technology Officer, four years, then Software Engineering Manager. On a title ladder that is a rung down and to the left, and people are too polite to ask about it, which is worse than being asked.
I notice it every time I see my own history written out. There is a particular feeling in seeing a career laid out in reverse-chronological order, where the shape of it implies a story you did not live. Anyone scanning it builds a narrative in about four seconds, and the narrative available from those two lines is that something did not work out.
I have rehearsed the answer for interviews that never asked. That is its own strange experience: preparing a defence for an accusation nobody makes out loud, and never being sure whether the silence means it did not matter or that the decision was already made before I sat down.
The honest version is that the two jobs are not on the same ladder. They are not even the same job. Comparing them by title is like comparing a restaurant owner to a head chef by counting the words in their business cards.
So rather than defend the move, what follows is a description of both roles as I actually experienced them, side by side, and then what the trade really was.
What CTO meant at a company of our size, in practice, on a normal week.
Architecture, the stack, build-versus-buy, the data model, the roadmap. The part I was actually trained for, and the part that took the least of my attention once we had customers. Every founding CTO I have compared notes with says a version of this and every one of them was surprised by it.
We handled protected health information. That means HIPAA, controls, audit readiness, data governance, and a set of questions where the answer cannot be "we will get to it in the next sprint". Compliance is not a feature you add later. It is a constraint you design inside, and somebody has to own it personally. That was me.
Contracts, BAAs, vendor terms, IP assignment, the paperwork of actually being a company. I was not the lawyer. I was the person who had to read it closely enough to know which parts to send to one, and to sign things that would matter years later.
Building an engineering organisation from nothing means writing the job descriptions, doing the interviews, making the offers, and then, eventually, ending it with someone. Firing a person you hired, in a company small enough that everyone notices, is the single hardest thing I have done professionally. Nobody prepares you for it and no book helps.
There was nobody above me to check my architecture. If I was wrong about the data model, we found out in production eighteen months later with customers on it. People talk about founder autonomy as a benefit and it is, right up until you notice that autonomy and exposure are the same property viewed from different sides. I made calls I am still proud of and at least two I would take back, and there was no senior person to catch either.
A startup is not a job you leave at the end of the day, because there is no version of the day where somebody else is holding it. Customer escalations arrived on my phone. Investor questions were mine to answer. When we were deciding whether we could afford someone, that was a conversation about a real person's livelihood, held by people who could not fully afford to be wrong. That weight is a different kind of thing from responsibility inside a company that will exist regardless of your week.
The category that ate the rest. Some weeks it was a customer escalation, some weeks a partner integration, some weeks the thing nobody else could do because there was nobody else.
And the same treatment for the job I moved into, because a comparison with only one side described is not a comparison.
A team, spread across more than one product line. Growth conversations, performance conversations, the ones where somebody is unhappy and has not said so yet. As CTO I hired and fired, which sounds harder and is in the moment. What I did not do was develop anybody over years, because we did not have years. This is the part of managing I was worst at on arrival and the part I would now say is the job.
At the startup, if a priority was wrong I changed it that afternoon. Here there is a roadmap above mine, other teams with their own commitments, and a business case that has to survive a room. Getting something done means building agreement first, which is slower, and produces decisions that outlive me rather than decisions that unwind the moment I leave.
I set architectural direction and pressure-test the decisions that carry it. I read pull requests. I do not write the production code, and the temptation to is the thing to resist. The skill is knowing which technical arguments matter enough to spend authority on, which is different from having the arguments.
Between engineers and a business that does not think in engineering terms, in both directions. Explaining why a migration is not a feature. Explaining to a team why a priority they think is arbitrary is not. At the startup I was both parties, so translation was internal and instant. Here it is most of the work.
I arrived thinking a CTO title meant I would find this straightforward, and that was wrong in a specific way. I knew how to make decisions and I did not know how to build agreement. I was fast and the organisation was not, and my instinct when blocked was to route around rather than to persuade. That instinct is an asset at startup scale and a liability at enterprise scale, and unlearning it took most of a year.
A decision I make lands with customers I will never meet, in numbers I cannot picture. That is a heavier kind of responsibility than a small team and a customer list I knew by name, and it is quieter, which makes it easier to underrate.
And here is the part that gets missed, because a job title cannot show it. The four years I was CTO were not four years of doing only that.
I did not leave a job to found a company. I did both. A full-time senior engineering role during the day, and a healthcare startup where I was responsible for the technology, the compliance posture and eventually a whole team, in the hours around it.
I am not going to romanticise that. It worked, in the sense that the company shipped, grew and still exists with me on its board. It was also four years of sleep I did not get, and I would be lying if I said the arrangement was sustainable or that I would recommend it to somebody without knowing a lot about their circumstances.
What a week looked like: a full day at the day job, then the startup work in the evening, then the parts that only happen after hours, which is most of the compliance reading, the contracts, and the conversations with people in other time zones. Weekends were not weekends. I got good at working in ninety-minute blocks because that was the unit of time I actually had.
The reason I did it that way is unglamorous and I suspect familiar: I could not afford not to. Walking away from a stable senior engineering salary to go all-in on an early healthcare company, with the obligations I had, was not a risk I was willing to hand to my family. So I took the other risk, which was to absorb the whole thing personally and hope the arithmetic held.
It held longer than it should have. The thing that eventually decides an arrangement like that is rarely a dramatic failure. It is an accumulation. You notice you are tired in a way that sleep does not fix, that the interesting technical problem now feels like a task, that you are present at home in the sense of being in the room. Nobody hands you a moment of clarity. You just gradually stop being good at either job, and if you are lucky you notice before somebody else does.
What it did give me is an unusually clear view of what each job actually costs, because I was doing both at once and could feel the difference in my own week.
People ask how you decide something like this, and the honest answer is that you do not, in one sitting. It happens in pieces over months and then one day the choice is already made and you are catching up to it.
There was no offer that forced it and no falling-out. The company was not failing. It had customers, a platform that worked, and an engineering organisation I had built from nothing. Those are the conditions under which leaving is hardest, because nothing external gives you permission.
What changed was the question I was asking. For four years the question had been "can I keep this going", and the answer was always yes if I was willing to spend more of myself. At some point the question quietly became "is this the best use of the next ten years", and that one has a different answer.
The thing that unlocked it was realising the choice was not binary. I had been carrying it as leave or stay, founder or employee, all or nothing. It is not. The company could keep me as an owner and a board member and lose me as its CTO, and for a company at that stage, having the founder in the room a few times a year with skin in the game is worth more than having him exhausted in it every day.
Once I saw that, the rest was logistics. I stepped back from the operating role, kept the ownership, kept the board seat, and went to find out whether I could do a different job properly.
Then there is the arithmetic, which founders are bad at discussing honestly because the answer is unflattering to the story we prefer.
The framing everyone knows is that a small slice of a big pie beats a big slice of a small one. It is true, and it is usually deployed to justify dilution. The uncomfortable follow-on is what the distribution of pies actually looks like.
Patrick McKenzie's version of the equity lottery is bleak and, in my experience, accurate: on a hundred-sided die, most outcomes are worth nothing, a band of them roughly matches the big-company salary you gave up, and only the last few points are life-changing. The 80,000 Hours analysis of Y Combinator founders puts numbers on it: 80% of the money belongs to 0.5% of companies, another 22% do well enough that founder equity beats a big-company job, and that leaves roughly 77.5% where it does not.
Read that last figure slowly if you are a founder. For three quarters of us, the equity is worth less than the job we did not take. That is not an argument against starting something. It is an argument for being clear-eyed about which part of the return is money and which part is everything else, because for most of us the everything else is the whole return.
So what did I actually trade? Less than the title suggests, and more than I expected.
This is the part that makes the "step down" reading wrong. I did not sell up and walk away. I still hold majority ownership of the company and I still sit on its board. What I gave up was the operational role, not the stake. The equity story and the title story are two different stories and people collapse them.
That is the real cost and it took a while to feel. As CTO the technical direction was mine to set and mine to be wrong about. As an engineering manager inside a large organisation, I influence rather than decide, and there is a roadmap above mine. Some days that is a relief. Some days it is frustrating and I do not pretend otherwise.
The organisation I joined operates at a scale the startup never approached. The systems are bigger, the constraints are real, the blast radius of a decision is measured in customers I will never meet. I have since led a team through a corporate divestiture, which is an education a small company cannot give you at any price.
Worth saying plainly rather than burying it. Four years of two jobs ended, and I got my evenings and my health back. Anyone who treats that as a soft consideration has not done it.
Six years on, the parts I miss and the parts I do not, stated plainly enough to be useful to somebody weighing the same thing.
Deciding something on Tuesday and having it in production on Thursday. Not because we were reckless, but because the distance between a decision and its consequence was short enough that you learned quickly. Large organisations trade that speed for durability and it is a real trade, but I felt the loss for about two years.
Knowing why every part of the system was the way it was, because I had been there for all of it. That kind of complete mental model is a luxury of small systems and I will probably never have it again at this scale.
The pager, the escalations, the sense that if I did not solve it nobody would. It sounds heroic in retrospect and it is corrosive in practice. There is enormous relief in working somewhere with genuine depth on the bench.
Whether we could afford a hire, whether a contract closing late meant a difficult month, how much runway a decision cost. Carrying that alongside the technology is the thing that actually wears people down, and almost nobody lists it when describing the role.
The genuine surprise. At the startup, people were resources I deployed against problems, which sounds cold and is simply what the pace allowed. Here I have watched engineers grow over years, and being partly responsible for that is more satisfying than any architecture I have drawn. If you had told me that in 2020 I would not have believed you.
The thing I would push back on is the axis itself. "CTO" and "engineering manager" sound like rungs on one ladder and they are not. CTO at a small company is a generalist job that happens to have "technology" in the name, most of which is security, compliance, hiring and whatever is on fire. Engineering manager at a large company is a specialist job about people, delivery and technical judgment inside a system much bigger than you.
I have been the senior-most technical person at a company where that meant reading a vendor contract at midnight. I have also been a manager inside a corporation where it meant defending a roadmap against a competing priority with real money behind it. The second is not a smaller version of the first. It is a different discipline, and I was not good at it on day one just because I had held a bigger title.
If anything, the thing I am proudest of is not the CTO title. It is that the company still exists, still has customers, and I am still on its board, while I went and learned to do something else properly.
What I would tell someone standing where I was standing.
They feel like one decision and they are two. You can step back from the operating role without selling the stake, and in a lot of situations that is the right structure for everyone. I did not realise that was available until I looked properly.
If the honest description of your week is security, compliance, legal, hiring and firing, ask whether that is the job you want to be excellent at in five years. It is a real job and some people are brilliant at it. It is not the job most engineers think they are signing up for.
Four years of two jobs made a company real. It also had an expiry date I was not tracking. If your arrangement only works because you are absorbing the difference personally, that is not a plan, it is a countdown.
Nobody has asked me about this in an interview, which means either it does not matter as much as I feared, or it is being quietly held against me. This page exists so it can be the first one instead of the second.