Firestarter

I step into complex projects when things stop moving. Find the real constraint, remove structural friction, and help the system start working again.

Sometimes as a strategist. Sometimes as an interim lead. Sometimes hands-on.

The role is defined by the problem — not by a title.

I work where execution is blocked

Most projects don't fail because people are incompetent. They fail because systems become unclear, overloaded, or politically stuck.

At that point the problem is no longer technical — it becomes structural.

That's where I usually step in.

My work is to identify the real constraint in the system and restore the ability to move forward.

Where I step in

1. Starting from zero

Early-stage projects often move fast but lack structure. This works for a while — until decisions begin to conflict and execution slows down.

Typical work:

  • defining a clear execution model
  • aligning stakeholders around real priorities
  • separating product vision from operational noise
  • building the minimal structure needed to move fast without chaos

Goal: a system that can execute consistently, not just improvise.

2. When a system becomes stuck

Many teams reach a point where effort grows but results stop improving.

This usually means the system accumulated friction:

  • unclear ownership
  • architectural debt
  • decision bottlenecks
  • political noise

Typical work:

  • identifying the real constraint
  • simplifying architecture and responsibilities
  • restoring decision velocity
  • resetting the execution model

Goal: remove friction so the system starts moving again.

3. Launching a new direction

Sometimes a company needs to open a new direction while the main system keeps running.

Typical work:

  • isolating the new initiative from legacy noise
  • defining structure and ownership early
  • building a minimal execution framework
  • stabilizing the first stage of growth

Goal: launch something new without breaking the existing system.

How I work

I don't sell predefined roles.

When entering a project, the first task is always diagnosis.

In most cases I spend the first weeks understanding:

  • where decisions are actually made
  • where the real constraint lives
  • what structure already exists
  • which parts of the system should stay untouched

Only then the role becomes clear.

Sometimes that means acting as a strategist. Sometimes as interim leadership. Sometimes temporarily helping execution.

The goal is always the same: restore a system that can move without constant intervention.

What I don't do

I'm usually not the right person if:

  • the goal is to maintain the current process rather than change it
  • the team is looking for validation rather than diagnosis
  • decisions are expected to be avoided rather than made
  • the organization prefers meetings over execution

My work only makes sense when there is real willingness to change the system.

Background

I've spent more than two decades working inside complex technical organizations.

My work has included:

  • building and restructuring engineering teams
  • leading R&D directions
  • designing system architecture and execution models
  • helping projects move through difficult transitions

I'm comfortable moving between strategy and technical depth, and stepping into unstable environments where structure is missing.

Typical engagement formats

Fractional involvement

Regular strategic participation while the system stabilizes.

Focused intervention

A limited period to identify constraints and reset execution.

Architecture and system review

Independent structural diagnosis and recommendations.

The exact format depends on the situation.

Contact

If you believe your project needs a structural reset, or if execution feels harder than it should be —

let's talk.

[Email] [LinkedIn / Telegram]