The Title I Gave Up

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. Seeing a career laid out in reverse-chronological order gives you a particular feeling: 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. Rehearsing is its own strange experience: preparing a defense 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 two jobs sit on different ladders, and are barely 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.

Instead of defending 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.

Engineering was the smallest part. 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.

Security and compliance was the largest. 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 a constraint you design inside, and somebody has to own it personally, which in our case was me.

Legal was work I was not qualified for. 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.

Hiring came with it, and then firing. Building an engineering organization 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 hardest thing I have done professionally. You go into it unprepared, and no book helps.

I was the last technical opinion. My architecture had no reviewer above me. 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.

And there is the part where it is your name on it. 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.

Last came whatever was on fire. 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.

People, properly, are the job. 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. Developing people is the part of managing I was worst at on arrival and the part I would now say is the job.

Delivery happens inside a system you do not control. 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. That is slower, and it produces decisions that outlive me rather than decisions that unwind the moment I leave.

Technical judgment is applied rather than exercised. 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.

Translation is constant. 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.

The first year was harder than I expected. 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. I did not know how to build agreement. I was fast and the organization was not, and my instinct when blocked was to route around instead of persuading. That instinct is an asset at startup scale and a liability at enterprise scale, and unlearning it took most of a year.

The blast radius runs further than I can see. A decision I make lands with customers I will never meet, in numbers I cannot picture. The blast radius 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 romanticize 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, and much more often 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. The moment of clarity never arrives. 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.

No competing offer forced it, and we did not fall out. The company was not failing. It had customers, a platform that worked, and an engineering organization 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 realizing the choice was not binary. I had been carrying it as leave or stay, founder or employee, all or nothing. 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.

The framing everyone knows is that a small slice of a big pie beats a big slice of a small one. The arithmetic is true, and it is usually deployed to justify dilution. The follow-on question 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. Do not read that as a reason to skip starting something. The case it makes is 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.

I kept the ownership. The "step down" reading breaks here. 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. The equity story and the title story are two different stories and people collapse them.

I gave up being the person who decides. That is the 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 organization, 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.

I gained a scope I could not have bought. The organization 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.

I got the nights back. 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.

I miss the speed. Deciding something on Tuesday and having it in production on Thursday. The distance between a decision and its consequence was short enough that you learned quickly. Large organizations trade that speed for durability and it is a real trade, but I felt the loss for about two years.

I miss owning the whole picture. 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.

I do not miss being the last line. The pager, the escalations, the sense that if I did not solve it nobody would. It sounds heroic in retrospect. It is corrosive in practice. Working somewhere with genuine depth on the bench is an enormous relief.

I do not miss the money conversations. 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.

I did not expect to enjoy developing people. 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. 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 a different discipline. I was not good at it on day one just because I had held a bigger title.

If anything, what I am proudest of 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.

Separate the equity question from the role question. 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 realize that was available until I looked properly.

Count the hats before you count the title. If 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.

The sustainable version matters more than the heroic one. 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 a countdown.

A title you have to explain is fine if the explanation is good. No interviewer has asked me about this, 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.