Avoiding the CTO Trap
Why product > perfection and business outcomes > abstractions
A few days ago, a founder CTO asked me what advice I’d give them as they scale. This is what I told them. And it’s what I wish someone had told me earlier.
After nine years as a founding CTO across two venture-backed startups, I’ve seen the role get misunderstood over and over, including by me, early on. It’s not about being the most senior engineer. It’s about being the connective tissue between technology and the business.
The best CTOs are commercial. They push for work that drives business value. They advocate for building what helps the company grow or operate more efficiently, not for rewriting the codebase in Go because it’s faster, or refactoring something that’s annoying but functional. Unless it’s existential, that work can wait (maybe forever).
This might piss off some engineers, but tech debt doesn’t matter as much as we pretend it does. Moving to microservices is a mistake for 99 percent of startups. And “cleaning things up” is not a good reason to slow down the business.
At my last company, Modern Life, I did my best to only hire what I think of as product engineers instead of architects. Not a title—a mindset. Product engineers think about users. They’re focused on growth, retention, and business value. They care less about elegant abstractions and more about minimal, effective solutions that ship.
You don’t earn your keep by building beautiful systems. You earn it by helping the business increase revenue or reduce costs. That’s it.
Too many CTOs sit out of commercial conversations. I’ve done it myself. I’ve watched deals fall apart and marketing stall while I stayed focused on roadmap velocity. That was a mistake. I’m not saying I could have singlehandedly saved the company, project, or initiative—but CTOs should be doing everything they can to help the business succeed, not hiding in a technical sandbox.
You don’t need to run sales or own marketing. But you should know where the business needs help. Sometimes your highest-leverage work won’t be a product feature. It might be fixing attribution. Or getting sales the tool they need. Or helping finance make better decisions with better data.
That’s the job. Not just building. Understanding the company broadly and making it better.
One last thing. The standalone CTO role is often overrated. It can become technical middle management with a fancy title. You translate timelines and justify complexity to people who don’t care. Don’t let that happen just because it’s the path of least resistance. I get it, engaging deeply across functions is a lot more work, especially when no one is asking for it. Welcome to being a leader.
If you really want to build a great company, don’t just be a tech leader. Be a product and business leader who deeply understands technology. Think Bret Taylor, not the person who owns the Jira board and complains that leadership won’t prioritize test coverage.
If you’re going to advocate for any kind of work, make sure it’s the highest-leverage thing your team could be doing. Otherwise, stop.
And if you find yourself arguing for a rewrite no one asked for, take a walk, drink some water, and ask sales what’s actually broken.
Great post, Jack. The "product engineer vs architect" distinction really hits home.
I've seen too many CTOs get seduced by technical elegance when the business is bleeding from a thousand small operational cuts. Your point about attribution tracking or getting sales the right tools often being higher leverage than another feature - spot on.
The hardest part is that engineers (rightfully) want to work on interesting technical problems, but the most valuable work is often boring integration stuff or fixing someone's manual Excel process. Managing that tension while keeping the team motivated is the real skill.
Also love the Bret Taylor reference. The best technical leaders I know spend way more time in Slack with sales and customer success than they do in code reviews.
One thing I'd add: sometimes the highest-leverage technical work IS paying down debt, but only when it's actually blocking business velocity. The trick is being honest about whether that refactor really enables faster shipping or if it just makes you feel better about the codebase.