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, ran daily executive stand-ups, and removed obstacles directly rather than logging them. He then set a review and planning cadence that gave technology, operations and transformation one language for progress. The measure of the role is 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 out of view. The daily executive stand-up, run against a live Kanban of initiatives and dependencies, is what 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, and at HSBC the cadence stabilised delivery around it.

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

It overruns because planning starts from a position of not knowing the current state: initiatives untracked, dependencies invisible, blockers unresolved, so the cycle spends its time reconstructing reality before it can decide anything. At HSBC the fix was structural rather than heroic. 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 already 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 made them visible on the executive team's live Kanban, raised them at a daily stand-up in front of the CIO's leadership group, and had someone whose job was to remove obstacles directly rather than minute them. 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, inside a function of 150+ global teams and a $102M operating budget. The results landed within the same window: decision speed improved sharply, blockers cleared in days rather than weeks, 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 daily.

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, and a leadership team that can see 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. The site keeps the framing honest: this study is founder track record rather than work delivered under the Tenhaw banner, and it is written that way, with James named throughout. 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 what this engagement installed there is exactly 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. The study is equally clear about the limit: no AI was involved here. What it evidences is that James has run this operating discipline inside the executive team of a global bank, which is the room where an AI programme's funding, priorities and blockers actually get decided.

More than sign-off: a rhythm the model can actually be run on. A banking AI target operating model usually arrives well argued and then stalls in the executive layer, which is where funding, priorities and blockers 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. That engagement involved no AI; the executive discipline is what transfers.

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 between functions rather than inside them, unescalated. 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: moving work that is stuck. At HSBC the stand-up ran against a live Kanban holding all work, planned initiatives and dependencies, so nobody spent the meeting reporting a position everyone could already see, and the governance model around it was deliberately lightweight rather than a new reporting layer. The other half is accountability. Obstacles were removed directly rather than minuted, so raising one led somewhere, and the group could judge itself on movement rather than 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, so we introduced Story Point estimation recalibrated against real capacity and 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. The result was that 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.

At Yondr it took three months to get development teams producing consistent output every sprint, and six months for that predictability to extend across the support and security teams. That is a realistic shape for the work: 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, reinforced with on-site workshops where being in the room genuinely helped. Remote-first was a necessity with three regions in play, and it worked because the method leans on visible artefacts rather than presence: estimates corrected against completed work, actively managed backlogs, and ceremonies whose outputs every team can see. 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, extended across support and security by six. There were no models and no agents at Yondr, and that is the point: predictability is a precondition for automation, not evidence of it.

Adjust the estimate after the work is done, which is what turns estimation from optimism into measurement. Most teams estimate, deliver something different, and 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, which reached consistent sprint output within three months, and by six months it had extended to the support and security teams as well. The mechanics are the same whatever the function: work made visible, estimates corrected against what was actually completed, and regular planning and retrospectives. Extending it beyond engineering mattered because a business plans across all of its functions, and predictable development next to unpredictable support still leaves leadership guessing. It was only once all three were predictable that Yondr could 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, and we will walk you through exactly which is which on a call. We state the distinction plainly because a track record is only evidence if you can check it: the same person led the work either way, and the case study describes exactly what was done and what changed.

They do when they are the missing feedback loops rather than ritual. Yondr's teams lacked retrospectives, planning and active backlog management, and embedding those 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 with none of the predictability.

Yondr was scaling data centre operations, and reliable digital delivery in the UK and USA was critical to that scaling, which is exactly where the unpredictability hurt most. When digital output is erratic, the operational side of the business cannot commit to anything that depends on it. Once development output became consistent, and support and security followed, Yondr could plan holistically rather than a quarter at a time. Predictable software delivery is an operational dependency for a business like that, not an engineering nicety.

Everywhere at once, sequenced by function rather than by geography. 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 rather than three local ones. What was staged was the order of functions: development teams first, reaching consistent output every sprint within three months, then support and security, which had the same predictability by six months. 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 was 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 points are used to rank people, which is why the correction at Yondr 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 rather than rewarded. Points are a planning unit, not a performance measure, and 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 is what gives reprioritisation somewhere to land: the backlog is reordered in planning, so a sprint that has been committed gets to 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 evidence was consistent output every sprint from the development teams by month three, the same result holding as the approach reached the support and security teams by month six, and the business 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.