Organizing Execution

Human Teams, Expertise and Specialist Agents

How to separate job titles, roles, competence, accountability and decision rights; how team boundaries shape the flow of value; and how to give…

Chapter 41Organizing Execution

A studio has two people and several software agents. One agent has prepared some code, five reviewer agents have declared it correct, and a release agent proposes deploying it. Yet the change touches the check that stops users from reaching other people's accounts. Who decides whether this capability is needed at all, who is entitled to assess the threat, who can approve the release, and what evidence should halt the automated flow?

Learning outcome. After this unit you will be able to tell apart a job title, a role in the work, competence, accountability and decision rights; explain how the type of work, experience, workload and team boundaries affect the flow of value; choose a suitable mode of interaction between teams; and define the boundaries of a specialist agent so that its output can be verified while accountability and important decisions remain with an authorised person.

Prerequisites. You need a general understanding of the product and research work discussed in Jira, Work Tracking and the Studio Operating System, Architectural Thinking and Dependency Graphs, as well as the ideas of delegation, state and verification from The Orchestrator Pattern. This unit deals with organisational decisions, not with configuring a particular piece of software or with actually reorganising a team.

The unit has three consecutive parts: the human team and expertise; team boundaries as described by Team Topologies; and the division of work between people, deterministic checks and software agents. Principles drawn from books about people and organisations are not empirical evidence that an agent behaves like a person. Wherever we apply them to agents, we say so explicitly and label it as a design decision or a cautious inference.

Teams, professional work and expertise

This part shows how to distinguish a job title from competence and from the right to decide, and how to match work to a team's skills and constraints. It relies on the general prerequisites of this unit: an understanding of product and research work.

A job title does not settle a particular decision

The word "role" is used to mean several different things. To avoid letting authority leak from a title into an action, separate five concepts:

Concept The question it answers Example
Job title What is the person's place in the organisation or employment agreement? Platform engineer, consultant, head of product
Role in a task What work is the person doing in this specific situation? Gathering evidence, changing the data schema, reviewing access control
Competence What knowledge and skills show they can do the work properly? Can explain the threat model, reproduce the scenario and demonstrate the check
Accountability For which outcome does the person or team answer, and what must they keep running? The team owns the service's health and resolves its incidents
Decision right Who is authorised to choose between options, accept a risk or permit a consequence? The service owner approves the launch after the defined checks

These concepts overlap, but none of them automatically proves another. The title "architect" does not prove competence in a particular system. High competence does not give someone the authority to change an access policy. An executor may be accountable for the quality of the evidence they prepared without having the right to accept a risk on the client's behalf. In the same way, you can call an agent a "security agent", but the name alone says nothing about its competence and gives it no right to approve an exception.

For every task, write down explicitly: who initiates the work; who does it; who checks the result; who holds the final decision right; who will support whatever follows from it; and what evidence is required before moving to the next step. One person can perform several of these functions, but the boundaries must stay clear. In a small team, the product owner may both write a requirement and implement it; that change of authorship must not quietly turn a self-check into an independent approval.

A team is neither a list of job titles nor a count of people busy at the same moment. It is a relatively stable system of mutual coordination: people know whom to ask, how work is divided, how handovers happen, who maintains the result and how risks are reported. Stability here means the opportunity to build shared understanding and trust over time, not a ban on changing the membership or the way of working. When every result is handed each time to a new set of people without context, the cost of explaining, finding the owner and re-checking keeps growing.

Professional services: matching work to capability

David Maister treats a professional firm as a system that must align different types of client work with skills, client interaction and the development of its people. In his article on the anatomy of a consulting firm, "finding, minding and grinding" are simplified kinds of contribution, not universal job titles or a mandatory structure for every company. He also describes different practice models through analogies with a pharmacist, a nurse, a brain surgeon and a psychotherapist, to show that the degree of standardisation, diagnosis and client contact varies. This is a useful professional perspective, not a proven taxonomy for all engineering teams (Maister, "The Anatomy of a Consulting Firm").

The practical conclusion is limited but important: first establish the nature of the work, and only then choose the people, the training and the way they interact. New, ambiguous work with a high cost of error should not be distributed as if it were a repeatable task with settled criteria. Conversely, sending every standard step to the most experienced specialist creates a queue and takes away the time they need to diagnose hard cases. Check whether the repeatable part can be codified, taught to others, backed by a tool-based check, or reduced so that the expert sees only the exceptions.

