Government technology programme · Scaling from 10 to 20 agile teams · Building a new primary system under strict regulatory constraints
Large-scale ART growth
What I did
Joined as RTE during a critical growth phase — the programme was doubling in size while also under pressure to deliver. I set up the agile team structure and the collaboration patterns that would need to hold across 20 teams. That included facilitating quarterly PI Planning events with 270+ participants in person, which requires a different kind of preparation than most people expect. Logistics matter enormously. So does the energy in the room.
I also coached stakeholders in MVP thinking — helping business owners make smaller, clearer bets instead of committing to everything at once — and organised offsite strategy days with directors when the programme needed a different kind of conversation than the usual cadence allowed.
What shifted
The programme had a culture of gap-spotting — retrospectives full of what was wrong, planning sessions focused on risk. Reasonable, given the constraints. But it was quietly draining people. Over time, we shifted toward celebrating progress: naming what had been delivered, what had been learned, what had held up under pressure. Psychological safety improved measurably. People started coming to PI Planning with a different attitude — still serious, but less braced.
RTE
SAFe
Large-scale
Government
270+ participants
Large municipality · Six teams building a shared cloud platform from scratch · Under pressure to deliver while expanding capabilities and headcount simultaneously
Platform teams finding their rhythm
What I did
Before acting, I spent time observing. I wanted to understand the actual collaboration patterns — where dependencies were creating friction, which handoffs were invisible, which meetings were happening out of habit rather than need. The diagnosis came first.
From there: restructured the team setup to reduce inter-team friction, facilitated planning events, and optimised the meeting structure so people weren't spending their days in rooms that didn't move anything forward. Perhaps most importantly, I created conditions for trust and continuity — two things that are easy to underestimate and hard to rebuild once they're gone.
What shifted
Teams moved from reactive delivery — responding to whatever was loudest that week — to predictable, quarter-on-quarter planning. People knew what they were working toward and roughly when. That predictability changed the atmosphere. People started enjoying the work again. That sounds simple. It's not.
RTE
SAFe
Cloud platform
Municipality
Technology organisation · A central enabling team needed to be established quickly · Significant risk of resistance from 11 other teams whose daily work would be affected
Team resilience under change pressure
What I did
The obvious path would have been to design the solution, communicate it clearly, and manage the transition. That approach works when resistance is low and stakes are manageable. Neither was true here.
Instead, I involved all affected developers in designing the change from the start. Not through a survey or a feedback round after decisions were made — but genuine co-design, where the people whose work would change had real influence over how it would change. That takes longer upfront. It's worth it.
What shifted
Resistance almost entirely disappeared. Not because people were managed or persuaded, but because they had shaped the outcome themselves. The transition was smoother than anyone expected. People don't usually resist change — they resist being changed. There's a difference, and it matters.
Agile Coaching
Change management
Co-creation
Developer engagement