Company Transformation

Most of what I do works at the level of one team, one leadership group, or one codebase. Sometimes the useful unit is larger, and this is the service for those times.

It usually looks like this. You have a dozen teams at genuinely different stages. One or two have found something that works and would struggle to say what. Tooling decisions have been made in more than one place. There is a number in front of the board. And what would help most is not more tooling but a shared idea of what good looks like, so that what one team learns reaches the others.

None of that is a sign of a badly run organisation. It is what happens when capable teams solve a new problem in parallel, which is what you would want them to do.

What is different at this scale

The pieces are the same work I do elsewhere: assessment, practice change, architecture, leadership alignment. What changes is that what to do stops being the hard part and what order to do it in takes over, along with who needs to be confident before the next phase starts. It runs over quarters, involves people well outside engineering, and turns on organisational questions more often than technical ones. That is why the assessment looks at how decisions get made, not only at how code gets written.

What you get

• A clear picture of where you are, team by team, against evidence rather than self-assessment. It often finds strength where nobody was looking.
• Agreement on what better means, written down first, with a baseline, so at the end there is something to point at.
• Practice that holds without me. Working agreements and guardrails your teams run themselves.
• People who can carry it, so the capability compounds rather than depending on a contract.
• Architecture that can take the change, which is what decides whether more output becomes leverage.
• Progress you can see while it happens, not in a retrospective afterwards.

Where I am careful

I will not put a productivity percentage in a proposal before seeing your codebase, because any number I chose would be chosen to win the work. I do not take on engagements framed around reducing headcount. Teams often dip before they improve, since judgment about what to delegate takes a while to build, and it helps to expect that. And teams will not all land in the same place, which is fine: for some of them, where they are is the right answer.

How it starts

With an assessment, never with a programme plan. I would rather not propose several quarters of work before knowing what is true about your teams.

The assessment is bounded, has its own deliverable, and is yours either way. If it turns out two teams want coaching and the rest are doing well, that is a good result and I will say so.

Pricing

The programme is scoped per engagement, because any figure printed here would be wrong for most organisations reading it. The assessment is bounded work with a fixed deliverable, so it has a price.

Assessment

Priced by number of teams, because that is what the work scales with. A team is a team whether it sits in a forty-person company or a four-hundred-person one.

Component	Price
Base: leadership interviews, delivery baseline, findings, phased roadmap	€6,000
Each team assessed	€900

Six teams is €11,400, ten is €15,000, fifteen is €19,500. You can work your own number out before we speak, which is the idea. Above fifteen teams a representative sample tells you more than interviewing everybody and costs less, so that is scoped individually.

You keep the maturity placement, the delivery baseline, the findings and the roadmap whether or not we carry on together.

All prices exclude VAT. Travel within the Netherlands is included; elsewhere it is billed at cost.

The programme

Six questions shape it, and they are roughly the first conversation:

• How large is engineering? The difference between thirty and four hundred is the number of boundaries a change has to cross.
• Startup or established organisation? One decides on Tuesday and runs it on Wednesday. The other has procurement, works councils and a governance calendar.
• How many engineers need onboarding? Everyone, or two pilot teams first? This moves the effort more than anything else.
• How much of my time, and how spread out? Two days a week for a quarter, or one day a month for a year.
• What is already in place? Clean boundaries and a strong review culture take a fraction of the work.
• Who needs to be confident first? If leadership is aligned, we start with the teams.

So: a conversation, then an assessment, then a phased proposal with real numbers. Each phase priced separately, and you can stop after any of them.

If you would like a sense of my rates first, the masterclass is published with fixed pricing.