In his article on results and rewards in the multi-group firm, Maister warns against short-term management by utilisation and hours alone. Systems, methods and training can, over time, make it possible to hand the typical part of the work to a less senior person, freeing the senior one for more complex diagnosis. This is the author's view of professional services; it should not be turned into a guarantee of productivity growth or a direct recipe for automation (Maister, "Results and Rewards in the Multi-Group Firm").

David C. Baker approaches expertise as the ability to notice recurring patterns within a narrow field, to build a distinct market position and to value the right diagnosis. The author's own site presents the ideas of the book The Business of Expertise and its view of the difference between entrepreneurship and narrow advisory expertise; it is not an independent assessment of effectiveness (the author's site and book description). For a team this means that expertise is not simply long tenure, nor the number of tools on a profile. Useful signs are relevance of experience to this class of problem, the ability to name the signals and counterexamples that distinguish one case from another, and the ability to explain how a conclusion can be checked. Niche specialisation can raise the value of an accurate diagnosis, but it can also create dependence on one person. So keep examples, criteria, decisions and learning opportunities, without assuming that all experience can be fully transferred in writing.

Focus, trust and working conditions

In the third edition of Peopleware, Tom DeMarco and Tim Lister discuss interruptions, fragmentation of working time, team cohesion, an environment for focused work and management's attitude towards people. The publisher provides the table of contents, the preface and a sample chapter on leadership, but not the full text of the book in open access. In the sample, the authors contrast leadership as "extracting work" through authority with leadership as service, support and innovation (sample chapter "Let's Talk About Leadership"; publisher's page for Peopleware, 3rd edition).

Applying this to a modern engineering team is an interpretation of their ideas, not a guarantee that every interruption is harmful or that all people work the same way. Frequent urgent messages, meetings without decisions and sudden shifts in priority can make uninterrupted work difficult. It makes sense to batch requests, define a channel for urgent escalation, put the context into the ticket, and distinguish a genuine outage from ordinary curiosity. At the same time, critical on-call duty or urgent help may be a necessary part of the job. The aim is to design the system so that interruptions have a reason, an addressee and a way back to the interrupted work, rather than to blame the person who receives the requests.

A leader who removes obstacles, aligns priorities and explains who holds the decision right is doing more than demanding a faster pace. A manager can protect boundaries for focused work, resolve a dependency conflict, approve training or record who bears the consequences of a decision. Trust and psychological safety do not mean an absence of standards or of difficult feedback. They should make it easier to report uncertainty, mistakes and disagreement before the cost of fixing them grows. Mentoring and joint diagnosis help spread experience; a stable team can accumulate context, but it needs time and healthy conditions for that to happen.

A study of 51 work teams in a manufacturing company found a link between psychological safety and learning behaviour. That observation does not prove the same causal effect in every team, but it supports a practical question: can people report uncertainty, mistakes and disagreement early and receive a constructive response? Edmondson, 1999.

Deadline pressure is also an organisational choice, not a property of an individual executor. The third edition of Peopleware has chapters titled "Quality—If Time Permits" and "Teamicide", and the publisher separately offers a sample in which DeMarco and Lister criticise leadership as a mechanism for squeezing out more work. The openly available table of contents confirms that the authors examine quality, deadlines and actions that damage team cohesion; because the full text of those chapters has not been worked through here, this is no basis for attributing to the authors a precise universal list of causes or a measured effect. The practical conclusion of this unit: when a date is fixed, the manager must explicitly agree the scope, the risk, the evidence and what will be dropped or postponed. Do not silently compress research, review and recovery time, do not set teams against each other in artificial competition, and do not punish people for reporting a problem early. Otherwise the team loses trust and quality quietly becomes optional. This is a question about the process, not a diagnosis of a particular manager (table of contents and sample of Peopleware from the publisher).

