Team decisions / Establishing delivery
Make the first change test the team setup.
A dedicated team needs a shared product purpose and a workable way to make decisions, review changes and preserve knowledge. Establish those conditions before expanding the backlog. Then follow a small, useful change from question to acceptance and use the difficulties it exposes to improve how the team works.
From assignment to operation
A roster names people. The working agreement connects their decisions.
A dedicated development team brings sustained contributions to a defined product or service. To establish it, agree the outcome, required disciplines, decision rights, onboarding support, quality expectations and knowledge ownership. Confirm capacity and dependencies, then check that the team can complete a useful change within those boundaries. Keep revising the arrangement as the work changes.
- Product direction
- A named client owner decides which problem matters, supplies domain context and resolves competing priorities. An external team needs timely answers as well as a backlog.
- Engineering leadership
- A technical owner coordinates design, review and engineering tradeoffs. Contributors need room to propose solutions within agreed constraints, with escalation for changes that affect business risk or scope.
- People and delivery support
- Name who handles capacity, development, feedback, dependencies and team health. These responsibilities may sit with different people; make their handoffs explicit rather than assuming the technical lead owns everything.
Six operating commitments
Write the agreement around work the team must be able to do.
Choose the disciplines from the product's needs and existing capability. The commitments below then connect those contributions. They are not a fixed staffing package or a requirement to add a separate person for every responsibility.
A bounded purpose and decision path
01Commitment: Define the product boundary, near-term outcome and who resolves competing requests.
- Purpose
- Several stakeholders can send work to the same team.
- Prepare
- A prioritized problem, domain contacts, constraints and explicit acceptance authority.
- Put it to work
- Bring an ambiguous request to the right owner and record the resulting decision.
- Accountable owner
- The client product owner sets priority; technical leadership advises on consequences.
- Inspect
- A short team agreement and a decision linked to the work it changed.
- Failure to notice
- Contributors receive conflicting instructions and silently choose the business tradeoff.
- Review when
- The roadmap, stakeholders or service boundary changes.
Onboarding that supports a real contribution
02Commitment: Prepare context, permitted access, a working environment and a named source of help.
- Purpose
- A contributor is joining or moving into an unfamiliar part of the product.
- Prepare
- A setup guide, system map, development data, review path and suitable first task.
- Put it to work
- Let the contributor run the relevant checks, ask questions and submit a bounded change for review.
- Accountable owner
- The onboarding owner coordinates support; system owners approve access.
- Inspect
- A working environment, a reviewed contribution and corrections to the setup instructions.
- Failure to notice
- A completed checklist hides unusable access or missing domain understanding.
- Review when
- A newcomer cannot follow the documented path without private assistance.
A cadence for decisions and feedback
03Commitment: Give planning, dependency resolution, demonstration and improvement a clear purpose.
- Purpose
- Work crosses working hours, disciplines or client teams.
- Prepare
- Shared work records, agreed overlap, decision channels and escalation expectations.
- Put it to work
- Review a working change with the people who can answer the next question.
- Accountable owner
- The delivery owner maintains the process; the relevant decision owner supplies the answer.
- Inspect
- Visible dependencies, accepted work and improvement actions with owners.
- Failure to notice
- Meetings report activity while decisions and blocked work remain unresolved.
- Review when
- The same obstacle returns or some contributors cannot participate effectively.
Quality before acceptance
04Commitment: Agree what evidence a change needs before it can be accepted or released.
- Purpose
- The team is learning the product's failure modes and operating constraints.
- Prepare
- Behavior expectations, review standards, relevant tests and release authority.
- Put it to work
- Review the implementation, exercise important failures and resolve material findings.
- Accountable owner
- Reviewers assess the evidence; the authorized owner accepts business and release risk.
- Inspect
- A reviewable change with tests, known limits and recovery information where relevant.
- Failure to notice
- Merged code is treated as proof that the user outcome or production readiness is established.
- Review when
- A defect, incident or new requirement exposes a gap in the acceptance criteria.
Knowledge that another person can use
05Commitment: Keep system context and operating instructions with the work, accessible to the client.
- Purpose
- An important explanation currently lives with one contributor.
- Prepare
- A place for decisions, setup steps, interface contracts and operating notes.
- Put it to work
- Have a colleague use the instructions and repair what they cannot follow.
- Accountable owner
- The team maintains records; the client owner confirms durable access and ownership.
- Inspect
- Findable, current instructions and a successful receiving-person check.
- Failure to notice
- Documentation exists but cannot answer the next maintainer's question.
- Review when
- Behavior, dependencies, responsibilities or contributors change.
Sustainable participation and continuity
06Commitment: Make workload, useful feedback, development needs and substitution visible.
- Purpose
- The engagement depends on sustained involvement rather than a short assignment.
- Prepare
- Real capacity, support for learning, feedback channels and a transition plan.
- Put it to work
- Discuss recurring friction with contributors and assign actions within the team's control.
- Accountable owner
- People managers handle employment and development; client and supplier owners coordinate assignment changes.
- Inspect
- Resolved obstacles, reviewed workload and a current handover path.
- Failure to notice
- Attendance or ticket output is used to infer satisfaction, or retention is assumed from the contract label.
- Review when
- Workload, motivation, role fit or assignment availability changes.
Six setup diagnostics
Investigate the obstacle before judging the team.
These observations are prompts for investigation, not automatic diagnoses. Ask the people doing the work and examine the actual decision or handoff. A single delay does not establish poor capability.
| Observed signal | Check first | Possible setup gap | Decision owner | Evidence of repair |
|---|---|---|---|---|
| Repeated priority changes | Who requested and approved each change? | Competing product authority | Client product owner | One current priority and visible tradeoff |
| First task cannot start | Environment, access and task context | Incomplete onboarding dependency | Onboarding and system owners | Contributor can run the relevant workflow |
| Work waits for review | Review ownership and available capacity | Unassigned or overloaded reviewer | Engineering lead | Named review path and resolved queue |
| Demonstrations miss the need | Acceptance criteria and user feedback | Weak domain or product feedback | Product and design owners | Agreed behavior tested with suitable evidence |
| Only one person can recover | Instructions and a receiving-person check | Knowledge concentrated in one place | Technical and service owners | Another authorized person can follow the steps |
| The same friction keeps returning | Contributor feedback and prior actions | Unresolved workload or working conditions | People and delivery owners | Action completed and effect reviewed |
The first-change exercise
Follow a useful change through every handoff.
Illustrative example: improve how an existing service explains a rejected request. Keep the change small enough to inspect, but include the real business rule, interface, review and acceptance path. This checks the setup; it does not prove the team can yet handle every future assignment.
- 01
Agree the behavior
The product owner explains the rejection rule and the user need. The team records the desired behavior, constraints and evidence needed for acceptance, including what the change must not disclose.
- 02
Prepare and reproduce
A contributor uses permitted development access and data to reproduce the current behavior. Their onboarding contact resolves missing context or setup steps and updates the shared guide.
- 03
Implement and review
The team makes a bounded change, tests relevant states and asks the named reviewer to inspect it. Record any unresolved question with the person authorized to answer it.
- 04
Accept and release deliberately
Demonstrate the behavior and relevant failure checks. Separate code review, business acceptance and release authorization. Confirm the receiving operator and recovery needs before any live change.
- 05
Improve the setup
Review where the change waited, which explanation was missing and whether another contributor can use the updated records. Assign improvements, then check their effect during subsequent work.
Keep the arrangement current
Review the conditions behind delivery, not just the output.
Once the first change is accepted, use normal work to check whether the agreement still fits the product and the people contributing to it.
- Confirm capacity and dependencies
- Distinguish assigned contribution from assumed availability. Account for review, support, learning and planned absence when choosing work. Escalate a dependency before it becomes an unspoken delivery commitment.
- Listen without inferring from activity
- Ask contributors what is helping or hindering their work. Give them a suitable route to raise concerns and show what changed in response. Ticket counts and online presence cannot establish job satisfaction.
- Test continuity during ordinary work
- Share review and explanation where appropriate. Ask a second authorized person to follow a setup or operating procedure. Repair the missing knowledge while the original contributor is still available.
- Make substitutions explicit
- Agree notice, transfer responsibilities, access changes and receiving-person acceptance when assignments change. Preserve context and client control without promising that a particular person will remain indefinitely.
Questions while establishing the team
Ask how the arrangement will work on an ordinary change.
The answers should identify a responsibility, an artifact or a decision the team can demonstrate.
- What makes a dedicated development team successful?
- Start with a useful product outcome, complementary contributions and clear decision rights. Then establish the conditions for implementation, feedback, quality and continuity. Inspect accepted work and the obstacles behind it. A dedicated label or a full roster does not establish success, and no setup method guarantees the eventual result.
- Who should lead the team?
- Separate product authority, engineering leadership and people or delivery support. The client needs an accountable source of priorities and domain answers. Technical leadership coordinates engineering decisions within that boundary. Name who handles capacity, feedback and escalation; one person need not own every responsibility.
- How long should onboarding take?
- There is no fixed duration in this guide. The starting context, system complexity, access and role all matter. Use evidence such as a working environment, a reviewed contribution and the ability to explain relevant behavior. Resolve missing dependencies instead of using elapsed time alone to declare someone ready.
- Does the team have to use Scrum or daily meetings?
- Choose a rhythm that supports decisions, coordination, feedback and improvement. A method can provide useful practices, but a meeting calendar is not acceptance evidence. Include people working remotely or across hours, keep decisions in shared records and review whether the chosen rhythm is resolving real obstacles.
- How do we support retention without depending on one person?
- Discuss workload, meaningful contribution, tools, feedback and development with the people involved. Act on the conditions you can improve and confirm assignment expectations separately. At the same time, maintain usable documentation and shared understanding. Supporting continuity and preparing for changes are compatible; neither guarantees retention.
Source basis
Team practices and research behind the operating questions.
- 01
GOV.UK Service Standard
Have a multidisciplinary teamJanuary 2026 guidance informs phase-appropriate contributions and access to decision makers. Government staffing requirements are not imposed on commercial teams.
- 02
GOV.UK Service Manual
Agile tools and techniquesUpdated March 2026. Main guidance reviewed for inclusive participation, shared work, reviews and retrospective actions. No particular meeting duration or agile method is prescribed here.
- 03
GitLab Handbook
Developer onboardingMain onboarding guidance reviewed September 2026; last modified May 2026. A public example connecting environment setup, workflow, security, quality and assigned code review. Its infrastructure and tool choices are not adopted.
- 04
DORA
Documentation qualityCapability guidance reviewed September 2026, drawing on 2021 and 2022 research. Supports attention to clear, findable, reliable and maintained documentation. Research uplift figures are not used as predictions.
- 05
DORA
Job satisfactionCapability guidance reviewed September 2026. Informs questions about tools, meaningful work, development resources and direct contributor feedback. It does not establish a retention guarantee for a specific team.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD