I have been the CTO at Sports Excitement since January 2026. Four months in, leading a fifteen-engineer team across web and mobile, owning system architecture, and still writing code most days. I am still building, the seat is still new, and most of the lessons here are the early ones. This is what has surprised me, what is working, and what I would do differently if I were starting the seat over tomorrow.
The seat is mostly translation
I expected the CTO seat to be mostly architecture. It is mostly translation.
Founders speak in product outcomes. Engineers speak in implementation details. PMs speak in user flows. Designers speak in interaction patterns. Customers speak in problems they cannot articulate cleanly. The CTO sits in the middle of all of them and translates each language into the others without losing meaning.
The translation work is invisible until it stops happening. When a feature ships and the team feels good about it, the translation went well. When a feature ships and the founder is surprised by what came out, the translation broke somewhere upstream. The bug is rarely in the code. The bug is in the conversation that happened three weeks ago when the spec was written.
I did not appreciate this in the first weeks. I treated translation as overhead. By the second month I had started treating it as the core of the seat. The shift has produced more shipped features than any architectural decision I have made so far.
The tax of leading vs the tax of building
A CTO who never writes code loses touch with the system. A CTO who only writes code loses the team. The trick is the ratio.
My ratio settled at about sixty percent leading and forty percent building, with the building concentrated on the highest-leverage parts of the system: API contracts, auth flows, payment handling, infrastructure. The team owns implementation everywhere else. I review pull requests, I unblock, I prototype the trickier piece when it would take the team a week to figure out and me two days because I have the context.
The trap I avoided: trying to build everything. The trap I fell into: not delegating fast enough in the first weeks. I held on to features I should have given to senior engineers because I was nervous about quality. The team is better at the implementation than I gave them credit for. I learned to trust that, then I learned to verify it through review and standards rather than through doing the work myself.
The architectural decisions I owned
A few that mattered.
40 plus REST APIs with consistent auth and observability. Every API on the platform follows the same pattern: middleware authenticates the JWT, middleware authorizes the role, the handler does the work, structured logging captures the result. New endpoints take a junior engineer about half a day. Without the pattern, every endpoint reinvents the wheel and the team spends thirty percent of their week debugging inconsistencies.
Hybrid VPS plus cloud infrastructure. The platform runs across rented VPS instances for the core services and AWS for storage, queues, and the parts that need autoscaling. The hybrid is not glamorous. It is cheaper than going full cloud and more reliable than going full VPS. I made the call in the first weeks of the seat and have not regretted it. When a VPS provider had a bad Tuesday recently, the system stayed up because the critical paths were on AWS. When AWS billing started to creep, we moved a workload back to VPS overnight.
Centralized logging plus monitoring. Every service ships logs to a single ingestion endpoint. Every alert goes to a single channel. The on-call rotation rotates through the engineering team, not through me. I built this early because I knew that without it, every incident would land on my phone at 2 AM. With it, the team handles ninety percent of incidents without paging me.
JWT plus OAuth plus database-level RLS. The same authorization-at-the-database pattern I use everywhere, except here it scales across fifteen engineers. Junior engineers cannot accidentally write a query that leaks data because the database refuses to return the rows. The mental model takes a week to teach. The dividends compound forever.
The team and the boring stuff
Engineering leadership is mostly boring. Standards documents. Code review templates. Onboarding runbooks. Pull request checklists. The boring stuff is what keeps fifteen people moving in the same direction.
I learned this the hard way. Early on I let standards slip to ship a feature on time. The next sprint, the team produced the same feature in three different patterns because the standard had been quietly suspended. Re-establishing it took two weeks. Letting it slip in the first place took one Friday afternoon.
The lesson: the boring stuff is the leverage. A standards document that nobody reads is useless. A standards document that gets enforced in code review is the difference between a team that compounds and a team that diverges. I review every PR for standards compliance. I do not review every PR for implementation details. The team handles those. I handle the things that, if they slip, cost us a month.
What I would do differently
Three things, honestly.
I would hire slower. We hired three engineers in a single month early on. The onboarding cost was real and I did not appreciate it. Each engineer needed two to three weeks of pair time before they were productive on our codebase. Three at once meant six to nine engineer-weeks of my time disappeared into onboarding instead of building. Stretched over three months it would have been the same total time but better integrated.
I would write the architecture document before the third feature. I am writing it now, four months in, and the document is partly archaeology, partly design. If I had written it in the first month, it would have been a contract: this is the system we are building, here is how the pieces fit, here is what is in scope and what is not. Without that contract, the team made reasonable local decisions that compounded into a system that nobody had explicitly designed. I am still catching up to that contract from the inside.
I would push back on scope earlier. Founders push for scope. CTOs push back. The push-back has to be calibrated: every "no" costs goodwill, every "yes" costs delivery. In the first weeks I said yes too often because I was new and wanted to prove I could deliver. The result was a roadmap that was too long, a team that was too stretched, and a quality bar that slipped twice. I have since learned to say "we can do that, here is what comes off the list." That conversation should have started on day one.
What I would carry to the next role
Three takeaways.
Translation is the job. The architecture is the easy part. The translation between founder and engineer is the hard part. Whatever the next role is, I will spend more time on the conversation and less on the code than I expect.
Standards compound. Heroics do not. Five fifteen-minute conversations about standards in code review will outlast every all-nighter. The boring stuff is the leverage.
The system has weight, and the weight is real. Every decision ships with a maintenance tax. Pay the tax in design, where it is cheap. Or pay it later, in incidents, where it is expensive.
I am the CTO at Sports Excitement and committed to what I am building there. I am writing this four months in, with the team still growing and the system still maturing. The lessons compound across roles, and the engineer I am becoming in this seat is the engineer I will carry into whatever comes next. If you are a founder reading this and thinking about the leadership half of a founding-engineer role, this is what the first months actually teach you.