In The Mythical Man-Month, Frederick Brooks warns against the simple arithmetic which assumes that adding people to a late software project reduces the time linearly: new people have to be brought up to speed, and interdependent work adds coordination. In the chapter on coordination he considers pairwise communication channels under a particular pattern of task interdependence. That model is not a schedule forecast for a specific team: dependencies, tools, task structure and people's maturity all differ. In the chapter on conceptual integrity he discusses the benefit of consistent system decisions and a clear architectural vision. This is not an argument that one person should decide everything alone, nor proof that more executors are always worse. What matters for a complex system is consistent concepts, a clear decision owner and a process in which experts can raise objections and present evidence (the book and edition in its Google Books bibliographic record; Brooks's text on the Carnegie Mellon site).

Worked case: two people in a studio, plus agents

Picture a small product studio. Marta is responsible for the product and the client's requirements; Danylo for implementation and maintenance. One agent researches documentation, a second creates a patch on a test branch, a third looks for authorisation bugs and a fourth drafts the release notes. The client asks for sign-in by invitation from a colleague. The coding agent has made the changes, and five reviewer agents have agreed that "the logic looks correct".

First Marta, as the owner of the product decision, clarifies the expected behaviour: who can invite a colleague, to which address, with what expiry and permissions, and how an invitation is revoked. She can ask an agent to research the options, but the agent does not decide on its own which roles the client needs. Danylo checks the impact on the code and on support: token expiry, reuse of the link, logging, email delivery failures and the ability to revoke. The product decision remains Marta's. In this example a qualified external specialist assesses the threat, and the authorised owner of the client's data separately accepts or rejects the residual risk. Marta, as the designated release owner, approves the release only after that risk acceptance has been recorded and the technical evidence has been received; Danylo carries out the deployment within the agreed limits. If the client has not named a risk owner, or Marta's authority to release has not been established, the change stops until such a decision is made. Calling an agent a "security reviewer" gives it no right to accept the risk or permit the release.

Each agent receives a narrow assignment with inputs, permitted actions and the evidence it must return. The researcher returns links to the current documentation and a list of open questions. The implementing agent proposes changes and describes what it did not change. The reviewer agent has to compare the requirement with the actual logic and present a concrete risk scenario. Automated checks verify formatting, types and known test cases. Danylo integrates the results and reviews the change in the shared state. Once the client has accepted the residual risk and the required technical checks have passed, Marta is the only designated owner of release approval; Danylo supplies the technical evidence and performs the deployment, but does not bypass checks that have not been completed. This is an arrangement within this example, not a general rule for every studio.

If the product has no designated security owner, the work cannot be "approved" by agents' votes. Marta and Danylo record the gap and pass it to the client; they can bring in a competent specialist to assess the threat, but they do not accept the risk in place of the authorised owner. The release stays on hold until the client names such an owner and that person accepts or rejects the risk. For two people this may be slower than fully automating a single release, but it matches the real authority and consequences. If the check shows that an invitation link still grants access after it has been revoked, the release is stopped until the logic has been fixed and the restored state verified.

This division does not require four permanent agents, nor does it prove that more specialisation is always useful. If an experiment shows that a separate reviewer agent merely repeats the ordinary tests, the team can remove that step or change its criteria. What matters is not the role diagram itself but a complete loop of verification and accountability: the author of a change is not the only source of its verification, the decision is not delegated to an unauthorised agent, and the consequence has a designated owner.

One participant in a Reddit discussion describes a small software company where the owner combines development, support, finance, sales and bug fixing and has no time to grow the business; the replies suggest various paths but do not confirm their results. This is one personal account and not evidence that a small studio must hire someone, narrow its niche or automate its work. It is useful only as a reminder to ask concrete questions about workload, invisible duties and the owner's constraints (discussion in r/smallbusinessuk).

Team boundaries and the flow of value: Team Topologies

This part shows how to recognise whether a need for expertise calls for temporary help, a stable specialised boundary or an internal service run like a product. It assumes you can already separate roles, ownership and the nature of the work, as covered above.

Think in terms of boundaries of joint work

Team Topologies is Matthew Skelton and Manuel Pais's approach to organising human teams around the flow of work and the management of cognitive load. The second edition was published in 2025; this part uses its authors' concepts but does not turn them into a single mandatory structure. The authors describe four team types and three modes of interaction between them on the official key-concepts page (the second edition and book description; Team Topologies key concepts). The typology concerns human organisation; borrowing its names for agents does not prove that software executors have human team dynamics.

