Operating models rebuilt at scale, answered in full.

It works, and HSBC is the proof we point to. The CIO's executive team had no shared mechanism to track strategic initiatives across 150+ teams, so James ran the group the way a Scrum Master runs a squad: a live Kanban of all work and dependencies, daily executive stand-ups, and a review and planning cadence that gave technology, operations and transformation a common language. Decision speed improved sharply and annual planning finished ahead of schedule for the first time in years. The ceremonies scale up well; what changes is the size of the decisions moving across the board.

The same job as at team level, aimed at bigger blockers. At HSBC, James designed a lightweight governance model around a live Kanban showing all work, planned initiatives and dependencies. He ran the daily executive stand-ups. When something was in the way he went and removed it himself, and he set a review and planning cadence that gave technology, operations and transformation one language for progress. Judge the role by what stops sitting still. Blockers that had persisted for weeks were routinely cleared in days, and C-suite visibility across a $102M operating budget went from poor to live.

They have time for the alternative even less. Before the daily rhythm, HSBC's executive team was losing weeks to blockers that persisted without escalation and to milestones slipping quietly out of view. The stand-up ran against a live Kanban of initiatives and dependencies, and it turned that around. Blockers that once took weeks were routinely cleared in days and decision speed improved sharply. A daily meeting that exists to clear obstacles pays for itself the first time it saves an initiative a fortnight of drift. At HSBC the cadence stabilised delivery around it.

Not with more reporting. At HSBC, 150+ global teams and a $102M operating budget sat in scope with no shared mechanism to track strategic initiatives. The answer was one live Kanban holding all work, planned initiatives and dependencies, wrapped in a deliberately lightweight governance model. The executive rhythm then ran on that board every day. Nobody was reconciling status decks for it. C-suite visibility increased and delivery cadence stabilised. You want one source of truth that stays current because leadership works from it, and not a reporting layer that goes stale between steering committees.

It overruns because the cycle starts without knowing the current state. Initiatives are untracked, dependencies are invisible, blockers are unresolved, and so the first weeks go on reconstructing reality before anyone can decide anything. At HSBC the fix was structural. Once the executive team had a live Kanban of all work and dependencies, daily stand-ups and a standing review and planning cadence, annual planning completed ahead of schedule for the first time in years. Planning got faster because the inputs were visible and already agreed before the planning window opened.

Escalate them daily, in a room where the people who can remove them are present. At HSBC, blockers persisted for weeks because nothing surfaced them and nobody owned their removal. The model James installed put them on the executive team's live Kanban and raised them at a daily stand-up in front of the CIO's leadership group, with someone in the room whose job was to go and remove obstacles directly. Under that rhythm, blockers that once took weeks were routinely cleared in days. Most blockers are not hard problems. They are unowned ones.

Three months, in the engagement this page describes. That covered designing the lightweight governance model, standing up the live Kanban of initiatives and dependencies, embedding daily executive stand-ups and establishing the review and planning cadence, all inside a function of 150+ global teams and a $102M operating budget. The results landed in the same window. Decision speed improved sharply, blockers that had taken weeks were cleared in days, and annual planning finished ahead of schedule for the first time in years. Executive habits change faster than organisational ones, because the group is small and it meets every day.

By making the work visible and the rhythm reliable, then letting results do the persuading. At HSBC, confidence in the function's ability to deliver had eroded. Milestones slipped, blockers sat unescalated, and the CIO's executive team had no shared view of critical initiatives. James put every initiative and dependency on one live Kanban, ran daily executive stand-ups against it, and removed obstacles directly. Within three months alignment and decision speed had improved sharply and delivery cadence had stabilised. Confidence follows evidence. A leadership team that can watch delivery happening stops needing to be reassured about it.

Because you are buying the person as much as the company. James Rooney leads every Tenhaw engagement personally, so what he delivered inside HSBC's executive team in his own delivery and transformation career is direct evidence of what you get. This study is founder track record rather than work delivered under the Tenhaw banner, and James is named throughout it because the work was his. Engagements such as Anglo American, Yondr and Greggs were Tenhaw deliveries; HSBC was James inside the bank. We will walk through which is which on a call if the distinction matters to your procurement.

Everything except the technology. Agentic transformation lives or dies in the executive room, and this engagement installed what an Embedded Agentic Lead installs at the top of an agentic programme. Visible work on one live board, fast decisions at a daily cadence, and accountability that holds. So the evidence here is that James has run that operating discipline inside the executive team of a global bank, and that is the room where an AI programme's funding, priorities and blockers get decided.

