Interim CTO: How do you steer Tech when everything is shaking?

In the startup and scale-up ecosystem, we often picture the CTO (Chief Technology Officer) as a visionary architect building on a blank canvas. Simon Tannai's reality is radically different. Simon doesn't show up to admire stable systems; he arrives when the engine is smoking, the crew is divided, and the leadership team has lost its bearings.

Being CTO when nothing is stable means accepting that code is only a tiny part of the equation. Here are the management and tech strategy lessons from his journey.

The CTO as a "backup system": Why do you call one in?

Calling on a freelance or interim CTO is never a comfort choice. It's a response to specific structural breakdowns:

• The forced transition: A long-tenured CTO leaves, creating a leadership void that hiring (often a 6-month process) can't fill immediately.
• The social fracture: A team of developers "at war" with leadership that doesn't understand the technical stakes.
• Forced acceleration: A need to scale at a moment when tech is being challenged and trust has been weakened.

For Simon, the mission isn't about "doing tech" for art's sake. His credo is pragmatic: "What I'm passionate about is solving business and organizational problems, but with tech."

Tech is a Business: The school of constraint

Simon's approach was forged in web agencies, where budgets are tight and deadlines non-negotiable. That's where he absorbed a fundamental truth: web development is a business function.

"Perfect" code that arrives too late or costs too much is a failure. The value of a technical solution is measured by its ability to last over time, to be maintained by the team in place, and to withstand the pressure of the product roadmap. His instinct? Reason in trade-offs rather than ideals.

The diagnosis: Stack conflicts often mask human crises

Watching consultancies and startups, Simon noticed a recurring pattern: when a team slows down, the tool (the tech stack) is often blamed, when the real problem is organizational.

• Fuzzy responsibilities.
• A poorly shared product vision.
• Engineers disconnected from financial stakes.

An effective CTO doesn't pick between React or Vue; they make the trade-offs intelligible so the CEO and the developers finally speak the same language.

Walking onto a "battlefield": The first two weeks

When he comes in after a sudden departure, Simon takes the stance of an observer. His golden rule? "The first two weeks: zero code."

Before opening an IDE, you have to take care of the human side. He meets each developer one-on-one to understand the frustrations. Often, the stories conflict. His role is then to recreate a neutral decision-making framework.

Technical legitimacy: speaking the engineer's language

If the role is human, it requires a strong technical backbone. You don't earn a senior developer's trust with vague management concepts.

"How do you earn an engineer's trust? By talking to them like an engineer."

This legitimacy lets him objectivize debates, detect the "real" technical debt issues, and prevent decisions from becoming purely political.

The technical migration as an organizational symptom

Simon cites the example of a migration from PHP to Node.js. You might think it was a stack choice. For him, it was a response to a recruiting and attractiveness problem. The stack wasn't the problem — the company's ability to move forward was hampered.

Every architecture change has to be tied to a concrete benefit for the company:

1. Faster delivery (Time-to-Market).
2. Better scalability.
3. Easier hiring.

The ultimate goal: Make yourself unnecessary

This is probably the most counterintuitive point of Simon's journey: a successful engagement is one that ends.

He defines success by the team's full autonomy:

• When quality standards are baked in.
• When architecture discussions no longer need a referee.
• "When I have nothing left to say in code review."

For an interim CTO, sticking around for comfort is a professional failing. The freelancer's real asset is their ability to stabilize a system, then pass the baton to a permanent CTO under healthy conditions.

Building Givematic: tech in service of philanthropy

Today, Simon co-founds Givematic (formerly 3615assos). The starting observation is typical of his approach: billions of euros sit dormant in philanthropic funds for lack of simple tools to distribute them.

The challenge here isn't so much the user interface as the regulatory and financial complexity. Banks can be wary of non-profit structures. Once again, Simon solves a structural problem (the flow of donations) with an agile technological response.

Conclusion: Simon Tannai's definition of a CTO

What is a CTO, in the end? "It's the title you're given when you have to find solutions."

It's a role of total responsibility. Responsible for the alignment between what the company wants to sell and what the machines can produce. In a world where nothing is stable, the CTO is the one who brings clarity.