The starting question is not "which job title should we add?" but "where does the valuable flow stall, and why?". Cognitive load is the volume of concepts, decisions, systems and exceptions a team must hold in mind at once to do its work. If one team has to know every product, the infrastructure, the security rules and all the internal libraries, its context can become excessive. If the work is split too finely, every step creates a handover, waiting and a dependency on another team. Look at the whole path from a user's need to a working result: waiting time, queues, repeated requests, failures and how often feedback arrives.

The four team types are design lenses, not judgements about how important people are:

Team type Main orientation When it may fit The point at which it gets in the way
Stream-aligned A continuous flow of value for a defined segment, product or user When the team can own a coherent part of the product from change through to support When every ordinary change needs several external approvals and handovers
Enabling Temporary mentoring, removing obstacles and transferring a missing capability to another team When a team has found a specific gap and needs to learn to act on its own When temporary help has become a permanent queue or hidden ownership of another team's product
Complicated-subsystem A specialised part of the system that requires deep technical or mathematical expertise When rebuilding that specialised capability in every product team would be unreasonable When the boundary has grown too wide and teams wait for every detail to be changed
Platform An internal product that reduces the infrastructure burden on stream-aligned teams When many teams repeat similar infrastructure work and can be given self-service When the platform has become a mandatory approval step or hides complexity behind an unstable interface

The name of a type does not replace checking actual behaviour. A "platform" team can behave like a ticket queue, and a stream-aligned team can be so overloaded that it finishes nothing. Check whether unnecessary handovers have decreased and whether the team clearly owns its outcome.

Three interaction modes

Interactions have different goals, time frames and boundaries of responsibility:

Mode What it is for Typical finished result Example boundary
Collaboration Jointly exploring a new or ambiguous problem when both sides need the context An answer to a defined question, a joint decision or a tested prototype Limit the time and the goal; revisit the mode once uncertainty has dropped
X-as-a-Service One team provides a clearly described capability that the other uses on its own A documented interface, a stable result, clear support and a self-service path Name the owner, quality terms and channel for reporting faults; the consumer should not have to negotiate manually for every ordinary request
Facilitation Temporarily helping another team learn, work through an obstacle or change its way of working A transferred capability, a removed obstacle or an exit plan The expert helps but does not take indefinite ownership of someone else's work

Do not keep collaboration going indefinitely: once both teams understand the requirement and the contract, move to a service or end the collaboration. Do not disguise temporary facilitation as a permanent dependency. Choose the mode according to the nature of the work, and revisit it when that nature changes. The official Team Topologies material defines these three modes as collaboration, X-as-a-Service and facilitation; the specific time frames and conditions in the table are a working interpretation for planning (official key concepts).

A platform is an internal product

A platform is useful only when internal users can reach their own outcome with less effort. The existence of a team, a portal or a centralised service does not prove that the platform has been adopted or that it has shortened anyone's work. Start with a recurring user problem, the smallest set of capabilities that solves it, clear documentation, support, and a way to measure usage and gather feedback. An internal product has owners, users and a life cycle just like any other product.

Do not turn the platform team into an "approver of everything". If a service only adds a request form and waiting without a clear result, it moves the queue instead of removing the burden. If using the platform is mandatory but its interface does not let users see the state for themselves, diagnose a typical failure and safely retry an operation, it is not yet a fully self-service offering. At the same time, an internal product does not have to be universal: a narrow, reliable capability can be more useful than a large set of rarely needed features.

Worked case: the infrastructure queue keeps growing

A product company has six teams. Each separately asks one expert to configure logging, backups and environment permissions. New changes stall whenever that person is on holiday. Calling the expert a "platform team" is not enough; first separate the different needs.

  1. Find the repeatable work and the risk boundary. Establish which configurations are identical, where domain expertise is needed and which actions genuinely require separate approval. Record the age, size and impact of the queue. You cannot automate exceptions for which no policy has yet been defined.
  2. If knowledge is missing, start with facilitation. The expert works with a product team on one representative case, explains the risk model, helps create an instruction or template and agrees self-check criteria. The exit condition: the team can handle the standard case and knows how to recognise and escalate an exception.
  3. If a recurring need has become shared, create an internal service. A small platform group can provide documented standard templates and automated environment creation. Product teams run the safe standard scenario themselves, see its state and can roll back a change following a defined procedure.
  4. If the problem concerns one complex component, keep specialised ownership. The owner of the complicated subsystem may accept changes, but a written contract and checks allow other teams to carry out adjacent safe tasks on their own.
  5. Decide where manual approval stays. If a request grants broad access, changes the retention policy or involves regulated information, it goes to the authorised owner with the necessary evidence. Self-service does not abolish access management.

After the initial transition, the teams check whether standard requests really are completed without a manual queue, whether the escalation mechanism is clear and whether the templates are stable. If every real case turns out to be unique, a broad platform should not be built; sometimes facilitation and documentation are enough. And if the platform goes unused, the reason is investigated together with its users rather than adoption being forced through a campaign.

A first-hand case: Backstage at Spotify

Spotify describes how its platform group created Backstage for finding services, tools and documentation. In its own engineering post, the company mentions new employees' difficulty finding context, frequent context switching, and duplication of similar internal services. The company presents its choice as an internal product for developers and explains why it took a path that respected its autonomous culture instead of issuing a simple centralised mandate (Spotify Engineering, "A Product Story: The Lessons of Backstage and Spotify's Autonomous Culture").

This is a useful example of how a large organisation describes an internal platform, the problem of discovering context and the way it brought teams on board. It is Spotify's own first-hand account: its figures and positive assessment should not be presented as an independent audit, as proof of causation or as a forecast for a small studio. The transferable lesson is more modest: name a concrete internal need, make the product useful to its users and check actual usage; do not treat a high level of autonomy as evidence that internal duplicates will disappear on their own.

Conway's law as feedback, not a verdict

Conway's law links the structure of an organisation's communication system to the structure of the systems it builds. It is best read as a caution: lasting boundaries of responsibility and channels of collaboration influence which interfaces and dependencies a team tends to build. It does not mean that the org chart mechanically determines the architecture, or that a reorganisation is needed every time the code structure is hard to change. Architecture is also shaped by legacy systems, technology, domain constraints, standards compliance and compatibility requirements.

Use the observation as a cycle: the flow of work shows where boundaries create delays; the team changes how it interacts; then it checks whether the flow has changed and whether new costs have appeared. Team Topologies structures should likewise be adapted along with services and needs, not fixed once and for all. Do not make staffing changes based solely on a finding that a team "does not match" a diagram.

Specialist agents in a team of people

This part shows how to define an agent's bounded work, separate its output from a human decision, and choose the appropriate check. It assumes an understanding of team boundaries from the Team Topologies part of this unit and of state, evidence and handover of work from The Orchestrator Pattern.

Specialisation is a work contract

A specialist agent is a software executor configured for a bounded type of work and the tools available to it. Its specialisation can be set by context, instructions, sources, permitted actions, response format and verification criteria. It does not necessarily mean a different base model; conversely, a different model does not by itself create useful specialisation. An agent is not a member of a human team in any legal, employment, professional or moral sense. A person or organisation is responsible for the system, the permissions, the decisions and the consequences.

OpenAI's vendor documentation shows two specific patterns in its toolkit: handing control to a specialist that owns the next response, and calling an agent as a bounded tool while the main agent remains responsible for the final answer. The documentation advises giving specialists narrow tasks and separating them when different instructions, tools or policies are needed. This is product guidance for the implementation it describes, not an organisational law (OpenAI, "Orchestration and handoffs"). Anthropic describes chaining, routing, parallel calls, an orchestrator with workers and evaluation loops as patterns to be combined according to measured need; the same material also warns about the costs and the compounding of errors in autonomous execution (Anthropic, "Building Effective AI Agents").

This leads to a useful question for the process owner: "What specific kind of work should become easier, what can this executor see and change, and how can its output be verified independently?" If the only answer is "the agent will be the architect" or "let's build a team of agents", the names do not yet define any work. Instead you might say: "It will check the declared changes to the authorisation contract against two official sources and the current schema; it will return discrepancies with exact references, without changing the code and without deciding whether to accept an exception."

Breaking work down into roles

The following table is a starting scheme for dividing tasks, not a catalogue of job titles or a claim that every operation needs its own agent. Actual access is determined by the real system and its permissions; describing a role does not create those rights automatically.

