Modernization review
Produces a risk map of the system, a proposed sequence of changes, and clear recommendations on what to keep, what to replace, and what needs more investigation before anyone decides.
How it works
Consulting sounds abstract until you can see the operating model. Here is the first month, the ongoing rhythm, and what is expected from your side, whichever service line the work sits in.
Where to start
Most work begins with one focused review of the problem that matters most. Each one ends with written findings you can act on, whether or not a longer engagement follows.
Produces a risk map of the system, a proposed sequence of changes, and clear recommendations on what to keep, what to replace, and what needs more investigation before anyone decides.
Produces a map of how a change reaches production today, where the manual effort and the repeat failures concentrate, and a ranked list of fixes with the first ones to make.
Produces a view of the team's real capacity against the roadmap, the work waiting on decisions and who owns each one, and a re-sequenced plan the team can commit to.
The first conversation costs nothing and is about fit: what is happening, and whether any of this would move it. Producing findings like those above takes real time with your team, your system and your data, so a review is scoped work, with its scope and price agreed before it starts.
Success is measured against what the problem actually costs you: the effort a deployment takes, how often the same incidents return, the time to bring a new site or customer online, how much work sits waiting for a decision, or the support volume a product generates. The baseline is measured first, and targets are agreed against it, not promised before anyone has looked.
The first thirty days
The first month ends with an agreed set of priorities, a baseline you can measure against, and clear decision rights.
Before anything is signed: your situation, what is at stake, and which kind of work would actually move it. Sometimes none of ours would, and you will be told so on the call.
Product, architecture, delivery, people and business priorities examined together rather than in isolation, because the bottleneck is rarely where it first appears.
A written baseline of what is being delivered and how long it takes, with risks ranked by what they would cost the business rather than by how interesting they are.
A short, ordered list of what gets attention first, agreed with you rather than presented to you.
In writing: which decisions Kendoo makes, which stay with you, which need both, and how often we meet. Ambiguity here is the single most common reason fractional leadership fails.
The ongoing rhythm
Intensity varies with scope, risk and team size. The rhythm does not.
A roadmap covering both the technology and the organisation that has to build it, sequenced so each step makes the next one possible.
Working directly with your engineering leads and managers each week: design reviews, coaching, unblocking decisions, and escalation when something needs it.
A written report to management covering what moved, what did not, which risks changed, and what needs a decision. Evidence rather than assurance.
Priorities revisited with management as the business changes. The roadmap is a working document, not something agreed once and defended afterwards.
At the end of the term we review what changed against the baseline and decide together whether to continue, adjust the scope, or conclude.
Commercial boundaries
Retained leadership engagements run six to twelve months, because leadership that changes how an organisation works cannot be bought by the hour. There is no pool of hours to draw down and no per-task billing, which means no incentive to make the work look larger than it is.
Intensity varies with scope, risk and team size, and is agreed before the engagement starts rather than metered afterwards.
Pricing is discussed on the call, against the actual scope. It is not published, because a number without a scope attached is meaningless to both of us.
Some work does not run this way. Team dynamics workshops are booked on their own, as a session or a short series with the team that has the problem. Software R&D is scoped to the piece of work and priced against it, under the same technical leadership rather than as a body shop. Where the question is narrow, a short, tightly scoped review is possible too.
What does not fit any of these is an hours bank, per-task billing, or a few hours of advice. That will be said plainly rather than accommodated badly.
Deliverables
Those are the retained-leadership deliverables. A workshop leaves the team with its own materials and a written summary; a software R&D engagement leaves working software, its architecture decisions and the people who can maintain it.
Thirty minutes on your situation, and a straight answer about whether this engagement fits.