Your company needs consistent technical decisions over time, but may not need a full-time CTO today.
I work alongside founders, executives, and the engineering team to provide technical leadership: clarifying priorities, making or driving key technical decisions, evolving the architecture, and helping the team work more effectively.
The goal is not to make Cabestan indispensable. It is to provide the technical leadership the company needs today while progressively building the conditions for the team to operate independently.
This is probably a good fit if¶
- you have an engineering team, but no one clearly owns technical direction;
- a founder or executive is still carrying too many technical decisions and needs to step away from them;
- you are approaching an important stage — growth, hiring, architectural change, scaling operations, or due diligence — that requires greater technical maturity;
- you need senior CTO-level leadership now, without a full-time CTO hire being the right answer yet.
What I can take responsibility for¶
The actual scope depends on the engagement: these areas do not necessarily receive the same level of attention. At the start, we define the responsibilities Cabestan genuinely needs to carry.
Technical direction and decision-making
Turn business needs into technical decisions that are understandable, explicit, and owned. Architecture, technical debt, build vs. buy, platform choices, investment priorities, and trade-offs between speed, cost, and robustness can all fall within this scope. The goal is not for me to make every decision myself, but to ensure decisions are made at the right level and with enough context.
Team organization and ways of working
Ensure technical leadership does not depend permanently on one person, and help the team operate with greater autonomy. This can include responsibilities, the role of tech leads, decision-making processes, technical reviews, product/engineering collaboration, delivery practices, and hiring.
Production and technical risk
Give the company a sufficiently clear view of its production systems and main technical risks so they can be prioritized and addressed. Reliability, observability, infrastructure, costs, CI/CD, operational security, delivery capability, and incident management can all fall within this scope.
Support for executives and leadership teams
Give founders and executives a technical perspective they can use in their own decisions. Roadmaps, hiring, technical investment, conversations with customers or partners, due diligence preparation, and translating technical constraints into business considerations can all be part of the role.
How does the engagement start?¶
Understand the situation
I start by understanding the company, product, team, existing systems, and the decisions currently waiting to be made.
Clarify responsibilities
We define the areas where I need to provide technical direction, what remains within the team, and the corresponding level of authority. A Fractional CTO engagement needs enough authority to genuinely drive the decisions within its scope.
Establish a way of working
Meetings with founders, executives, and the team, decision-making, focused work, and support for technical leaders: we establish a rhythm that fits the situation rather than imposing a default calendar of meetings.
Adjust the level of involvement
The level of involvement is reassessed as the organization evolves. The aim is to progressively reduce dependency as the team becomes able to take on more responsibility.
What level of involvement?¶
The right level depends on the scope of responsibility, the maturity of the team, and the company’s situation. The two levels below describe a common trajectory, not two standardized packages to choose from.
Initial engagement
For context: capacity equivalent to roughly two days per week
The beginning usually requires greater involvement: understanding the context, building relationships with the team, picking up decisions already in progress, and establishing a sustainable way of working. This is not a number of days to consume.
An initial period of around three months is a useful reference horizon for establishing the engagement and assessing how it works in practice. At that point, we reassess the scope and level of involvement together. The engagement may remain at the initial level, move towards a steady state, or end if the organization is ready to take those responsibilities back internally.
Steady-state engagement
For context: capacity equivalent to roughly one day per week
A steady-state engagement becomes appropriate once the context is understood, responsibilities are better distributed, and the team can take on more decisions. Moving to this level therefore depends on the maturity reached, not on a predetermined date. This is not a number of days to consume either.
The engagement continues to be reviewed regularly. It may remain at this level, temporarily increase again, or end when the organization is ready to take those responsibilities back internally.
These levels of involvement are capacity guidelines, not days to consume or carry over. The monthly fee covers a scope of responsibility and the capacity required to carry it.
Experience spanning technology and technical leadership¶
Tech Lead / Engineering Manager · Head of Software Engineering · CTO / co-founder
My career has taken me from backend engineering to engineering leadership: Tech Lead and then Engineering Manager at Molotov, Head of Software Engineering at Wiremind, and CTO/co-founder of NuCorder.
This combination allows me to stay close to systems and engineering teams while working with executives on decisions that extend beyond a single technical project.
What the engagement does — and does not — cover¶
A Fractional CTO engagement covers technical leadership, decision-making, work with founders and executives, and support for the engineering team.
I can naturally get hands-on when it is useful to read code, prototype an idea, take part in a review, pair with an engineer, or understand a production problem directly.
The engagement is not intended to become recurring development capacity or to absorb a significant technical delivery project in parallel with the leadership role.
When a substantial implementation project appears, it can be handled by the internal team, entrusted to another provider, or require a different sequencing of responsibilities.
Availability and continuity¶
A Fractional CTO engagement requires continuity, not permanent availability.
Working time and important moments are organized with the team. Asynchronous exchanges between those times are a natural part of the role when they remain compatible with the agreed level of involvement.
The engagement does not include implicit on-call coverage or an SLA. If a critical period requires a specific arrangement, it is agreed explicitly.
Do you mainly need to understand the situation?¶
If an engineering team is not moving as effectively as it should and the problem does not appear to be purely technical, a Team & Organization Assessment may be a better fit than a Fractional CTO engagement.
I bring an external perspective to responsibilities, information flow, product/engineering interfaces, and decision-making to identify what is really slowing the team down and propose a path forward.
This is not Scrum coaching, an HR assessment, or an implementation mandate. You leave with a structured view of the situation, prioritized recommendations, and a path forward that you can act on with or without Cabestan.
Budget guideline: around €6,000 excl. VAT.
This is probably not the right fit if…¶
- you mainly need someone to produce code or work through a backlog;
- you already have effective technical leadership and mainly need focused expertise;
- you expect full-time operational presence;
- you need permanent on-call coverage or unlimited availability;
- you want to delegate execution without giving the role genuine technical decision-making responsibility.
Is your need instead a defined backend problem with a clear outcome?