A leader's core job is defining and communicating the company's unique position, making trade-offs, and forging fit among activities.1 Not managing functions. Not overseeing operations. Strategy. For a founder, this means their highest-value work is reading the market, choosing what to build and what not to build, and turning those choices into a direction for the company. The closer they stay to that work, the better the business performs.
Strategic technical decisions are complex and the stakes are high. I work with founders and executives to navigate these challenges. Reach out if you'd like an outside expert perspective.
… or continue reading
Where does a founder's time go?
A founder's span of control is wide: customers, product direction, hiring, finance, fundraising, partnerships. Then there's engineering. The product needs to get built, and the founder needs to translate what they've learned from the market into something the engineering team can act on. That translation is expensive. Not in money, but in attention. Every conversation requires the founder to step out of their strategic world and into the engineer's more concrete, technical one.
Porter1 also wrote that "managers at lower levels lack the perspective and the confidence to maintain a strategy." That's not a criticism of engineers. It's a description of different altitudes. The strategic work can only happen at the top. Every hour the founder spends preparing work for the engineering team is an hour not spent talking to customers, thinking about positioning, or deciding which market changes to respond to.
Feed your strengths, starve your weaknesses. The founder's strength is market-to-strategy. The translation from strategy to engineering, while necessary, is not where their unique value lies.
Why the translation is so expensive
In a previous article, I described how work changes across organizational levels: from hands-on execution at the front line to long-range strategic thinking at the top. Each level involves a different time horizon, a different kind of complexity, and a different vocabulary.
The founder and the engineer are operating at different altitudes.
The founder's world is vision and direction. Where should this product go? What market are we serving? What does success look like in two years? Long time horizons, high ambiguity, many unknowns.
The engineer's world is concrete and immediate. How should this component be structured? What's the right way to handle this edge case? Can we ship this by Friday? Short time horizons, specific constraints, tangible outputs.
Both kinds of work are essential. But they require fundamentally different thinking and fundamentally different language. The gap between these altitudes is what makes every conversation between the founder and the engineer so costly. It's not a personality clash or a communication failure. It's a structural distance that takes real effort to cross every single time.
What this looks like in practice
Imagine a startup with two promising customer personas representing different industries. The founder sees these as potentially different products. The engineer sees shared infrastructure with some configuration on top. Both are looking at the same situation, but from completely different altitudes.
When this goes well, the founder says: "We have these different use cases. Can you help me figure out if we can build both at once, or do I need to prioritize one customer over the other?" And the engineer responds: "I think we could turn the differences into something configurable without much extra cost. But I'd need to understand how likely the other opportunities are before I invest in extensibility over a narrow implementation. Can you help me see which industries are most promising?"
When it goes poorly, the founder says: "Building two products is too expensive. Build this one narrow use case and forget the other exists." And the engineer says: "Sure, I'll implement exactly what you described. Let me know if you want something else later."
The good version is a real conversation across altitudes: both sides contributing what they know, asking for what they need. But notice what it cost. The founder had to step out of their strategic world and frame the problem in terms the engineer could engage with. The engineer had to ask business questions outside their usual domain. Both had to meet in the middle, and that middle ground doesn't come naturally to either of them.
And even after this conversation, the founder walks away uncertain. The engineer recommended the configurable approach, but is that the right call? The founder doesn't have the technical background to evaluate it independently. They're making a business decision based on a translation they have to take on faith. Do that three times a week, and the founder's confidence starts to erode. Not in the engineer's intentions, but in their own ability to steer the ship.
The poor version avoids that cost entirely. The founder made a technical assumption they weren't qualified to make. The engineer accepted a business decision without questioning it. It felt efficient. It wasn't. The result is worse for both.
Of course, the "right" answer depends entirely on the state of the code, the market conditions, the financial runway. That's exactly the point. These are judgment calls that require input from both altitudes. When the distance is too great, those calls get made with incomplete information, by whichever side happens to be holding the pen.
Getting the founder's time back
CTOs come in many shapes: deep technologists, engineering managers, product-minded leaders. There is no single definition of the role. But when the core problem is that a founder is spending too much time translating strategy downward, one particularly effective interpretation of the role emerges: the bridge.
A bridge role sits in the middle of the altitude spectrum. Close enough to the founder to absorb strategy quickly. Close enough to the engineer to translate it into their domain and their language. The founder doesn't have to descend to engineering altitude. The engineer doesn't have to guess at business context. Someone in the middle carries the translation.
Take the two-persona example. The founder explains the market opportunity and the trade-offs between industries. A CTO in a bridge role absorbs that in minutes, because they understand both the business logic and its technical implications. They then sit down with the engineer, already speaking in terms of architecture and trade-offs the engineer can evaluate. The engineer doesn't need to decode business strategy. They can focus their energy on researching the options and forming a recommendation.
The engineer presents their analysis back to the CTO, who condenses it into a targeted story for the founder: here are the options, here's what each costs, here's what I'd recommend and why. The founder gets a clear decision point without having to parse technical detail.
The founder's time goes back to the work that only they can do: reading the market, talking to customers, shaping the direction of the business. The engineer's time goes back to building. The bridge carries the translation, and everyone focuses on the work they do best.
Whether that bridge is a full-time CTO, a fractional one, or an experienced advisor matters less than you'd think. The structural gap doesn't care about employment contracts. It cares about whether someone is making the translation efficient.
What comes next?
The model I've described here focuses on one dimension: altitude, the distance between strategy and execution. But I mentioned earlier that the founder and the engineer also work in different domains. Those domains (engineering, product, sales, operations) each have their own version of the altitude spectrum, and the gaps between them add a second dimension that makes communication even more complex. A founder with a sales background talking to an engineer isn't just crossing an altitude gap. They're crossing a domain gap at the same time.
That's a story for the next article in this series. For now, the takeaway is simpler:
If you're a founder spending significant time translating your strategy into language your engineers can work with, measure the cost of that translation. Not just the hours, but what those hours could have been spent on instead.
The answer isn't more communication. It's a more efficient bridge.
Ivo Timmermans is the founder of Sparqpath, where he works as a fractional CTO and strategic technology advisor, helping companies build the translation layers that make collaboration work.