From Chaos to Clarity: The Power of Working Agreements
Scaling an organization effectively requires mitigating the decline in marginal productivity as it grows.
Experienced managers know the challenges of growth: keeping coordination overheads down, resolving friction, and keeping teams aligned. But the standard tools available – issuing policies, adding meetings, increasing oversight – all come with real costs to marginal productivity and managerial resources. By themselves, they don’t provide the precision and efficiency needed to fully support high-performance organizational growth.
A more effective tool for sustaining productivity at scale is the working agreement.
When implemented well, working agreements can yield substantial gains in an organization’s performance – without increasing management workload.
In this article, I explain what working agreements are, why they’re more effective than traditional approaches, and how to implement them successfully.
The challenges of sustaining performance at scale
To understand what’s required for high performance at scale, it helps to look at two ends of the spectrum: peak performance at minimal scale, and performance collapse at the limits of scale.
Peak performance at minimal scale is a lone founder feverishly working on a passion project, free of coordination overheads or workflow constraints. This is the highest marginal productivity possible, but also the smallest overall capacity.
Low performance at scale can be illustrated – in dramatized fashion – with two hypothetical companies at opposite extremes.
The first company has no management. No one knows what they’re doing or why. Conflicts flare up across the organisation and remain unresolved. Everyone is waiting on everyone else, systems are broken, customers are complaining, and everyone’s getting drawn into endless meetings about all of the above. In this chaos, staff are overloaded with work, but little gets delivered, and what does get delivered is late or rejected.
The second company is managed to the hilt. Managers – who may even outnumber non-managers – have everything under lock and key. Nothing moves without strict adherence to rigid processes, layers of approvals, and exhaustive meetings. There’s no chaos, but only because work has been throttled to a snail’s pace. As with the first company, what does get delivered is late; and since requirements will have changed by then, it will be rejected too.
High performance at scale comes from staying as far from these two extremes as possible – right in the middle at the ‘just right’ management sweet spot.
This indicates the ideal scaling story: from employee 1 through to employee N, management stays at this sweet spot – providing just enough clear guidance, intervening only to the extent needed, applying minimal and effective solutions, and staying hands-off otherwise. This maximizes performance at all points in time and, all else being equal, allows the organization’s productive capacity to grow at its fastest sustainable rate.
The question then becomes: as the company grows, how do we avoid undermanaging or overmanaging?
To answer this, it helps to revisit how managers typically respond to coordination problems.
Common management responses to coordination problems
Managers faced with rising coordination problems look for solutions that are broad in scope and rapid to implement. Their time is limited, their span of control is wide, and the problems are urgent.
Policies
Often a manager's thoughts will move to apply a uniform solution across their whole division. One that they’re confident will make the situation better, even if not perfect.
One approach is to lay down policies, often lengthy, which may include approvals, permissions, checklists, procedures, rules, or forms.
This bureaucratic approach can introduce rigidity, reduce the autonomy and empowerment of teams, dampen innovation and productivity, weaken the relationship between staff and management, and erode a dynamic, can-do company culture.
Writing these policies also takes a lot of work, yet they often get ignored after their introduction. They also implicitly transfer responsibility upwards – replacing judgement with the following of rules, further lowering productivity.
Frameworks
Another approach is to choose an off-the-shelf framework, e.g. an Agile framework like SAFe, and apply it verbatim. This has a big advantage over writing policies – it’s a ready-to-use product.
In practice, staff often perceive this as heavy-handed, disruptive, or even as the latest management fad. It can also be burdensome – introducing new terminology and processes that must be learned on top of their already heavy workloads.
It might also unintentionally sideline work teams have already been doing to address the same problems, lowering morale and displacing their potentially more effective, tailor-made solutions.
Frameworks also don’t naturally accommodate the best-practice approach to improvement: follow the 80/20 rule and fix the bottlenecks. Frameworks are all-or-nothing by default because, without deep experience, an implementer can’t know what to remove without weakening what remains. That makes this approach inefficient by default, imposing changes where no problems exist.
There’s nothing inherently wrong with frameworks, but they need to be applied judiciously. Under time pressure – as is often the case – they tend to be implemented formulaically, leading to poor outcomes.
Meetings
A common default approach is to increase the number and size of meetings until the situation feels under control. The meeting becomes the blunt go-to tool to work out what’s going on, and what are we going to do about it.
This can feel like it works. With the increased meetings, chaos subsides. But this can be misleading. While everyone’s in meetings, they’re not working, hence less work to coordinate.
Indeed, reducing productivity in any way will reduce chaos – less productivity means less frequent work interactions. (This isn’t a linear effect; chaos tends to increase exponentially as workloads saturate multiple dependent teams, causing sudden-onset gridlock rather than a gradual rise in coordination difficulties. As a result, even modest reductions in productivity can quickly cut back chaos.)
This reliance on meetings is expensive and inefficient, effectively reduces net headcount as staff are drawn away from their work to listen to people talk in meetings, and scales poorly.
Withdrawal
In some cases, an overwhelmed manager may simply withdraw from dealing with the problems and focus on other priorities, leaving the teams to fend for themselves. Coordination issues grow, and without leadership, the decision-making falls to whoever pushes hardest.
To understand what to replace these patterns with, we should first consider the fundamentals of how organizations coordinate work.
Top-down and bottom-up coordination
A simplified interpretation of an org chart would say that the top gives orders, and the bottom follows. We can call this “top-down coordination”, where managers set direction for their reports, who in turn direct their own, cascading down the hierarchy.
But as we know, most coordination actually occurs at the bottom (“bottom-up coordination”), during collaboration. Projects are completed through a series of quick informal decisions, with minimal management input. Middle management are guided as much by directions coming from above as they are information being reported from below.
Managerial decisions are important – such as setting boundaries, direction, and priorities; unblocking impediments; and settling disputes as they arise. But they are infrequent compared to decisions made at lower levels. And since the org chart is a triangle not a rectangle, a manager's span of control demands top-down decisions comprise a small fraction of decisions as a whole.
Bottom-up coordination has several advantages. The most obvious being scale – there are a lot more work-days at the bottom of the chart than at the top.
Staff at the bottom of the chart are also closest to the action – in aggregate, they hold the most up-to-date context on how work is getting done, enabling them to make informed decisions more quickly. If they’re empowered, they can act on those decisions immediately. With small, independent teams, coordination can be fluid and precise.
However, bottom-up coordination scales outwards poorly. Any informal agreements made during collaboration extend little further than that project. Contrast this with top-down coordination, like policies, which can readily scale across the whole organisation.
To perform highly, an organization must skillfully blend top-down and bottom-up coordination, with a clear understanding of where each is strongest and weakest.
Why coordination complexity escalates rapidly
Projects contained within a single close-knit team are easy to coordinate: people know each other; regularly meet and keep aligned; share the same tools, schedules, and leadership; and often come from similar professional backgrounds.
As organizations grow, projects become more complex, and roles that start out embedded in teams may migrate into shared services. Project participants start to come from increasingly distant parts of the org chart, follow different processes, work at different cadences, report through separate chains of command, or even operate across time zones. With more permutations of projects, teams, and people, simply coordinating resources can become a challenge in itself. This complexity can spiral into chaos if left unchecked.
These problems are then compounded by the dispersion of power and responsibility for fixing chaos. If chaos arises in a small team, its leader can fix it themselves. But if the chaos is spread throughout a whole division, knowledge about the problem is dispersed too, and no one individual is able to understand the whole situation and fix it themselves.
Bottom-up coordination can’t fix it alone – it lacks centralized authority and accountability. Neither can top-down coordination – it lacks the time and up-to-date insight to intervene effectively.
The solution is to use top-down authority to empower detailed solutions created at lower levels. This avoids the problems of top-down policies, while at the same time avoiding the gridlock that comes from dispersed knowledge, ideas, and responsibility at lower levels.
In short, management needs to lay out a framework for those below them to solve coordination problems themselves. This is where working agreements come in.
Working agreements are the best tool for the job
Working agreements are a written agreement between individuals or organizational units on how they will work together. They are developed in a collaborative way, with multiple levels of the organizational hierarchy playing a role.
They differ from policies in that they don’t flow directly from management; their subordinates do most of the writing. They also differ from informal “how to” pages on the corporate wiki, because management’s sign-off makes them binding.
Most people in Agile organizations have heard of at least one type of working agreement: the “Definition of Done”. Another common one is the “Definition of Ready”. Most Agile literature focuses on working agreements that – like these examples – are usually applied at the team level, reflecting Agile’s emphasis on the cross-functional team as the engine room of value delivery.
While these intra-team working agreements can be useful in certain cases, small teams can often get by fine without them. Small teams organically develop Team Norms, due to their ongoing collaboration with each other. Everyone roughly knows what to do in a given situation, or at least who to ask.
Greater benefits are gained from working agreements covering broad organizational distances, where collaboration is too dispersed for norms to form.
In this article I’ll focus on these cross-team working agreements, which are more difficult to execute but offer a far higher return.
What happens when a working agreement comes into play
Working agreements, when done well, perfectly thread the needle described above:
- They create the right amount of process – not too rigid, not too loose.
- They’re generated by those with the most context – those regularly experiencing the problems.
- They nevertheless carry management’s authority.
- The workload for creating them is distributed among many parties, rather than overwhelming a single manager.
- They’re efficient – no need for ongoing big meetings.
When a high-quality working agreement is implemented, coordination problems drop precipitously. Expectations and accountability between teams become clear, incidents fade out, productivity increases, and harmony among teams returns.
Working agreements also create psychological safety for staff, as the drafting process makes them feel listened to, supported, and encouraged to share their thoughts.
As a result, they make teams more effective, allow increased managerial span of control, strengthen retention, and raise overall organizational performance.
Crafting the perfect working agreement
First and foremost, working agreements need to provide high value quickly. This is attained through following the 80/20 rule.
When should you make a working agreement? Only when there’s problems to address.
What should it cover? Only those problems.
Who should be involved in drafting it? Only those with knowledge and responsibility within the domains the problems are arising.
Once that narrow scope is established, the process for crafting it is as follows.
Step 1. Green light to start
A working agreement must flow from the authority of the managers of the organization units involved. Their subordinates can suggest making one, but drafting can’t start until those managers have agreed in principle and given the green light.
Step 2. Drafting
Drafting should start with a small group, referred to as the “working group”, composed of those who are particularly affected by the problems or interested in fixing them. It should include at least one person from each major organizational unit involved, and a facilitator – such as an Agile coach or Scrum master – to guide the process.
The working group should be kept small enough so that the draft can be completed quickly, but large enough to ensure buy-in. Without broad buy-in, staff may feel it to be imposed, unnecessary, or irrelevant.
Members of the working group may want to circle around and ask teams or key individuals if there’s anything they want included. They will usually know who is likely to have opinions about the ideas being discussed. This doesn’t mean the drafters should accommodate every request, but when individuals feel they’re benefiting from the agreement, it reduces resistance in later stages.
Step 3. Review and revision
Once drafting is complete, the working group circulates it for review by team representatives – usually team leads – who may request revisions or circulate the draft within their teams to gather feedback.
The working group then works through the revision requests. In most cases, the revisions are either uncontroversial or resolved through straightforward compromises.
Contentious revisions may indicate misalignment between teams, and should be brought into a meeting with the managers of the organizational units to hammer out a solution.
The managers may want to stay hands-off early in the revision process, to give their teams space to speak freely before offering their own input – otherwise, reports may hesitate to raise concerns that conflict with higher-ups' views. Once all input has surfaced, the managers can then flag any problem areas and request final revisions.
Once all representatives have signed off on the final version, it’s ready to be executed.
Step 4. Executing the agreement
The managers of the organizational units then sign off on the working agreement, making it binding. The working group then announces this to all of the teams involved, and carries out the tasks required to roll it out.
The structure and contents of a high-quality working agreement
An effective working agreement must meet all of the following requirements.
Parties involved. It must be clear who the agreement covers. This will usually be in the agreement’s title, e.g. “Working Agreement between Engineering and Design”.
Motivation. The agreement should start with a statement of intent, which should be positive and inspiring. The agreement should not feel like an imposition, but a helping hand and a path to a brighter future.
Subject matter. The subheadings of the agreement should be very clear on what they cover, and narrow in scope. It should only cover significant, recurring problems. Broadly-worded headings are a warning sign that it isn't narrow enough.
Easy to read. It should be written in simple, clear, concise, and easily understandable language. There’s a balance to strike between clarity – which can sometimes be hard to digest and may appear legalistic – and simplicity – which can open the door to multiple interpretations. However, it’s easier to start with simplicity and clarify later than to do the reverse.
Binding effect. The working agreement must state how it binds the parties involved. This should be as flexible as possible, while remaining firm enough to be effective.
The sweet spot is typically something like: “Everyone should aim to follow this agreement; but they may deviate from it if they do so knowingly, have a reason, notify anyone who may be affected, and receive no objections”.
This approach preserves most of the flexibility the parties had before, while ensuring they remain mindful of the commitments laid out in the agreement.
Enforcement mechanism. Without enforcement, the agreement will end up among the other forgotten pages in the corporate wiki. On the other hand, watching like a hawk for violations would harm company culture. Fortunately, the middle ground is simple: address it when conflicts arise.
Typically, when a project goes poorly and causes conflict between teams, it turns into a blame game. But with a well-written working agreement, the blame game melts away. Anyone can point to the provision the other side didn’t follow that led to the issue. Since both sides agreed to it, there’s no need for protracted back-and-forths or meetings with managers – just a simple “oops, we’ll remember that next time.”
Amendment provisions. Everyone should be fully empowered to amend the agreement. This is important to keep the agreement up to date and actively used. It also makes staff feel responsible for continually fixing coordination problems from the bottom up, rather than treating the agreement as final.
The amendment mechanism is a barometer for how bottom-up the agreement actually is. If it reads like “all heads of the departments must explicitly approve amendments”, then you don’t have a working agreement, you have a managerial policy. On the other hand, if anyone can edit it freely, that’s also not a working agreement, it’s a wiki page.
In essence, the mechanism must bias proposed amendments towards approval. A proposed amendment should not need others to give affirmative consent, and instead, should require others to object if they don’t consent. This means a system of notice, opportunity to discuss, and automatic deemed approval.
A simple example might read: “Anyone may propose an amendment to this agreement, by giving notice to the managers and team leads. If there is no objection to the amendment within five business days, it is deemed approved.”
Owners. Having someone “own” the agreement helps keep it active. Usually this will be someone from the original working group.
The owner’s duties are to keep everyone aware of the agreement, oversee its use, suggest amendments (or encourage others to do so), and participate in meetings when problems arise between the teams.
The owner should make sure the working agreement is linked to and posted everywhere, and included in onboarding materials for new staff.
Escalation. In the uncommon case that people interpret a provision differently, or can’t agree on an amendment, or have just stopped following the agreement, there needs to be an escalation process.
For example, the owner of the agreement may hold a meeting to facilitate a solution; if that fails, they would involve the managers of the organizational units involved.
Reviews. The owner should hold regular reviews of the agreement, to make sure it’s being followed and kept up to date. A good time to do a review is after a cross-team project. If there were any difficulties in that project, the owner can check those against the agreement, and either remind everyone of the provisions that would have prevented that problem, or discuss amendments.
Simplification reviews should also happen from time to time. Amendments tend to be additive, which makes agreements more complex over time. Since simpler agreements are easier to use, periodic reconsolidation and cleanup is essential.
Record of approval. There should be an attachment at the bottom of the working agreement that shows who approved it, when, and their titles. This is where its authority comes from.
Execution steps. The agreement will take time for everyone to understand and start using. There’s a risk once it’s signed that everyone calls that “job done”, and moves their focus on to other work. To avoid this, the agreement should include post-approval tasks and specify who will complete them – and who will confirm their completion – to ensure it is set into motion.
Rolling out a new working agreement
Approval does not mark the end of the working agreement project; the next step is to communicate the change.
To implement it successfully and ensure it sticks, managers and team leads must actively champion it, at least in the beginning.
In particular, the signatory managers must drive initial engagement. If this step is overlooked, even the team representatives who initially agreed to and contributed to it may quickly forget about it.
The first task is to make sure everyone reads it. If it’s a lengthy agreement, you can instead ask people just to read the table of contents and the Meta section (which covers things like the effect of the agreement and how to amend it). If they read the table of contents, they at least know what subject matters it covers.
After that, the supporting tasks originally attached to the agreement need to be completed.
Finally, some parts of the agreement may require teams to modify their internal processes to align with it. The owner of the agreement should follow up on this until they have done so.
Thereafter, the owner and the other drafters should continue to remind their peers about the agreement, and encourage them to participate in its enforcement and amendment.
Keeping the working agreement alive
The owner of the working agreement holds primary responsibility for ensuring its continued effectiveness. They may receive support from other advocates – typically the other drafters.
The managers who signed off on the agreement must consistently provide their support to its owner. Without this backing, the agreement is likely to lose momentum, and the original problems will resurface.
It is best to identify the owner of the working agreement by position rather than name. This ensures that if the current owner leaves the company or moves to a different role, the agreement won’t be left without an owner. If the owner does move on, they should ensure their successor is properly onboarded.
The owner must ensure regular reviews of the agreement take place, such as through periodic meetings, cross-team project retrospectives, or whenever significant challenges arise between the teams.
Interplay between management decisions and working agreements
A working agreement does not affect a manager’s ability to make decisions afterward.
As with any decision, a manager can revoke previous ones. Signing off on a working agreement is a revocable act of delegating authority.
The authority of a working agreement comes from the approval of the managers overseeing the groups involved. Therefore, if they or their superiors later issue a directive contrary to the agreement, they have implicitly revoked that portion of it.
Even so, any such actions should be handled carefully to avoid undermining the working agreement.
A good practice when a management decision conflicts with a section of a working agreement is to strike through the affected section and add a note explaining why. The management decision then takes precedence over that part of the agreement. The section should not be deleted entirely; striking it through allows it to be reinstated if the management decision is later changed.
This will likely lead to follow-up amendments to the agreement to realign it.
There are exceptions, such as changes to names or labels. Since these do not alter the substance of what was agreed upon – only the terminology – these can be treated as simple edits.
Management does not lose any authority through working agreements. Instead, a working agreement is an exercise of power via delegation, and they retain the ability to change how that power is exercised. However, they should proceed with caution, considering how their actions will be received and the potential drawbacks of top-down directives. In many cases, it may be better for management to have one of their subordinates propose an amendment to align with their needs, or to hold a meeting with representatives from each group to reach a consensus.
Overcoming challenges with working agreements
There are a few common pitfalls with working agreements. Here’s how to avoid them:
Lack of buy-in
Front-line staff and individual contributors tend not to pay close attention to operational policy documents, often viewing these top-down mandates as disconnected from day-to-day reality and more a source of friction than support. (This disengagement is not born of resistance to management or company goals; indeed, the inverse – workers strictly adhering to work rules – is a well-documented form of labour protest.)
If they’re unfamiliar with working agreements, they may mistake them for a policy document. To gain their buy-in, make the distinction clear by explaining how a working agreement differs and what benefits it offers them. Involve them in shaping it so they feel it’s theirs, not something imposed on them.
The purpose of the document must be clear – it’s a collaborative effort to address recurring, painful issues. Ignoring it would therefore constitute complicity in those problems.
Highlight the Meta section. It should be seen as flexible, amendable, and empowering – more of a delegation of management power than a top-down directive.
Influential individuals should be involved in the drafting process, even if it’s just to provide input on what should be included. If they see their contributions reflected, they’ll support it.
Suboptimal solution
A well-designed working agreement will always reduce coordination problems between teams, but it may not be a sufficient solution.
Often the underlying cause of the coordination problems lies elsewhere, such as cultural issues, team topologies issues, or capacity constraints. In these cases a working agreement may not be the first tool you reach for.
For instance, if your organization has functional departments, before you craft working agreements between them, you should consider if a reorganization in the direction of cross-functional teams – the standard Agile form of organization – would be possible.
Too burdensome
A working agreement should be easy to follow. If it’s too difficult to carry out its provisions, it’ll be ignored.
Too big and complex
The more complex the agreement, the less it will be read and understood.
When adding provisions, ask: "Is this necessary, or is it implied?" Details can be clarified later in amendments. Use simple language – avoid legalese.
Lack of accountability
If the agreement isn’t followed and problems arise, there must be consequences. For this, you need a system for monitoring adherence and reminding people. The agreement is only as strong as the accountability behind it.
Failure to keep it up to date
Informal agreements can evolve faster than amendments to the working agreement, leading to discrepancies and reduced respect for it.
Newcomers can help. If they’re tasked with reviewing the agreement during onboarding, they can identify discrepancies and raise them as part of their onboarding responsibilities.
Organizational changes
If teams are reorganized, it can be unclear the extent to which the agreement still applies.
To resolve this, trace new reporting lines. If a team no longer reports to any of the original signatory management positions, the agreement is no longer binding on them. Conversely, if a new team reports to one of them, and is within a function covered by the agreement, the agreement applies to them. If a manager changes, the agreement remains in effect unless countermanded.
Difficulty reaching consensus
If there’s disagreement on provisions, defer them rather than letting them block progress. This is a fundamental Agile principle – deliver value incrementally.
Deferred provisions can be revisited in future sessions. An Agile coach or experienced mediator can help if the group gets stuck.
Conclusion
Working agreements, especially cross-team ones, are a powerful way to boost performance in growing organizations. They reduce coordination friction, foster harmony, and facilitate effective collaboration, helping companies preserve the agility and camaraderie of their early days as they scale.