What I Learned as a Founding CTO
Five years leading engineering at a startup taught me things no university or senior role at a big bank could. Here's what actually matters when you're the one accountable for everything.
From 2018 to 2023, I was the CTO and co-founder of Vegannation Services. We built a fintech-scale consumer platform. I was responsible for everything technical: architecture decisions, hiring, CI/CD, payments infrastructure, security, reliability, and shipping product.
I came from JP Morgan, where I worked on high-frequency trading systems and large-scale data pipelines. That was rigorous, technical work — but someone else was always accountable for the outcome. As founding CTO, the buck stopped with me. Five years of that taught me things no previous role could.
The hardest part is prioritization under uncertainty
At a big company, someone else decides what you work on. At a startup, you have a product to build, a team to manage, infrastructure to maintain, technical debt accumulating in real time, and investors asking questions. You can't do all of it. You have to constantly choose what matters most right now — with incomplete information and real consequences for being wrong.
The framework I eventually landed on: ruthlessly protect the decisions that are hard to reverse, and move fast on everything else. Wrong database schema choices cost you months. Wrong UI choices cost you a sprint. Know which is which.
You are the ceiling and the floor
As engineering lead, you set both the upper and lower bounds for your team. If you write sloppy code, the team will write sloppy code. If you skip documentation, the team will skip documentation. The floor follows your behavior, not your words.
But you also set the ceiling — the technical ambition of the organization. If you don't push for well-designed systems, nobody else will. If you don't fight for observability and testing, they'll be deprioritized forever.
This accountability is heavy at first. It became clarifying over time. I started being very deliberate about the norms I wanted to establish, because I knew they'd propagate.
Reliability is a feature, not a concern
We had a rough early period where the platform was flaky. Downtime would happen unexpectedly. The team treated it as a normal operating condition — a thing that happened and then got fixed.
That changed when I reframed it as a product decision. Reliability is what your users actually experience. Downtime isn't an engineering problem — it's a product failure. Once the team internalized that, the conversation shifted. We invested in proper monitoring, runbooks, on-call rotations, and reliability goals. System downtime dropped by 30% within two quarters.
Speed of delivery compounds
Early on I cared deeply about code quality. I still do. But I became more nuanced about when quality paid off and when it didn't. A perfect system that ships in six months versus a good enough system that ships in six weeks isn't a quality decision — it's a survival decision.
We implemented CI/CD pipelines that cut deployment time by 50%. That wasn't just an efficiency win. It changed how the team thought about shipping. When deploying is cheap and fast, you ship smaller changes, get feedback sooner, and accumulate learning faster. Delivery speed compounds.
Hire people who own outcomes
The engineers I learned the most from hiring were the ones who cared about the outcome, not just the task. The difference is visible: a task-oriented engineer asks "what should I build?" An outcome-oriented engineer asks "what problem are we solving and how do we know we solved it?"
The latter will proactively flag when a requirement doesn't make sense. They'll think about edge cases before you ask. They'll raise a concern about technical debt before it becomes a crisis. Building a team of these people is the highest-leverage thing you can do as an engineering leader.
You won't know how good it was until you leave
I moved on to contracting after five years. Within a few months, working across different teams and codebases, I appreciated what we'd built in ways I couldn't see while I was inside it.
Not because it was perfect — it wasn't. But because I could see clearly what was hard about building maintainable systems at speed, and we'd done a lot of it well. The architecture held up. The CI/CD still worked. The codebase was navigable.
That felt like success. Not the metrics, not the valuation — the fact that what we built kept working.
I'm still learning what the right lessons were. Writing helps me think through it. If any of this resonates or contradicts your experience, I'd genuinely like to hear from you.