It needs a rhythm it can be run on, and not just sign-off. A banking AI target operating model usually arrives well argued and then stalls in the executive layer, because that is where the money and the priorities really move. At HSBC, the CIO's executive team had no shared mechanism for tracking critical strategic initiatives across 150+ global teams and a $102M operating budget. Operating effectively as a Scrum Master for that team, James put every initiative and dependency on one live Kanban, ran daily executive stand-ups and removed obstacles directly. Decision speed improved sharply and blockers that once took weeks were cleared in days. Three months in, annual planning finished ahead of schedule for the first time in years.

Put the dependencies where both can see them, then give both the same cadence. At HSBC, the CIO's executive team had no shared mechanism for tracking critical strategic initiatives, so milestones slipped and blockers sat unescalated in the gaps between functions, owned by neither. James built the fix around one live Kanban of all work, planned initiatives and dependencies, daily executive stand-ups, and a review and planning cadence that created a common language across technology, operations and transformation. Decision speed improved sharply, delivery cadence stabilised, and blockers that once took weeks were routinely cleared in days. Functions rarely fall out over priorities. They fall out over dependencies nobody could see.

The overlap is real, and the difference is that one is a post and the other is a mechanism. A chief of staff is a permanent role built around a single leader. What James installed at HSBC was a small set of artefacts the executive team itself ran on: a live Kanban of all work, planned initiatives and dependencies, daily executive stand-ups, a review and planning cadence that gave technology, operations and transformation one language, and someone removing obstacles directly rather than logging them. Three months in, blockers that once took weeks were clearing in days and annual planning finished ahead of schedule for the first time in years. Install the rhythm first, then decide who holds it permanently.

Give it one job. The stand-up exists to move work that is stuck, and at HSBC it ran against a live Kanban holding all work, planned initiatives and dependencies, so nobody spent the meeting reporting a position everyone could already see. The governance model around it stayed deliberately lightweight, so it never became a second reporting layer. The other half is accountability. Obstacles were removed directly, so raising one led somewhere, and the group judged itself on movement instead of attendance. In that function, blockers that had persisted for weeks were routinely cleared in days, decision speed improved sharply and delivery cadence stabilised. A meeting that has changed nothing by Thursday is a status round, whatever it is called.

At Tenhaw's published pricing that shape of work is Programme and Delivery Management, £18k–£35k a month, bought on its own with no requirement that Tenhaw builds any of the programme. The figures come off a published rate card: partner £1,560 a day, senior practitioner £1,250, associate £950, excluding VAT, at twenty billable days a month. The HSBC engagement predates Tenhaw and was James inside the bank in a delivery and transformation role, so read the price as what the same three months would be sold at today. Every month is expected to deliver measurable value, and a month that delivers none is reported as a failed month.

A six-month engagement to make Yondr's global digital delivery predictable enough to plan around. Teams across the UK, USA and Singapore were delivering erratically. We introduced Story Point estimation recalibrated against real capacity, and we embedded the agile ceremonies that were missing: retrospectives, planning and active backlog management. Within three months the development teams were producing consistent output every sprint, and by six months that predictability had reached the support and security teams too. Yondr could plan beyond a single quarter for the first time.

Because its global digital teams delivered inconsistently, and you cannot plan around output you cannot predict. The unpredictability was most damaging in the UK and USA, where reliable delivery was critical to scaling data centre operations. Nobody could say with confidence what a team would finish in a sprint, so any commitment beyond the current quarter was a guess. Fixing that was the whole engagement. Once output became consistent sprint after sprint, the planning horizon extended with it, first for development and then across support and security.

Three months at Yondr to get the development teams producing consistent output every sprint. Six months for that predictability to reach the support and security teams. That is a realistic shape. Estimation only becomes accurate once it has been recalibrated against a few completed sprints, and ceremonies like retrospectives and backlog management compound rather than pay off instantly. Anyone promising a predictable delivery organisation in a fortnight is describing a report, not a change in how the teams actually work.

Yes. The Yondr engagement ran remotely across the UK, USA and Singapore, with on-site workshops where being in the room helped. Three regions made remote-first a necessity. It worked because everything the method relies on is a visible artefact. Estimates get corrected against completed work. Backlogs are managed in the open where anyone can see them, and every ceremony leaves behind an output the whole team can read. Within three months of working that way, the development teams across those regions were producing consistent output every sprint.

