I Never Planned to Become a CTO: What Quality Engineering Taught Me About Building Products
I didn't follow the traditional engineering leadership ladder. I started in quality engineering, learned to build products around real human pain, moved deeper into engineering systems, and eventually found myself responsible for the whole thing.
A few days ago I wrote about becoming CTO at Snap eHealth. The response was much larger than I expected. More interesting than the number of people who saw it, though, were the messages and emails that followed. People wanted to know how I got there.
It's a reasonable question because my career doesn't look much like the conventional path to CTO. I wasn't a software developer who became an engineering manager. I wasn't a Director of Engineering and then a VP of Engineering. I spent much of my career in Quality Engineering.
There was no ten-year plan behind that progression. I wasn't collecting titles or deliberately assembling a CTO résumé. Most of the important moves in my career happened because I found a problem that bothered me and kept following it until I understood the system underneath it.
Quality taught me to distrust the happy path
Good quality engineering isn't really about finding bugs. Bugs are the evidence. The more interesting question is why the system allowed the failure to happen.
Quality taught me to look at software differently. I learned to question assumptions, look for failure modes, explore the edges of a system, and pay attention to the difference between what somebody intended to build and what a person actually experienced.
Over time, finding the same classes of problems became less satisfying. If a regression suite took weeks to execute, I didn't want to become better at managing a weeks-long regression process. I wanted to know why we had one. If engineers repeatedly introduced the same type of defect, I wanted to know what was missing from the engineering system that allowed it. If releases were painful, adding more release process wasn't necessarily the answer.
That curiosity pulled me into automation. Automation pulled me into CI/CD. CI/CD exposed infrastructure problems. Infrastructure pulled me into AWS, containers, Kubernetes, observability, reliability, and eventually platform engineering.
At each step, the original problem turned out to be part of a larger system. Testing couldn't be separated from delivery. Delivery couldn't be separated from infrastructure. Infrastructure couldn't be separated from the developer experience built on top of it.
The most important thing I learned wasn't technical
That progression explains how I became a much broader engineer. It doesn't explain how I ended up leading technology.
The other part of the story is product.
Somewhere along the way I got really damn good at understanding consumer pain. I learned to look past what somebody asked us to build and understand what they were actually trying to accomplish.
That's a different skill from gathering requirements. A requirement might tell you that a user wants a button in a particular place. Understanding the pain means asking why they need the button at all. What are they trying to accomplish? What is frustrating them today? What decision are they trying to make? What unnecessary work have we forced them to perform?
Once I started thinking that way, product and engineering stopped looking like separate activities.
That sounds obvious, but engineering organizations get this wrong constantly. We can build technically excellent solutions to problems nobody particularly cares about. We can optimize architecture while the experience remains frustrating. We can deliver every requirement and still miss the reason the product needed to exist.
Learning to recognize that changed the kind of engineer I was becoming. I cared about architecture and reliability, but I also cared deeply about whether the thing we built made somebody's life better. Engineering became the mechanism for solving the problem, not the objective itself.
Platform engineering made the customer bigger
Platform engineering reinforced that way of thinking because suddenly the customer was often another engineer.
A developer waiting on an environment has pain. An engineer copying the same configuration between repositories has pain. A team trying to understand why a deployment failed has pain. Someone spending half a day figuring out how to launch a new service has pain.
You can respond to those problems with documentation and process, or you can treat them like product problems.
What is the developer trying to accomplish? Why is it difficult? Which decisions should the platform make for them? Which complexity can disappear behind a good interface? How do we make the safe path easier than the unsafe one?
That's product thinking applied to engineering infrastructure.
It also changed how I thought about leadership. Instead of optimizing a team or a technology in isolation, I became interested in the interfaces between them. Product, engineering, quality, infrastructure, security, and operations weren't independent functions. They were parts of the same delivery system.
I had to be willing to be bad at things again
None of this happened because I somehow accumulated expertise in every engineering discipline. Moving outside Quality Engineering meant repeatedly becoming a beginner again, usually while already being experienced enough to know how uncomfortable that was.
I had to ask basic questions about infrastructure. I had to build things that more experienced platform engineers could have built better. I had to learn cloud architecture, Kubernetes, networking, reliability, system design, and eventually a much broader set of product and organizational concerns.
There is a temptation once you're good at something to stay close to the things that prove you're good at it. Starting over removes that protection. You go from being the person with answers to the person asking questions everyone else seems to already understand.
But almost every major expansion in my career required exactly that.
I still do it. Becoming CTO didn't suddenly make the unknowns disappear. It dramatically increased their surface area.
Leadership means making the people around you better
There is another part of becoming a CTO that has very little to do with technology.
At some point, your own output stops being the most important measure of what you're accomplishing. The people around you become the multiplier.
I've come to believe that one of the most important jobs of a leader is to lift people up. Give them real ownership. Teach what you know. Listen when they know something you don't. Create opportunities for people to stretch beyond what they think they're ready for, and then give them enough room to figure it out.
That also means allowing people to fail.
I don't mean allowing reckless mistakes or putting customers, security, or the business at unnecessary risk. Leadership includes creating boundaries around consequential decisions. But if I prevent someone from ever making a wrong decision, I've probably also prevented them from learning how to make difficult decisions on their own.
I expect the same thing from myself.
I don't have much use for starting with why something can't be done. I'd rather understand what would have to be true to make it possible, try something, learn from what happens, and adapt.
Sometimes that means being wrong.
That's part of the job.
I want people around me who will tell me when I'm wrong. I want to listen when someone understands a problem better than I do. I want ideas to win because they're good ideas, not because of the title of the person who had them.
Ego is incredibly expensive in engineering. It makes people defend bad decisions, hide mistakes, stop asking questions, and ignore better ideas because they came from somewhere else.
I'd rather lead a team that is unafraid to experiment, challenge me, learn, adapt, and occasionally get something wrong than one that waits for me to have every answer.
The goal isn't to be the smartest person in the organization.
The goal is to build an organization full of people who are becoming better because you led them.
The system kept getting bigger
Looking backward, there is a much cleaner story than there was while I was living it.
Quality Engineering taught me to understand failure. Automation taught me to remove repetitive work. Platform engineering taught me to think about the systems that enable engineers to work. Product taught me to understand the pain underneath what people say they want. Leadership taught me that my job wasn't simply to solve bigger problems myself, but to build a team capable of solving them together.
Eventually those ideas started converging.
Today the questions I'm interested in are larger. How should an engineering organization work? How do architecture and product strategy reinforce each other? How much coordination can we remove? Where should humans retain explicit authority? How should AI change software delivery? How do we build systems that allow engineers to move quickly without treating security, reliability, or quality as somebody else's problem?
And how do I build an organization where talented people have enough trust, ownership, and support to become better than they were when they arrived?
Those may sound like CTO questions, but to me they don't feel fundamentally different from the questions that interested me in Quality Engineering. The boundary of the system changed.
I don't know that my career is a path anyone should try to reproduce. It certainly wasn't designed to be one. There are much more conventional ways to become a CTO.
But I also don't think my path was as strange as it first appears.
I started by trying to understand why software failed and how that failure affected the person using it. Then I kept moving outward: the test system, the delivery system, the infrastructure, the product, the engineering platform, the people building it, and eventually the organization responsible for all of them.
I never planned to become a CTO.
I just kept following the problem.