People leadership in engineering: structure shapes behaviour

Look at the system before the person

W. Edwards Deming argued that most failures come from the way work is organised, not from the people doing it. His often-cited estimate puts the large majority of problems on the system and management, and a small remainder on individual causes. You do not need the exact figure to use the idea: when the same mistake keeps happening to different people, the system is the thing to change.

Cognitive load is a real constraint

A team can only hold so much in its head. Matthew Skelton and Manuel Pais, in Team Topologies, treat cognitive load as the limit that decides how much a team can own well. Their answer is to design teams around the work: teams that own a flow of value end to end, platform teams that make that easier, and enabling teams that help others learn. If a team owns too many things, quality drops, however good the people are.

Structure comes first, and it shows up in the code

Conway’s observation that systems mirror the communication structure of the organisation that builds them is a leadership tool. If two teams keep blocking each other, look at ownership and boundaries before blaming individuals. Moving a boundary can remove a recurring conflict that no amount of coaching would.

Find the constraint

Eliyahu Goldratt’s Theory of Constraints says a system’s output is limited by its slowest step. Improving anything else does not help. In engineering the constraint is often review, testing, release approval or a single overloaded expert. Map the flow of work, find where it waits, and fix that first.

Safety is how teams learn

Amy Edmondson’s 1999 study of work teams found that psychological safety, the belief that you will not be punished for speaking up, was linked to how much teams learned from their mistakes. Ron Westrum described a spectrum of organisational cultures, from pathological to generative, and the DORA research has linked generative, high-trust cultures to better delivery performance. In practice this means treating incidents as information.

How to run a blameless review

1. Write the timeline from what people knew at the time, not from what we know now.
2. Ask how the system made the mistake easy, and what would have made it hard.
3. List changes, each with an owner and a date.
4. Share the write-up widely, so other teams can learn from it.
5. Check back that the changes happened.

People Leadership in Engineering is 12% of the ATP exam and 10% of the CTP exam, and 15 to 20% of the PgTP and PfTP exams, where leaders work across teams. See exam facts.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.