Joint Optimisation: When Your Team Norms and Your Technical System Are Fighting Each Other

The collaborative team that couldn't collaborate

The team had everything Agile coaching is supposed to produce. Genuine trust between members. Psychological safety that was evident, not performed. A product owner who was available and engaged. Retrospectives that surfaced real issues and produced real commitments. An engineering manager who protected the team from organisational noise. By every social-system measure, the team was exemplary.

They were also consistently slow, consistently producing individually-owned work, and consistently frustrated by handoffs that took days longer than they should. The coach spent three sessions looking for the relational dysfunction. There wasn't one. The coach then looked at the delivery pipeline. The deployment system required individual sign-off before merging to main. The code review tool assigned reviews to named individuals, creating personal queues. The Jira workflow enforced sequential handoffs through four separate approval stages. The social system was configured for collaboration. The technical system was configured for individual accountability. They were working against each other.

Trist, Emery, and the coal mines

Eric Trist and Fred Emery's socio-technical systems research began in the late 1940s in the coal mines of Durham, England. The National Coal Board had introduced a new mining technology — the longwall method — that was supposed to dramatically increase productivity. It did not. Productivity was disappointing and absenteeism was high. The technology was genuinely superior. The social organisation built around it was not.

Trist's observation was that the old mining method had naturally produced work groups that were self-contained, multiskilled, and mutually responsible. The new technology had been designed for efficiency without regard to these properties, and the resulting social organisation — specialised, divided, and individually accountable — was incompatible with the cooperative nature of the work.

The principle Trist and Emery derived from this research — and from subsequent studies in textile mills, aviation, and healthcare — was deceptively simple: peak performance is only possible when the needs of both the social system and the technical system are jointly met. This is what they called joint optimisation. And its converse: optimising one system at the expense of the other produces sub-optimal performance in both.

This principle was the most influential organisational design concept of the twentieth century. It informed the design of semi-autonomous work groups across manufacturing and services globally. And it is almost entirely ignored in Agile transformation work.

Agile's blind spot

Agile frameworks are primarily social system redesigns. The sprint cadence, the cross-functional team structure, the collaborative ceremonies, the shared backlog, the psychological safety practices — these are all interventions in the social system. They change how people interact, how work is organised, how authority is structured, how decisions are made. They are generally well-designed for what they are intended to do.

The technical system — the tooling, the pipeline architecture, the deployment authority, the ticket workflow, the monitoring and alerting systems, the code review processes — was almost always designed before the Agile transformation. It was designed for different assumptions: individual ownership, sequential handoff, approval-gated progress, functional specialisation, personal accountability for quality. These assumptions are structurally embedded in the tooling. They do not change when the social system is redesigned.

The result is a chronic joint optimisation failure that most Agile practitioners read as a team mindset problem. The team is running the collaborative social system it has been trained to run. The technical system is running the individual-accountability architecture it was originally built for. They are in conflict, and the conflict is felt as friction, slowness, frustration — interpreted as a people problem, addressed with more psychological safety work, and not improved.

Four recognisable mismatches

Collaborative team, gatekeeping pipeline. The team has high trust, shared ownership norms, and collaborative practices. The delivery pipeline requires individual sign-off before merge, named approval at each stage, and personal accountability for every deployment. The social system says "we own this together." The technical system says "one person is responsible for each step." Every collaborative decision is mediated through an individual-accountability bottleneck. The team experiences this as slow and frustrating and attributes it to "the tools" — which is accurate but insufficient, because the tools embody the assumption mismatch.

Self-organising team, individually-owned code. The team has committed to collective ownership as a value. The codebase has accumulated years of individual expertise, invisible tribal knowledge, and implicit ownership. Anyone who touches a module they don't own requires the original owner's review and approval — not formally, but practically, because the original owner's knowledge is the only thing that makes the review meaningful. Self-organisation is the social norm. Individual expertise is the technical reality.

Psychologically safe team, blame-signalling ticket system. The team has developed real safety to name failures and learn from them. The Jira workflow assigns bugs to the last person who modified the relevant code, notifies their manager automatically, and produces a report that counts individual bugs by assignee. The social system says failure is safe to acknowledge. The technical system says failure is individually attributable and managerially visible. The safety the team has built operates in a container that the tooling continuously undermines.

Cross-functional team, tool landscape that enforces silos. The team includes design, engineering, and product in a single cross-functional structure. The tools are organised by function: designers work in Figma (disconnected from development workflow), engineers work in GitHub (disconnected from design workflow), product works in Confluence (disconnected from both). Handoffs between the tools are manual, lossy, and delayed. The social system is cross-functional. The technical system is functional. Integration requires human effort at every boundary.

The coach's expanded diagnostic

Most Agile coaches have well-developed diagnostic frameworks for the social system: psychological safety assessments, team health surveys, BART analysis, ceremony observation, retrospective pattern analysis. They have almost no frameworks for the technical system — for understanding how the tooling, pipeline architecture, and workflow design are shaping the social dynamics the coach is trying to change.

The expanded diagnostic the joint optimisation principle requires asks a set of questions about the technical system that most coaches are not trained to ask. How does the delivery pipeline distribute work — to individuals or to the team? How are reviews and approvals structured — as personal queues or as shared responsibilities? How does the ticket system assign accountability for failures — to individuals or to the team? How does the tool landscape support or impede collaboration across functions?

The coach does not need to be a technical architect to ask these questions. They need to be curious enough about the technical system to look at it, and analytically capable enough to recognise when it embeds assumptions that contradict the social system being built.

What coaches can and cannot do

The coach cannot redesign the technical system alone. Deployment pipelines, code review tools, and ticket workflow architectures are organisational infrastructure — they require engineering decisions, IT involvement, tool procurement, and usually management authorisation. The coach who attempts to redesign these systems without appropriate authority will create different problems.

What the coach can do is make the mismatch visible. Naming the joint optimisation problem — "the team is configured for collaboration and the tooling is configured for individual accountability, and these two systems are in conflict" — is itself a significant intervention, because it reframes what the team is experiencing from a people problem to a structural one. This reframing changes what interventions make sense and who needs to be involved.

The coach can also build the case for joint redesign with the sponsor. Presenting the evidence of the mismatch — here is the collaborative norm the team has built; here is the individual-accountability structure embedded in the tooling; here is the friction that results — creates a conversation about technical system change that the coaching relationship is uniquely positioned to initiate.

Half the system is not enough

Trist and Emery's coal mine research showed that a superior technology, deployed without regard to the social system built around it, produces disappointment. The reverse is equally true: a superior social system, built without regard to the technical system it must operate through, produces the same result.

The team in the opening vignette was not underperforming because its members lacked the right mindset or the right practices. It was underperforming because two systems that needed to support each other were configured to oppose each other. The coaching agenda that addresses only the social system — more trust, more safety, better retrospectives — is coaching half the system. Joint optimisation requires that both systems be examined and, where necessary, jointly redesigned.