“All progress depends on the unreasonable man,” wrote George Bernard Shaw, and anyone who has sat beside a founder knows exactly who he meant. The asks are ambitious, the timelines are worse, and every engineering instinct says to push back. But if you’re the CTO, the unreasonableness isn’t a problem to fix. It’s the job.

Unreasonable is a feature

Founders are paid to see a version of the business that doesn’t exist yet. If they only asked for what engineering already believed was achievable, the company would be capped by the imagination of its most cautious function. When a CEO asks for something in six weeks that you estimated at six months, it’s rarely ignorance. It’s a signal about what matters, often delivered with all the subtlety of a brick. As an executive, your role is to work backwards from that challenge and try to solve it.

The reasonable response, “that’s not possible”, is also the least useful thing a technology leader can say. It ends the conversation at the exact moment it should start. A better answer sounds like: here’s what we can have by then, here’s what it costs, and here’s what we stop doing to get there. That turns a demand into a decision, and decisions are what executive teams are for.

Spar for the business, not your team

A CTO is one of the few people in the room with both a whole-of-business view and enough technical depth to call bluffs in either direction. That’s what makes sparring valuable, and good founders want it. They’re surrounded by people who tell them what they want to hear. So argue hard, bring data and put real options on the table.

But be honest about what you’re arguing for. Engineering leaders often confuse protecting their team from load with protecting the company. Patrick Lencioni’s idea of the “first team” applies here: your primary loyalty is to the executive team you sit on, not the function you run. If your pushback survives the question “is this best for the business?”, make it loudly. If it only survives “is this best for engineering?”, think again.

Understand the why before you commit

You’ll lose some of these arguments, and you should. A CEO who never overruled their CTO would be a strange one. When it happens, the work isn’t over. Find the real reason behind the decision, not just the stated one. It might be board pressure, a competitor’s move, a runway calculation or a promise made to a key customer. Often the why makes the decision make sense. Sometimes it reveals your CEO knows something you don’t.

And sometimes you’ll still disagree. That’s fine. The point of understanding isn’t to be persuaded. It’s so you can carry the decision honestly.

Commit, and own the message

Amazon codified this as “have backbone; disagree and commit”, and the second half is where most leaders fall down. The failure mode sounds like “leadership has decided” or “I argued against this, but the CEO wants it”. It feels candid. It’s actually corrosive. It tells your team the exec team is divided, gives them permission to half-commit, and quietly casts you as the good guy at your CEO’s expense.

Committing means standing in front of your team and saying “we’re doing this, and here’s why it matters” in your own voice, with the conviction you’d bring to a decision you championed. Integrity doesn’t require pretending you loved the idea from the start. If someone asks, you can say it was debated. But once you’ve committed, “we decided” is the only honest framing.

If you can’t say it with conviction, treat that as information. Either you haven’t truly understood the why, or the disagreement is about values rather than trade-offs. The first is fixed with another conversation. The second is a different conversation entirely, possibly about whether you’re in the right seat.

The supporting role

In a founder-led company, the CTO is rarely the protagonist. The founder is the unreasonable one, trying to bend the world to an idea. The CTO’s job is to make sure the world can actually bend: telling the truth about what it costs, fighting hard in the room, then carrying the outcome as their own. Supportive isn’t the same as submissive. The best measure of success in the role is simple. Your CEO stops wondering whether engineering is on board.