Because you cannot state an automation improvement in a system whose human throughput nobody can currently state to within a factor of two. If a team's output swings unpredictably, any claim that AI made it faster is unmeasurable. The Yondr engagement is what getting to that baseline looks like. Consistent sprint output within three months, and support and security on the same footing by six. The payoff does not wait for the AI either. For the first time the business could plan holistically, where before it had never seen past the current quarter.

Adjust the estimate after the work is done. That one habit turns estimation from optimism into measurement. Most teams estimate, deliver something different, then never close the loop, so the next estimate inherits the same error. At Yondr we recalibrated Story Points post-completion to reflect the capacity each team had actually demonstrated, and that feedback loop is a large part of why development output became consistent within three months. The aim is not better guessing. It is that the numbers you plan with start to describe the team you actually have.

They can. At Yondr predictability started with the development teams, who reached consistent sprint output within three months, and by six months it had reached support and security too. The mechanics do not change with the function. Make the work visible. Correct the estimates against what actually got completed, and hold planning and retrospectives on a regular beat. Extending it beyond engineering mattered because a business plans across all of its functions, and predictable development sitting next to unpredictable support still leaves leadership guessing. Only once all three were predictable could Yondr plan holistically.

Yondr is one of the engagements delivered under the Tenhaw banner, alongside Anglo American, Greggs, Colart, Tecknuovo and Globelynx. Several engagements from that period predate the company's incorporation and were delivered by James Rooney personally on contract. On a call we will walk you through which is which. We say so plainly because a track record is only evidence if you can check it. The same person led the work either way, and this case study describes what was done and what changed.

They do when they are the missing feedback loops. Ritual on its own changes nothing. Yondr's teams had no retrospectives and no planning, and nobody was actively managing the backlog. Putting those back alongside honest Story Point estimation took the development teams to consistent output every sprint within three months. The ceremony itself is not the point. What each one adds is a place where the plan meets what actually happened and gets corrected. Teams that hold the meetings without making the corrections get the cost of the ceremonies and none of the predictability.

Reliable digital delivery in the UK and USA was critical to Yondr scaling its data centre operations, and that is where the unpredictability hurt most. When digital output is erratic, the operational side of the business cannot commit to anything that depends on it. Development output became consistent, support and security followed, and Yondr could plan holistically at last. For a business like that, predictable software delivery is an operational dependency, not an engineering nicety.

Everywhere at once. We staged the order of functions and left geography out of it. At Yondr the work ran across the UK, USA and Singapore in parallel, remotely with on-site workshops where they earned the travel, because the erratic delivery was one problem, not three local ones. Development teams went first and hit consistent output every sprint within three months. Support and security followed and had the same predictability by six. Fixing one region at a time would have left leadership planning around whichever region was furthest behind, and Yondr needed reliable delivery in the UK and USA to scale its data centre operations.

If one team needs its ceremonies run properly, a coach is the cheaper and better answer, and we will tell you so. Yondr's problem was a size larger. The business could not plan beyond a quarter because digital teams in the UK, USA and Singapore delivered inconsistently, and reliable delivery in the UK and USA was critical to scaling data centre operations. The work meant recalibrating estimation against demonstrated capacity, embedding the ceremonies that were absent, then carrying the same discipline into support and security so leadership could plan across functions rather than one team at a time. Development output was consistent every sprint within three months.

They will if you use points to rank people. At Yondr the correction ran the other way. Estimates were adjusted after completion to reflect the capacity each team had actually demonstrated, so an optimistic estimate gets corrected by the next sprint's evidence instead of rewarded. Points are a planning unit, not a performance measure. The test of the whole exercise was a business one. Could Yondr commit beyond the current quarter? Within three months the development teams were producing consistent output every sprint, and by six months support and security had the same. Use the number to judge individuals and you lose both the trust and the data.

Predictability dies, and no estimation method survives it. Active backlog management was one of the ceremonies missing at Yondr, and putting it back gives reprioritisation somewhere to land. The backlog gets reordered in planning, so a sprint that has been committed can finish and produce a number worth learning from. Without that, every sprint is a different experiment and the average tells you nothing. That discipline is a large part of why Yondr's development teams reached consistent output every sprint within three months, and why the same approach held later for support and security.

By whether it repeats sprint after sprint, and by whether anyone outside engineering can plan on it. At Yondr the development teams held consistent output every sprint from month three. The same result held as the approach reached support and security by month six, and the business started planning holistically instead of a quarter at a time. One strong quarter is noise, usually a team that pushed hard or got lucky with scope. On live engagements we report value monthly for the same reason, and a month that delivers nothing measurable is reported as a failed month.