Team decisions / Skills and contribution
Build the team around the work it must complete.
A capability list can introduce the disciplines a project may need. It cannot confirm who will join, when they can start or whether they have the relevant experience. Start with the outcome and its difficult handoffs, then identify the contributions, evidence and retained decisions needed to deliver it.
A map of contributions
A discipline describes work, not a confirmed assignment.
Nearshore engineering teams may combine product and design, application development, integration, data and AI, quality, and platform or operating skills. The relevant combination depends on the outcome, existing team and stage of work. Confirm the proposed contributors, their evidence, capacity, working overlap and responsibilities before treating a capability as available to your project.
- Continuous contribution
- Work that needs frequent decisions, implementation or review belongs in the team's regular delivery capacity. Identify the artifact and handoff that require that involvement.
- Scheduled specialist input
- Some questions need focused expertise at a known point. Agree the question, access, review window and how findings will be resolved. Being available for consultation is different from owning daily delivery.
- Retained client decisions
- Business priorities, domain rules, data permissions and acceptance need named authority. A nearshore contributor can inform these decisions, but a skills catalog does not assign the right to make them.
Six discipline areas
Ask what each contribution leaves behind.
The examples below describe work to plan and evidence to request. They do not imply that every project needs every discipline or that each area requires a separate full-time person.
Product, research and design
01Contribution: Make the user problem, workflow and acceptance criteria concrete.
- Relevant need
- The team is unsure which change will help or how people will use it.
- Needs from the team
- Access to users, business constraints, existing processes and a product decision owner.
- Example work
- Investigate a failed task and test an alternative interaction with relevant users.
- Retained decision
- The product owner prioritizes work and accepts the business tradeoff.
- Artifact to inspect
- Research findings, a tested flow and a decision explaining what changed.
- Missing handoff
- A polished screen arrives without the conditions or evidence behind it.
- Confirm
- Who resolves scope questions and who tests the experience with users.
Application engineering
02Contribution: Build maintainable behavior across the interface and application services.
- Relevant need
- The outcome requires working software with explicit states and rules.
- Needs from the team
- Accepted behavior, design constraints, data contracts and review standards.
- Example work
- Implement a request flow with loading, invalid input, permission and failure states.
- Retained decision
- Application and business owners accept behavior and authorize release.
- Artifact to inspect
- Reviewed code, relevant tests and an explanation another maintainer can follow.
- Missing handoff
- A feature works in isolation but its failures or permissions are untested.
- Confirm
- Which frontend, backend, mobile or domain-specific skills the actual application requires.
Integration and data engineering
03Contribution: Move information between systems while preserving meaning and failure evidence.
- Relevant need
- The change crosses APIs, events, source systems or reporting datasets.
- Needs from the team
- Source ownership, schemas, permitted access and definitions for identifiers and records.
- Example work
- Connect a status update, reject an invalid record and reconcile a repeated event.
- Retained decision
- System and data owners resolve source conflicts and approve data use.
- Artifact to inspect
- Contracts, mappings, provenance, replay behavior and reconciliation results.
- Missing handoff
- A successful transfer hides missing records or incompatible definitions.
- Confirm
- Who owns each interface and who handles data that cannot be reconciled.
AI and model engineering
04Contribution: Evaluate and integrate model behavior within a bounded task.
- Relevant need
- A model may help with a task and the team can compare it with a suitable baseline.
- Needs from the team
- Permitted examples, evaluation criteria, error consequences and domain review.
- Example work
- Test a candidate approach, inspect important failures and define rejection or fallback behavior.
- Retained decision
- Qualified reviewers accept evidence; business and application rules retain consequential authority.
- Artifact to inspect
- Versioned evaluation, relevant error analysis and the proposed operating boundary.
- Missing handoff
- A demonstration is treated as evidence of production reliability.
- Confirm
- Whether the work needs model development, applied integration, evaluation or operational expertise.
Quality and specialist assurance
05Contribution: Find material defects and make acceptance evidence repeatable.
- Relevant need
- The service has critical flows, accessibility needs or risks requiring focused review.
- Needs from the team
- Expected behavior, risk priorities, realistic environments and defect owners.
- Example work
- Exercise a critical flow, investigate a failure and verify the repair.
- Retained decision
- The service owner accepts residual risk with appropriate specialist input.
- Artifact to inspect
- Risk-based checks, reproducible findings and confirmation of affected behavior after repair.
- Missing handoff
- Testing is scheduled after the team has already committed to release.
- Confirm
- Who maintains everyday quality and when accessibility or security specialists are needed.
Platform and service operation
06Contribution: Make delivery, monitoring, recovery and maintenance workable.
- Relevant need
- The change must run reliably within an existing or proposed operating environment.
- Needs from the team
- Deployment constraints, access rules, release authority and support expectations.
- Example work
- Deploy an accepted change, detect a failure and restore a known state.
- Retained decision
- The service owner defines coverage and approves operational changes.
- Artifact to inspect
- Deployment records, useful alerts, recovery instructions and a receiving operator's check.
- Missing handoff
- Infrastructure exists but no one owns alerts or recovery outside the project.
- Confirm
- The division between platform engineering, cloud administration and ongoing support.
Four illustrative team shapes
Change involvement when the problem changes.
These are combinations of contributions, not staffing packages. The same person may cover more than one area if their capability and available time support it. Validate the interfaces between roles as carefully as the individual skills.
| Outcome | Regular contribution | Specialist input | Retained owner | Evidence before proceeding |
|---|---|---|---|---|
| Clarify a difficult workflow | Product, research and design | Technical feasibility and domain review | Product decision owner | Observed need and tested flow |
| Connect an existing service | Application and integration engineering | Security, data and platform review | System and data owners | Contract, failure and reconciliation checks |
| Evaluate a model-backed task | AI, evaluation and application work | Domain, privacy and operating review | Task and release owners | Baseline comparison and failure boundary |
| Maintain a live product | Application, quality and operation | Research, architecture or specialist assurance | Service owner | Accepted change and recovery evidence |
Build the contribution record
Follow one change across the team before naming the seats.
Suppose a customer portal needs to show the status of a service appointment. Use this illustrative change to identify the work and its dependencies before turning it into a staffing request.
- 01
Define the useful result
Describe what the customer must understand, where appointment status comes from and which actions are allowed. Identify the person who owns those definitions. A different interface does not settle ambiguous status rules.
- 02
Trace the difficult handoffs
Follow the status from its source through the integration to the portal. Include an outdated update, an unknown status and an unavailable service. Note where user research, application work, data judgment and operating knowledge are needed.
- 03
Assign involvement and authority
For each contribution, name the expected artifact and whether involvement is continuous or scheduled. Keep business approval, access decisions and release authority explicit. Add the retained team's capacity to the same record.
- 04
Check the proposed people
Request relevant work evidence from the contributors who would perform the assignment. Confirm actual availability, working overlap, competing responsibilities and any staffing conditions. A supplier's previous project is background evidence until linked to the proposed team.
- 05
Review the shape after learning
When the workflow, integration or operating risk becomes clearer, revisit the contribution record. Reduce, increase or change involvement based on the work remaining. Record the handover before essential context leaves the team.
Conditions behind the capability
Confirm the arrangement as carefully as the skill.
Government service guidance distinguishes a multidisciplinary team from access to other organizational specialists and changes the mix by phase. Apply that planning principle to your own work without importing its public-sector staffing rules.
- Keep assignment status explicit
- Record proposed, confirmed and still-to-be-sourced contributions separately. Attach the person or role, expected involvement, evidence and unresolved start conditions. Do not present a potential capability as reserved capacity.
- Schedule the scarce decisions
- Specialist advice is useful only if it reaches the team before the dependent decision. Agree review windows, required inputs and the person who resolves findings. Include your domain, security and application owners in that calendar.
- Test overlap through actual work
- Check the proposed contributors' working hours and try a written handoff or review exchange. Include holidays and decision coverage. Location alone does not establish communication quality or continuous availability.
- Make knowledge transferable
- Keep design decisions, interfaces, evaluation rules and operating notes in agreed team locations. Have another authorized colleague use them. When a role changes, revisit the work that depended on that person's context or authority.
Questions when planning the team
Use the role title as the start of the discussion.
The contribution and its evidence matter more than a long list of technologies.
- Which skills can a nearshore engineering team cover?
- A proposed team may cover product and design, application development, integration, data and AI, quality, platform or operation. Check the specific assignment and relevant evidence. This guide describes disciplines to consider, not a claim that every skill is currently available from Werkon or any supplier.
- Do we need a separate person for every discipline?
- No. Some contributors can cover several areas, and some specialist input can be scheduled. Check depth, workload and review independence where relevant. Combining role titles does not remove the underlying work or establish that one person has time to do it.
- Should the same team stay throughout the project?
- Continuity can preserve context, but the mix of work changes. Discovery may emphasize understanding the workflow; integration needs contracts and failure handling; live operation needs maintenance and recovery. Review the remaining work and arrange handovers before changing involvement.
- Does an AI feature require a dedicated model specialist?
- It requires access to suitable understanding of the model and its impact, but the precise contribution depends on the task. Integrating an existing model differs from training one. Identify the evaluation, data, application and operating work, then assess the proposed capability against those responsibilities.
- What turns a capability into a confirmed assignment?
- Confirm the proposed contributor or role, relevant evidence, capacity, start conditions, working overlap and responsibilities. Record substitutions and dependencies. A catalog entry, location or portfolio does not reserve a person for your work.
Source basis
The team and lifecycle guidance behind this map.
- 01
GOV.UK Service Standard
Have a multidisciplinary teamUpdated January 2026. Covers phase-appropriate expertise, decision makers, specialist access and understanding of AI. Government requirements are not presented as universal commercial staffing rules.
- 02
GOV.UK Service Manual
What each role does in a service teamMain role descriptions reviewed, including product, design, development, architecture, operation, analysis and quality. Last updated November 2023. Informs role boundaries, not supplier availability.
- 03
GOV.UK Service Manual
Set up a service team at each phaseFull phase guidance reviewed, updated January 2025. Distinguishes changing delivery needs, live operation and collaboration with other organizational teams. No fixed staffing ratios adopted.
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