Kind of work Input and useful questions Who or what can do it Expected evidence Decision boundary
Product decision The user's request, product constraints; who has the problem, how does the change help, what is unacceptable? The authorised product owner; an agent can synthesise feedback or prepare alternatives Clear behaviour, assumptions, deferred questions and the chosen option The agent does not determine value, target policy or a promise to the client without defined authority
Research A narrow question, acceptable sources, a date and a sufficiency criterion; is the source authoritative and current? A person, or an agent with web search, a repository or documentation Links, minimal excerpts, the date, context and what remains unknown Synthesis does not turn an unverified claim into a fact; resolving a contradiction belongs to the content owner
Architecture Requirements, current state of the system, constraints; what are the alternatives and consequences? An architect, the team, an agent for analysing dependencies and options A comparison of options, a migration path, risks, testable invariants The final choice is authorised by the designated technical owner, with the necessary involvement of the team
Implementation An accepted requirement, scope of change, method of verification; what is the smallest compatible patch? An engineer, or an agent within an isolated environment A diff, a description, reproducible steps and verification results Writing a change does not mean accepting it, releasing it or confirming it is secure
Testing Expected behaviour, invariants and examples of failures; what could refute the hypothesis? A deterministic check, a tester, an agent proposing edge cases Results of specific tests, cases covered, gaps and limitations A green suite confirms only the conditions it checked; the agent does not invent missing guarantees
Security Trust boundary, data, threats, controls; who can gain access and what could go wrong? A competent person or team; an agent can search for defined patterns and check configuration A threat scenario, the vulnerable surface, evidence, proposed mitigations Decisions to accept a risk, grant an exception or reach a regulatory conclusion remain with an authorised person
Review The changes, acceptance criteria and independent sources; what is a counterexample to the author's claim? A colleague, a specialist, or an agent for one particular aspect Findings with their location in the change, the reason, severity and evidence Voting, the number of reviewers and confident wording do not replace verification
Release and support An approved change, a recovery plan, the state of the system; are monitoring, user communication and rollback ready? The service owner, the on-call person, automated deployment within agreed limits Version, state change, check results, observability and confirmation of recovery An automated step does not grant the right to an unsafe release; whoever answers for the consequences is defined in advance

Specialisation should reduce confusion about what evidence is needed. If it creates more handovers, duplicates checks or hides who must answer an open question, the boundary should be reconsidered. Sometimes it is better to give one executor a bounded analysis plus a machine check than to create several personas with the same sources and blurred accountability.

Three different executors: a person, an agent, a deterministic check

A person is best suited to decisions that require context, experience, a value judgement or the authority to accept the consequences. That does not mean people do not make mistakes, or that every human decision needs a manual procedure. Important decisions can be prepared with facts, checklists and independent verification.

An agent can search, synthesise, propose options, prepare changes and carry out work with tools in the environment it has been given. Its report that a task is done is a claim that must be checked against files, logs, tool output or the source system. Information carried over from the context of a previous run may be stale; the agent may lack knowledge, carry hidden assumptions or lack the necessary access. So a new run must not inherit decision rights just because a similar task succeeded before.

A deterministic check is code or a rule that produces a reproducible result for the same inputs: for example, type checking, schema validation, formatting, comparing a checksum or forbidding a vulnerable permission. It suits a stable, formal condition. But a green check attests only to the claim that was actually checked: correct formatting does not prove value to users; passing tests does not mean the right requirement was chosen; a policy or legal decision cannot be reduced to a test unless a competent owner has defined a formal condition.

In a reliable process one type of executor does not stand in for another: a model can propose a case; a test can reproduce it; a specialist can assess its severity; the owner can accept or reject the residual risk. Sometimes the same person or system carries out every step, but the distinction is needed so that nobody calls a guess evidence or calls execution authority.

Worked case: five approvals, one wrong condition

Suppose five agents receive the same assignment: "Verify that an invited user cannot read a record before accepting the invitation." The team's requirement says: "A valid invitation grants access to the profile." Every agent reads the same requirement and the same check function and sees the same condition, invitation_status == accepted. All five agree. But the product policy in another source says that the pending status should allow access only to the acceptance page, not to the profile. The error lies in a wrong interpretation of "access" that both the requirement and the agents repeated.

