How do we balance structure and agility in a growing project management team?

[Dennis.B]

We’re hitting a real bottleneck with our current project management system as we’ve grown from a core team of 10 to nearly 50 people across three departments. The lack of a single source of truth is causing missed deadlines and duplicated work, but I’m worried that enforcing a rigid, company-wide system will stifle the autonomy that helped us grow in the first place. Has anyone navigated this specific clash between necessary structure and preserving team agility?

[Nora.R]

We split governance into federated squads; each dept owns its backlog in the PM tool, but we maintain a lightweight cross-project board that shows dependencies. It reduced duplicated work but we still hit bottlenecks when cross-team work needed signoffs.

[Kenneth70]

I tried pushing a common system across all teams and got pushback. We kept autonomy but introduced a minimum data spec for cross team items and a once-a-week sync to surface blockers.

[PaulM]

We kept the system optional for non critical work. We track cycle time and on time delivery, and adoption varied by team. When a team used it heavily, deadlines improved; when not, it didn't.

[Ryan.L]

A pilot with three projects showed that the teams with more frequent cross-team standups had fewer duplicated tasks. But it required a lot of nudging and a dedicated facilitator.

[Aaron.L]

Sometimes the real problem wasn't the tool but unclear decision rights. We redefined who can prioritize cross-team work and that reduced last minute chaos somewhat.

[Justin75]

Question: Do you need a single source of truth or just better signal across teams?