Lessons from a failed steering committee update

Every project leader has experienced it. You've spent hours preparing a report back, anticipating questions and making sure every detail is accurate. The meeting begins, you start presenting and within minutes you can tell the information isn't landing. The discussion drifts into operational detail, people disengage and the decisions you needed never quite materialise.

I've been there. It was that experience that ultimately shaped the presentation I delivered at the Scrum Alliance Global Scrum Gathering in Vancouver earlier this year.

While leading a technology implementation at Futuregrowth, I prepared what I genuinely believed was the perfect steering committee update. It included delivery dashboards, sprint metrics, technical blockers and detailed project updates. I wanted to be transparent and to demonstrate the amount of work the team was putting in behind the scenes.

The meeting, however, did not achieve what it was intended to. Some executives became absorbed in operational issues they weren't there to solve while others quietly disengaged as the discussion became increasingly technical. The meeting remained professional and respectful, but I walked away realising that despite all the preparation, I hadn't helped the people in the room do what they were actually there to do: make informed decisions.

Looking back, the problem wasn't the project, or even the report — it was my assumption that giving people more information would automatically create more understanding.

Transparency isn't the same as clarity

Like many project professionals, I'd always believed that transparency meant sharing as much information as possible. The more detail stakeholders had, the better equipped they would be to understand what was happening.

Take story points, for example. For anyone unfamiliar with agile delivery, story points are simply a way for software development teams to estimate the relative effort and complexity of work. They help teams understand capacity, plan future work and track progress over time – everything that is incredibly useful for the people building the product.

But they're not what keeps a board awake at night. Executive committees and boards aren't responsible for managing the day-to-day delivery of a project; their role is to govern it. They need to know whether the project remains aligned to its objectives, whether the business case is still sound, what risks require executive attention, whether budgets remain on track and what decisions only they can make to help the project succeed.

Different audiences need different conversations

Organisations communicate at different levels, and each level requires a different conversation. At an operational level, delivery teams need detail. They spend their days discussing technical blockers, sprint planning, testing, integrations and delivery capacity because that's how problems get solved and work moves forward.

Managers and programme leads sit one level higher, where their conversations are less about individual tasks and more about milestones, dependencies, resource allocation and delivery risks. Their role is to coordinate work across teams and ensure projects remain on track.

Boards and executive committees operate at a strategic level. They are focused on business outcomes, commercial impact, regulatory obligations, investment decisions and organisational priorities. They're not asking whether the team completed 40 or 60 story points during a sprint. They're asking whether the project is progressing as planned, what risks threaten delivery and whether leadership needs to intervene.

For example, a technical issue affecting a data migration might be an operational discussion for a delivery team. For a programme manager, it's a milestone risk that could delay implementation. For the board, exactly the same issue becomes a conversation about contractual commitments, regulatory exposure or the financial implications of a delayed go-live.

Redesigning the meeting

The first thing to go was the slide deck. No more elaborate presentations packed with dashboards, charts and delivery metrics. Instead, I started sending a concise one- or two-page briefing several days before each steering committee meeting that answered just four questions:

• Where are we?

• What are the biggest risks, and how are we mitigating them?

• What issues require escalation?

• What decisions do we need from the steering committee?

Reading the report became an expectation with committee members now needing to arrive having reviewed the material and prepared with questions. If I happened to see our CEO or COO in the corridor before the meeting, I'd simply ask, "Did you get a chance to read the report? Any questions?" It was a small prompt, but it kept the meeting front of mind and ensured everyone arrived with the same context.

As a result, our conversations changed almost overnight. We stopped spending time discussing sprint burndown charts, delivery metrics and technical blockers that executives neither needed nor wanted to solve. The executives did more of the talking; they challenged assumptions, asked better questions and provided clearer direction. The steering committee stopped spectating and started steering.

Instead, the executives did more of the talking; they challenged assumptions, asked better questions and provided clearer direction. The steering committee stopped spectating and started steering.

Perhaps the most significant change, however, happened behind the scenes.

Previously, I carried almost all the cognitive load as it was my responsibility to gather every metric, explain every dashboard and connect every dot during the meeting itself. Whereas, by introducing pre-reading, that responsibility became shared with committee members arriving having already absorbed the context, which meant our time together could be spent making decisions rather than interpreting information.

Whereas, by introducing pre-reading, that responsibility became shared with committee members arriving having already absorbed the context, which meant our time together could be spent making decisions rather than interpreting information.

The bigger takeaway

One of the most rewarding parts of presenting in Vancouver was discovering that this challenge extends far beyond agile software development. During conversations after the session, it became clear that professionals across industries were wrestling with exactly the same issue.

Whether they worked in financial services, healthcare, government or technology, the underlying challenge was similar: how do you communicate increasingly complex work without overwhelming the people responsible for making decisions.

As leaders, it's easy to assume that our job is to communicate everything we know but in reality, it is our responsibility to help others understand what matters most. That doesn't mean oversimplifying the work or hiding complexity but rather, recognising who is sitting across the table, understanding what decisions they are there to make and presenting information in a way that enables those decisions.

Representing Futuregrowth at the Scrum Alliance Global Scrum Gathering was an opportunity to share that lesson with a global audience, but it's one I'll continue applying long after returning home. Because the most effective board reports don't simply tell executives what's happening but create the clarity that allows them to decide what happens next.