The number of approvals does not create five independent pieces of evidence here. The reviewers share the same inputs, dependencies and blind spot. They may have reduced the likelihood of a missed syntax error, but they did not check whether the requirement was authoritative. The responsible team stops the integration and formulates the precise dispute: "Which resource should be accessible in the pending, accepted and revoked states?" The product owner sets the behaviour, the security owner confirms the boundary of private data, and the implementer changes the logic. The test matrix covers all three states and different resources. Then someone who did not write the change checks it against the canonical decision, rather than re-asking the same requirement.

If the context or the source of the requirement cannot be established, the decision does not move to "approved". The product owner clarifies the contract; if needed, the person responsible for the data or for access is brought in. This step may delay the release, but it makes the unknown visible. Five identical answers indicate a shared signal, not automatic independence. For genuinely independent verification you must separate sources, criteria or methods, and then still decide who will examine any disagreement.

Worked case: a reviewer who keeps being interrupted

Iryna is the only experienced engineer who has to review several changes to a critical library. Authors send her separate messages: a link without context, a new version of a patch, a "take a quick look" request and a clarification about an approach she has already rejected. Iryna interrupts one review to open another, and each time has to work out again what has changed, which criterion applies and whether it is the same commit. The delay is not evidence of a lack of diligence on the reviewer's part; the process forces her to rebuild lost state every time.

The team changes the handover itself. The author opens a single request with a link to the exact state of the change, a short goal, acceptance criteria, a list of changed files, the results of checks already passed, known risks and a specific question for the reviewer. Each new version updates the same record and clearly marks what is new. Non-urgent requests go through a single queue; an urgent request carries a visible reason and the required response time. For a recurring error the team adds an automated check or a clear template, rather than simply telling Iryna to be more careful.

Iryna can reserve a block of time for reviewing, and the rest of the team knows who takes urgent questions during that block. This protects focus without creating an untouchable special position. Where possible, the team teaches others to review the standard parts, leaving Iryna the complex architectural or security questions. The new arrangement works if fewer reviews bounce back for lack of context, if people stop losing track of the current version, and if risk — not just the number of closed requests — drives priority. Do not measure Iryna by the number of patches she approves: that would encourage superficial review.

Accountability and stopping

Before running an agent step, define:

  • what the expected artefact is and how to tell it apart from an assumption;
  • which sources take priority, and as of what moment their currency must be checked;
  • which tools are allowed, and whether the agent may only read, propose changes or apply them;
  • which side effects are forbidden or require a separate human decision;
  • which criteria require it to stop, hand over an ambiguity or decline to draw a conclusion;
  • who integrates the result and is responsible for the next state;
  • who has the right to accept risk and to authorise an external consequence.

If the team cannot name the decision owner, that is not a signal to give the agent more autonomy. It is an unresolved gap in the process. Appoint an authorised owner or stop the step until one is defined. If a person approves the result, they need the facts and the uncertainty, not just the agent's recommendation. If an agent has changed something in a shared space, check the current state itself, because an earlier report may already be out of date.

Summary

Work from the nature of the task, the competence it requires and the authority involved, not from the name of a job title or an agent. How teams are organised affects workload, queues and access to context; the Team Topologies types help describe that relationship but are not a staffing template. Focus, stability and mentoring need a process that does not hide obstacles or shift blame onto an individual. Specialise agents only for concrete work with defined evidence, tool boundaries and a decision owner. Reviews and automated checks support human accountability, but they do not create it in a person's place.

Further reading by topic

Book Which topics of this unit it helps deepen
Team Topologies, 2nd edition Cognitive load, team types, interaction modes, the internal platform and boundaries between teams
Peopleware, 3rd edition Focus and interruptions, team stability, supportive leadership, cohesion and working conditions
David Maister, Managing the Professional Service Firm and related writing by the author Matching the type of work to skills, training, and the balance between short-term utilisation and building capability
David C. Baker, The Business of Expertise Recurring patterns, focus and the diagnostic value of expertise
Frederick P. Brooks Jr., The Mythical Man-Month Costs of coordination and onboarding, conceptual integrity and the limits of arguments about team size

Sources and further reading