The task is on track. Is the team? A three-part check for tech delivery

The feature is nearly finished. The remaining tickets look manageable, and the demo date still seems possible.

One developer is answering every technical question. Support has not seen how failures will be handled. A newer colleague is completing assigned tasks but cannot yet explain how the whole feature works.

Would you describe that delivery as on track?

A useful model from British Army followership asks us to consider the task, the team and the individual within their wider context. Adapted thoughtfully, it gives tech colleagues a way to notice what a task board may be missing and turn that observation into a practical decision.

The model behind the check

The British Army’s 2023 Followership Doctrine Note presents an action-centred model with three connected areas: achieving the task, building teams and developing individuals. Its diagram adapts John Adair’s Action Centred Leadership model, with a follower overlay, and places the three areas within the operating environment.

For tech, I would translate that into three questions: are we delivering the right outcome, can people work together effectively, and do individuals have the capacity and support to contribute?

These are connected areas to review, rather than three stages to complete. The example and working questions below are my adaptation. You can use them while contributing to someone else’s initiative, as well as when you are leading one.

Start with the context

For example, a software company is adding a spreadsheet import to its inventory product. Shop managers will upload a file of item codes and stock quantities instead of entering every item manually.

The team has promised a demonstration in two weeks. One experienced developer understands the import rules. A newer developer is building the results screen, while a support colleague needs to explain rejected rows to customers.

Before reviewing the three areas, establish the context. Is the upcoming event a demonstration using test data, a customer pilot or a production launch? Who will use the feature, and what decisions have already been made? A polished demonstration and a supported customer release need different evidence.

In this example, the event is a demonstration, with a pilot decision afterwards. Write that down so nobody quietly treats “demo ready” as permission to release to customers.

How to put it into practice

The task: protect the outcome

Purpose: Check what needs to work and how the team will know.

Start with the customer’s job: updating stock quantities accurately, with enough information to resolve an import that cannot be completed. “The upload button works” is too narrow a definition of success.

Ask how the import handles unknown item codes, repeated rows and a file containing both valid and invalid entries. Agree the intended behaviour before treating any of those cases as finished. For the demo, use an approved test file with known results, including a file that should be rejected.

A colleague contributing to the feature could ask: “What should the customer see if one item appears twice?” That question gives product and engineering something specific to resolve. If the answer changes the work, the priority owner needs to decide what fits before the demo.

Record what has been demonstrated and what still needs checking before a pilot. Completion should describe evidence of the agreed behaviour.

The team: make collaboration workable

Purpose: Check whether information and responsibilities can move between people.

Look at how the work joins up. The developer building the results screen needs agreed error information from the import process. Support needs wording that matches what the product actually does. Neither should have to reconstruct the rules from scattered chat messages.

Arrange a short walkthrough using the same test file. Ask engineering to show what the import returns, the newer developer to show how those results appear and support to explain what they would tell a customer. Record mismatches as shared work with named owners.

If every answer depends on the experienced developer, agree time to document the key decisions or pair on one uncertain part. Ask the delivery lead to account for that time in the plan. Helping the team should not mean one person absorbs every interruption while keeping their original workload.

Trust also needs visible follow-through. When someone identifies a gap, acknowledge it, agree who will act and tell them what changed.

The individual: support a sustainable contribution

Purpose: Check capacity, learning and the ability to ask for help.

Ask each colleague what they need to complete their part of the work. The newer developer may need an explanation of the import rules before they can make sensible decisions about the screen. The experienced developer may need focused time without becoming unavailable to everyone.

Agree one bounded learning opportunity. The newer developer could trace an unknown item code from upload to customer message with support available, then explain the flow back. Give the learning time a place in the work plan.

Make limits discussable. “I can finish the results screen or investigate the new file format today; which matters first?” provides useful information for a priority decision. It is more workable than silently trying to do both.

Self-management helps, but staffing, priorities and an excessive workload also need decisions from those who own them. An individual raising a capacity problem should not have to solve the team’s entire resourcing problem.

A record you can use

Use a short check before the next delivery decision:

Context: what event or decision are we preparing for, and what has changed?
Task: what outcome needs evidence, and what is still uncertain?
Team: where is the work blocked by an unclear handover or dependency on one person?
Individual: whose capacity or learning needs must the plan account for?
Decision: what will change, who owns it and when will we review it?

For the import feature, the team could keep the demo to an agreed file format, schedule the shared error-handling walkthrough and pair on one uncertain flow. The product owner confirms the reduced demo scope, the technical lead owns the walkthrough and the delivery lead makes room for pairing.

Revisit the decision after the demo and before committing to a pilot. These changes are proposals to verify, rather than proof that the feature is ready.

What to try next

Bring these three areas to one planning conversation this week. You do not need to redesign the whole delivery process. Choose the most important gap and agree one change that reaches the work plan.

If you are contributing without a leadership title, start with an observation: “The import tasks look nearly complete, but support has not seen the error messages. Can we include a walkthrough before deciding on the pilot?”

Progress includes the outcome being delivered and the people’s ability to carry it forward. A good review makes both visible before the next commitment.

Source: British Army, A British Army Followership Doctrine Note (2023), section 4, paragraph 24 and Figure 2, printed page 8. The tech examples and working tools are Coded Female adaptations.