How it works

What actually happens, month by month

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

What you would actually start with

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.

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.

Release reliability review

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.

Delivery planning review

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 call is free. The review is the work.

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

Establishing what is really happening

The first month ends with an agreed set of priorities, a baseline you can measure against, and clear decision rights.

  1. First conversation and fit

    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.

  2. Discovery

    Product, architecture, delivery, people and business priorities examined together rather than in isolation, because the bottleneck is rarely where it first appears.

  3. Baseline and risk assessment

    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.

  4. First thirty-day priorities

    A short, ordered list of what gets attention first, agreed with you rather than presented to you.

  5. Decision rights and cadence

    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

After the first month

Intensity varies with scope, risk and team size. The rhythm does not.

  1. Technical and organizational roadmap

    A roadmap covering both the technology and the organisation that has to build it, sequenced so each step makes the next one possible.

  2. Weekly leadership and coaching

    Working directly with your engineering leads and managers each week: design reviews, coaching, unblocking decisions, and escalation when something needs it.

  3. Monthly progress and risk reporting

    A written report to management covering what moved, what did not, which risks changed, and what needs a decision. Evidence rather than assurance.

  4. Continuous reprioritization

    Priorities revisited with management as the business changes. The roadmap is a working document, not something agreed once and defended afterwards.

  5. Engagement review and renewal

    At the end of the term we review what changed against the baseline and decide together whether to continue, adjust the scope, or conclude.

Who does what

Kendoo is accountable for

  • Technical direction and architecture decisions
  • The order of work, judged by business consequence
  • The delivery system and how work reaches production
  • Coaching your leads and managers
  • Surfacing risk in writing, monthly
  • Saying so when the engagement is not the right answer

You provide

  • An executive sponsor who attends the cadence
  • Access to the team, the system and the data
  • Willingness to change priorities when the evidence says so
  • Decisions that remain yours, made in reasonable time
  • Tolerance for honest reporting, including bad news
  • For retained leadership, a commitment of at least six months

Commercial boundaries

A retainer, not an hours bank

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

What you actually receive

  • A written baseline and risk assessment in the first month
  • An agreed decision-rights and cadence document
  • A technical and organizational roadmap
  • A monthly written progress and risk report
  • Architecture decisions recorded with their reasoning
  • An end-of-term review against the original baseline

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.

See whether the cadence fits your organisation

Thirty minutes on your situation, and a straight answer about whether this engagement fits.