Who Should Own It? The Question That Outlasts Every Restructure

Some of the best work I have done started by building a buffer between teams, and ended by helping to take that buffer away. Both decisions were right at the time. Knowing when the answer has changed is, I think, one of the most underrated skills in product leadership.

The setting was the product, used by more than 8 million active accounts and part of the Government Made Easy program. Agencies wanting to join that ecosystem faced a slow, ad hoc onboarding process. Meanwhile, the teams behind Proof of Identity, Profile Connect and Customer Identity and Access Management were being pulled into every agency's problems, at the expense of their own roadmaps.

Stage one: build the buffer

I think of those product teams as parts manufacturers. What was missing was a parts supplier standing between them and constant demand.

So I founded an onboarding squad, later called Agency Experience, with a vision of onboarding as a service and clear roles and responsibilities. Direct agency contact with product teams fell by around 80%, and the teams got their focus back.

A squad is not yet a product, so the next step was to mature it into one. The Service Orchestrator was an internal wrapper managing the flow between Proof of Identity and Profile Connect, using consistent CX and privacy patterns instead of one-off integrations. With a complete framework around it, we delivered Premier's Priority work including Toll Relief, the Digital Driver Licence, and LicenceNSW licences. LicenceNSW alone delivered $148M in economic benefits and added 127K days to the economy. Revenue NSW was onboarded in under 15 person-days.

Stage two: notice the buffer's cost

A buffer that works too well can become a bottleneck of its own. Knowledge collects in the middle, and the people who build a product move further from the people struggling with it.

In 2023, government priorities shifted and Agency Experience moved under the broader Customer Success Team. A better buffer was no longer the right answer, so I pushed for a shift-left model, in which product teams support and own their own products rather than passing issues downstream to operations.

In practice, that meant:

• Proactive health checks, instead of waiting for tickets.
• Sharing Root Cause Analysis and Post-Incident Review insights directly with product teams.
• Dual-Track Agile, so BAU support and innovation could run together without one starving the other.

In the third quarter under this model, we recorded 100% CSAT on onboarding process clarity, documentation and guidance. Of 22 support issues that quarter, 63% were resolved within SLA. That second figure is not one I would frame as a triumph. It is useful because it is honest: moving ownership exposes where the work still is.

When a restructure breaks something

Ownership gaps usually show up at the worst moment. A CIAM identity provider migration coincided with an organisational restructure, which cut off access to Single Log Out documentation. The team was soon spending 60% of its time on Single Log Out support queries.

The fix was not more support capacity. I ran a workshop with the CIAM squad; we agreed on a living document, and we shipped the documentation into the partner portal Beta. Support requests fell by 50%, and adoption rose by 10%.

The real problem had never been the queries. Nobody clearly owned the knowledge once the organisation moved around it.

Questions worth asking regularly

• Who is absorbing demand that belongs to someone else? Sometimes that is the right temporary design. Be clear that it is temporary.
• What would break if this team disappeared tomorrow? The answer shows you where knowledge has concentrated.
• After a restructure, what lost its owner? Check documentation, integrations and support paths first.
• Do builders see what their users struggle with? If not, your support model may be hiding the most useful product feedback you have.

Organisations rarely stay the same shape for long enough for an operating model to be finished. Solve today's problem, then ask who should own it once the dust settles.