From activity to accountable decisions, Kotori

The situation

Parkering Göteborg had multiple digital initiatives underway, both large and small. Work was driven by individual interests, preferences, and local priorities. There was no shared structure deciding what should be done.

The organisation was trying to deliver solutions without first establishing what the underlying needs were. This created a steady flow of activity, but without a clear connection to business priorities or user needs.

At the same time, key constraints were already in place. Procurement timelines, delivery expectations, team structures, and budgets could not be reset. The work needed to move forward within those boundaries.

How I read this

The situation was often described as a lack of process, structure, or direction.

Those elements were missing, but they were symptoms rather than the core issue.

What was actually absent was a way to make and hold decisions. There was no shared mechanism for defining needs, setting priorities, or ensuring that work aligned with those priorities once it started.

Without that, activity filled the space. Work continued, but without a consistent answer to what should be done next, or why.

The problem wasn’t that nothing was happening. It was that nothing decided what should happen.

What I did

Established decision-making as a shared responsibility

I introduced forums, rituals, and processes that brought business needs and development work into the same conversation, making ownership of decisions explicit.

Made priorities visible and accountable

Decision material was prepared for the management team to support clearer choices. Decisions were documented, communicated, and followed up so that priorities were understood across the organisation.

Introduced a structured product development process

Work began with defining the problem or need, followed by proposing solutions grounded in that understanding. Development did not start until this had been reviewed and agreed.

Stopped work that bypassed the process

Initiatives that did not go through this structure were paused, ensuring that all work was connected to an agreed need and priority.

Created shared understanding across the organisation

I ran sessions across the organisation to make current work visible: what was being built, procured, researched, and planned, why it had been prioritised, and what the realistic scope was.

Outcome

Work shifted from continuous activity to structured, prioritised delivery.

Initiatives that had started without a defined need were de-prioritised once they went through the process.
Both leadership and the wider organisation gained a clear view of how decisions were made and why, not just what the priorities were.
Requestors became responsible for building the case for their needs and owning them through delivery, replacing a model where ownership transferred to whoever fulfilled the request.
Development efforts focused on agreed problems, reducing rework and misaligned delivery.

Why this pattern matters

The tempting path would have been to keep moving. Work on what was interesting, respond to whoever was loudest, and let the queue fill itself. That would have felt like progress.

Resisting it meant creating friction instead. Departments that had always been able to request work now had to build a case for it and own the outcome. That was uncomfortable, and not everyone welcomed it.

The product development process itself required care to get right: the right steps, the right forums, the right decision points. Too much structure and it becomes bureaucracy. Too little and the old patterns return.

The hardest part was the mandate question. Handing decision-making authority for smaller decisions to the wider organisation required the management team to let go of control they were used to holding. That was a genuine ask, and it took time before it felt safe enough to do.