An urgent API change: seven questions to plan the work before you rush

The message arrives with a deadline: a supplier is retiring an application programming interface, or API, that your product uses. An API lets one piece of software request information or actions from another. The integration needs updating, and your team already has a full plan.

It is tempting to turn the deadline straight into a list of development tasks. Before that happens, someone needs to establish what must keep working, what can wait and who can make the necessary decisions.

A short set of planning questions can help you do that. Here is a practical adaptation inspired by a British Army planning approach.

The UK Defence connection

The Combat Estimate, commonly described as the Seven Questions, is a British Army planning method. A Centre for Army Leadership discussion paper on metacognition connects it with examining a task, resources, timing and constraints.

The seven prompts below are my adaptation for tech teams. The useful connection is the discipline of understanding a situation before choosing and coordinating actions.

A practical tech example

For example, a software company’s reporting product imports transaction summaries from a partner API. The partner has announced that the old version will stop working in six weeks. The new version changes the response format and how results are split across multiple requests.

The team needs to preserve accurate reporting for existing customers. It does not yet know whether the migration also requires changes to historic reports. Bring engineering, testing, product and support into the planning conversation, with someone who can resolve priority conflicts.

How to put it into practice

1. What is changing, and what do we know?

Purpose: Separate confirmed facts from assumptions.

Read the supplier’s retirement notice and migration documentation. Confirm which version is used, where the integration runs and which customer reports depend on it. Record the source and date of each important fact.

“Only the import job needs changing” belongs on the assumption list until someone has checked its consumers. Give that investigation an owner and a decision date.

2. What outcome must we protect?

Purpose: Give the work a clear purpose.

Write an outcome people can test: existing customers can receive complete, accurate transaction reports after the old API closes. Agree how completeness and accuracy will be checked.

Keep optional improvements visible but separate. A request to redesign the reporting screen should be considered against the migration deadline and available capacity.

3. What needs to change, and where?

Purpose: Find the affected parts of the service.

Map the import job, stored data, report calculations, scheduled processes and support guidance. Check error handling as well as the successful response.

In this example, request pagination could leave a report looking valid while missing transactions. Include a test dataset large enough to require several requests, with an expected total to compare against.

4. What people and resources are available?

Purpose: Make the plan possible within actual capacity.

Confirm access to a supplier test account, representative test data and colleagues who understand the integration. Check leave, existing commitments and supplier response times.

If a developer can only contribute two days a week, plan around that. Ask the priority owner to decide what moves, rather than quietly relying on overtime to close the gap.

5. What depends on what, and when?

Purpose: Build a workable sequence.

Work backwards from the retirement date. Allow time to investigate the response changes, implement them, test realistic reports and observe the new integration before the old one closes.

Name dependencies explicitly. Testing cannot start with representative data until the partner test account is ready. Put an owner and needed-by date beside that dependency.

6. What support and authority are needed?

Purpose: Resolve decisions that cross team boundaries.

Agree who approves displaced work, contacts the supplier and briefs support. Decide who can stop the migration if report totals do not reconcile.

Record unresolved choices with a deadline for escalation. “Waiting for a decision” should tell readers what decision, from whom and what happens if it arrives late.

7. What will make us pause or change the plan?

Purpose: Prepare to respond to new evidence.

Choose review points and conditions that require a different approach. Examples include incomplete test data, mismatched totals or a supplier test environment arriving too late.

Document what rollback can and cannot achieve. Returning to the old API may help before retirement; it cannot provide continuity after the supplier switches that service off. Agree the remaining options with the service owner.

A record you can use

What to try next

Try these questions on one urgent change before committing to a delivery date. A short conversation may expose a dependency that deserves investigation before the rest of the work starts.

If you are new to product or delivery, you do not need to supply every technical answer. You can help by making the missing answers, their owners and their consequences clear.

Source: Centre for Army Leadership, Leadership Insight No. 48: Exploring Metacognition (January 2024). The tech examples and working tools are Coded Female adaptations.