Could you explain why every team exists?
Teams are often described in terms of the systems they operate or the activities they perform, rather than the user needs they help meet.
Ask most teams what they do and you will get a list of systems, services or activities. "We look after the payments platform." "We do data engineering." "We run the integration layer."
Ask who is better off because of that work, and the room often goes quiet for a moment.
A team that can only describe itself in terms of a system is a team whose purpose is being inferred rather than stated. The system is real, and looking after it is real work, but the system exists for a reason. Somebody needs something, and the system helps meet that need. When the reason is not visible, prioritisation gets harder, hand-offs multiply and the team is judged on the health of the system rather than on whether the need is being met.
This matters for flow because teams that understand the needs they serve make better local decisions. They can tell the difference between a request that advances the need and one that merely keeps the system busy. They can push back on work that does not serve anyone, and they can notice when a need has changed and the system has not.
It is worth being clear about what this does not mean. It does not mean that every team must serve an external, paying customer. Most organisations have many internal users: a platform team’s users are the teams that build on the platform; a data team’s users might be analysts and decision-makers inside the business. Enabling capabilities that help other teams work more effectively are legitimate and valuable. The test is not whether the user is external. The test is whether the user can be named and the need can be stated.
Making the chain visible
User Needs Mapping is a way of drawing this chain explicitly. It starts with users, asks what they need, identifies the capabilities required to meet those needs and then shows which teams steward those capabilities. Laid out on a single map, the relationships that were previously held in people’s heads, or not held at all, become something a group can look at and discuss.
The exercise often produces two kinds of finding. Some teams turn out to have a clear and direct line to a user need, and the map simply makes explicit what they already knew. Other teams find the line is tangled, shared with several other teams, or missing a link. Neither finding is a verdict. Both are useful, because once the chain is visible it can be improved.
If several teams can only describe their purpose in terms of the same system, what does that tell you about where the real boundaries are?
Shared language about users and needs is often more revealing than the org chart.
Rich Allen
Rich Allen is a UK-based sociotechnical architecture consultant. He helps organisations improve the flow of value through people, teams, technology and organisational structure. He is the author of User Needs Mapping: Aligning Teams Around What Matters, a long-standing Team Topologies Valued Practitioner and the creator of the Fast Flow Toolkit.
He works with engineering and product leaders to make the flow of work visible and to change team boundaries on evidence. Flow Awareness Sessions are a low-commitment place to start.
Have a question worth exploring together?
Sometimes an outside perspective helps make a difficult organisational problem clearer. If one of these questions resonates, I’d be happy to explore it with you.