“The best architectures, requirements, and designs emerge from self-organizing teams.”
Agile Manifesto
This line gets quoted a lot, usually as shorthand for autonomy and empowerment. It comes from a simple but powerful insight: when teams are trusted to organise their own work, they adapt faster, make better decisions, and produce higher-quality outcomes. Anyone else feeling the vibes of unicorns and rainbows...
But I'm not sure self-organisation was intended to mean no structure or no standards.
It requires that strong capability and the right fundamentals are already in place. Without those, self-organisation can lead to chaos.
I’ve seen inconsistency become the enemy of speed. Teams interpret “agile”, “ready”, and “done” differently. Delivery is unpredictable as rework creeps in which erodes trust, at leadership and stakeholder levels, but with clients too.
Getting back to basics means clearly defining the minimum standard for how product and delivery teams work together. I don't mean command and control by any stretch, but rather to create alignment and trust through a shared understanding of how things get done.
If you’re looking to scale, or you’re an enterprise struggling with outcomes, delivery confidence, or trust, here are a few principles that we see as foundational and are worth testing yourself against.
Delivery metrics tell teams how efficiently they’re working. Outcome metrics tell them whether their work actually matters. Remember, shipping the thing is output, delivering measurable value is the outcome.
You need both, but teams must be crystal clear on the difference. When teams regularly review customer and business outcomes, they’re better equipped to adjust direction, refine solutions, and stop work that isn’t delivering value.
That feedback loop strengthens product strategy and helps ensure growth doesn’t come at the expense of customer impact.
In early-stage teams, ways of working are often implicit. People sit close together so decisions happen quickly and gaps get filled through conversation.
As teams scale and distribute, that implicit understanding disappears.
Rather than forcing a one-size-fits-all process, I prefer thinking in terms of hygiene, a baseline that creates alignment while still leaving room for teams to adapt.
For example, Definition of Ready and Definition of Done help to ensure quality standards are met. Do you have clear "minimums" for your teams?
That baseline should make it easier to collaborate across teams, onboard new people, and coordinate work at an organisational level.
At a minimum, teams should be aligned on how they:
Capture opportunities
Prioritise discovery and delivery
Plan and prepare work
Deliver
Test and release
Launch, measure, and iterate
But of course, this isn't a linear process:
One of the earliest signs of scaling strain is when teams are overloaded with commitments before they’ve had a chance to understand the problem they’re solving. Work gets framed as solutions instead of opportunities.
A more sustainable approach starts with clearly articulated opportunities. These describe the customer problem, the strategic context, and the outcome the organisation is trying to achieve.
They also create a consistent entry point for ideas, whether they come from customer feedback, sales conversations, operational pain points, or leadership strategy.
By anchoring work in opportunities, teams retain the ability to explore options, test assumptions, and make informed decisions before delivery begins. That flexibility becomes critical as stakeholders multiply and priorities compete.
Just right-sized discovery helps teams understand the problem, validate the best solution approach, and clarify what success looks like.
It doesn’t need to be a three-month exercise. When done well, teams enter delivery with a shared understanding of the outcome they’re aiming for and the risks they’re managing.
As organisations scale, discovery also helps avoid a familiar and costly pattern: committing too early, then uncovering complexity halfway through delivery.
Yes, building software is getting faster and cheaper. But waste is still waste. If you can validate assumptions or test a proof of concept before making a big investment, you should.
At scale, prioritisation becomes a series of trade-offs between strategic bets, customer commitments, operational needs, and technical health.
There are plenty of frameworks you can use. RICE is a good one, but strategy comes first, scoring ideas second.
Transparency about what has been prioritised, and what hasn’t, reduces noise, builds trust, and is a key enabler of real empowerment.
As organisations scale, governance is unavoidable but isn't necessarily a bad thing. The real question is whether it enables progress or gets in the way.
Effective governance is lightweight and principle-led. It clarifies decision rights, creates transparency around progress and risk, and helps teams resolve dependencies. It avoids unnecessary approvals and keeps accountability close to the work.
When governance forums are well designed, they reinforce alignment without slowing teams down and give leaders confidence so they'll leave you alone.
Example:
Self-organising teams fail when organisations mistake autonomy for the absence of clarity.
At scale, empowerment comes from clear intent, shared standards, and fast feedback. The goal is creating the conditions where teams can make good decisions, repeatedly, and with confidence.
This means being explicit about what's expected and getting the basics right.