Technical Design That Survives Handover (and the Bus Factor)

STORY TIME: Episode 2: “The Flight Plan”

Dispatcher Journal Entry: 15th Feb

Our briefings improved alignment, but we still had handover risk.

The flight plan was said to be “clear” until the lead pilot went off shift. Then we realised the route was written down, but the thinking behind it was not. We had lost the why behind the decisions: alternates, margins, constraints, and contingency paths that were understood in conversation but never captured.

So we upgraded the flight plan: not a long document, but a readable plan that any qualified pilot & crew could execute. Route, trade-offs, key decisions, and contingency paths. One page. Signed off.

Translation: Good technical design makes intent portable. It reduces bus factor, rework, and brittle “only X understands this” delivery.

---

Technical design is where uncertainty should be discovered

A good feature ticket tells the team what needs to be achieved.

A good technical design helps the team understand:

• how it should be implemented,
• what decisions have been made,
• what assumptions are being carried,
• where the edge cases are,
• what must be tested,
• and how another developer could continue the work if the original developer was unavailable.

The goal is not to create a long technical document that nobody reads.

The goal is to imagine the solution clearly enough before writing code so that the team can build, test, review, and hand over the work without relying on one person’s memory.

That distinction matters.

When design is skipped, developers still make design decisions. They just make them privately, under time pressure, while coding. That is where inconsistent naming, duplicated components, missed edge cases, and fragile implementation paths often begin.

---

Technical design should not be a solo activity

One of the biggest misconceptions about technical design is that it belongs to one person.

In mature teams, technical design is collaborative.

At minimum, the discussion should include:

• the technical lead or architect,
• the lead developer working on the story,
• the business analyst or product owner,
• and QA, especially where testing scenarios, devices, data, or workflow permutations matter.

For larger or higher-risk work, the broader development team should be involved too.

That may sound expensive, but it pays back quickly. When the team contributes to the design, the team understands the design. That means less handover risk, fewer repeated explanations, and less dependency on one person’s memory.

It also improves the solution.

A business analyst can clarify requirement intent.
QA can expose scenarios the developers may not immediately think about.
Developers can spot implementation complexity or technical constraints.
Architects can help ensure the solution fits the direction of the platform.

This is where better decisions are made.

Not because everyone agrees immediately, but because the right questions are asked before the codebase has already absorbed the consequences.

---

The BA should be close enough to clarify intent

Technical design is not purely technical.

If the team is designing the solution and the requirements are unclear, the business analyst or product owner should be close enough to clarify the intent there and then.

Otherwise, the design session becomes a chain of assumptions:

• “I think this means…”
• “They probably want…”
• “Let’s just build it this way and confirm later…”

That is dangerous, especially in financial services environments where small wording differences can have large consequences.

For example, “client”, “investor”, “account holder”, “beneficiary”, “portfolio”, and “mandate” may sound interchangeable to someone outside the domain.

They are not interchangeable in a codebase.

The wrong word can send the implementation in the wrong direction. Naming is not cosmetic. Naming shapes the model. The model shapes the behaviour. The behaviour shapes the product.

This is why ubiquitous language matters.

A mature technical design process forces the team to agree on the language before those words become classes, database fields, API contracts, reports, validations, and audit trails.

---

Good design reduces cognitive load during development

There is a misconception that technical design slows teams down.

Bad technical design does.

Good technical design does the opposite.

When a story is properly designed before development starts, developers are not constantly stopping to ask:

• Where does this data come from?
• What do we call this concept?
• What happens in this edge case?
• Is this validation client-side, server-side, or both?
• Does this need an audit trail?
• Who signs this off?
• What should QA test?
• Is this part reusable or feature-specific?

Those questions are valid. But if they are discovered mid-build, they break flow.

Every unresolved decision adds cognitive load. Every missing clarification creates friction. Every “quick check” becomes a context switch.

A good technical design clears the runway.

When development starts, the developer can focus on writing clean, high-quality code because the team has already agreed on the shape of the solution.

---

The design should live with the source of truth

The technical design should not be buried in a separate document that nobody can find.

Ideally, it should live directly on the feature ticket, requirement page, or source-of-truth document.

If that is not possible, it should be linked from there clearly.

The principle is simple:

If someone opens the ticket, they should understand both what needs to be built and how the team intends to build it.

That includes:

• the requirement,
• the technical approach,
• key decisions,
• assumptions,
• edge cases,
• validation rules,
• testing notes,
• and the implementation tasks.

This also improves traceability.

When a bug appears later, the team can go back and understand what was requested, what was decided, what was implemented, what was tested, and where the gap may have entered.

In regulated environments, that kind of traceability is not just useful. It is often essential.

---

The “Silly Question” rule

A strong design session should create space for simple questions.

In fact, one of the healthiest habits a team can build is this:

Everyone should ask at least one “obvious” or “silly” question during technical design.

Not to waste time. To expose assumptions.

Some of the best design discussions start with questions like:

• “Why are we calling it that?”
• “What happens if the user does this twice?”
• “What if this data arrives late?”
• “What if the user changes their mind halfway through?”
• “Is this always true, or only true for this product?”
• “Are we building this for now, or for where the platform is going?”
• “If we had to support another channel later, what would change?”

These questions often pull the thread that exposes the real issue.

They reveal hidden requirements, future constraints, incorrect assumptions, and overloaded terminology.

A mature team does not punish these questions. It welcomes them.

---

Break the work down while the thinking is fresh

Once the technical design is agreed, the team should create the implementation tasks immediately.

Not later. Not after someone has “had a look”.

There and then.

This is where the design becomes executable.

The team should break the feature into small, clear tasks or subtasks, such as:

• create domain model or entity changes,
• add validation rules,
• update API contract,
• build shared component,
• add database migration,
• implement service logic,
• update UI flow,
• add audit event,
• update automated tests,
• add QA test notes,
• update monitoring or logging,
• prepare release notes.

This does two important things. Firstly, it makes progress visible. Then secondly, it reduces handover risk.

If a developer is unavailable tomorrow, another developer should be able to:

• pull the branch,
• open the ticket,
• review the design,
• see the completed and remaining tasks,
• and continue without needing a full re-brief.

That is the practical meaning of reducing bus factor.

It is not about replacing people. It is about making delivery resilient.

---

Small tasks create momentum

The goal is to create small, achievable tasks that can ideally be completed in, say, 10–30 minutes. The time doesn’t matter so much, the idea of small does.
There is a human side to this:

• Large, vague tasks create drag.
• Small, clear tasks create rhythm.

When developers can pick up focused pieces of work and complete them cleanly, they build momentum.
Progress becomes visible: “One task down… OH! and another one.. WOW! I’m on a roll! Let me do another one!”.
Reviews become easier. Testing becomes more targeted.

This is not about turning engineering into a checklist exercise, it is about removing unnecessary uncertainty so developers can use their energy on the parts that matter: design judgement, code quality, integration, and problem-solving.

When the thinking is done well upfront, velocity often improves naturally because they stop losing time to avoidable ambiguity.

---

What a good technical design should cover

A practical technical design does not need to be huge, but it should be complete enough to make the work portable.

At a minimum, it should cover:

1. Requirement summary
   What are we solving, in plain language?

2. Business context
   Why does this matter, and where is the platform going?

3. Ubiquitous language
   What terms are we using, and what do they mean?

4. Technical approach
   How will the solution be implemented?

5. Components impacted
   Which systems, APIs, services, screens, jobs, queues, reports, or data stores are involved?

6. Data sources
   Where does the data come from, and which source is authoritative?

7. Business rules and validation
   What rules must be enforced, and where?

8. Edge cases and permutations
   What scenarios could break the happy path?

9. Testing considerations
   What must QA validate? Which devices, roles, permissions, or data scenarios matter?

10. Tasks and subtasks
    What needs to be built, in small executable pieces?

11. Open questions
    What still needs clarification before or during implementation?

12. Key decisions
    What trade-offs did the team agree on?

---

Last Boarding Call for all passengers

Part 2 Summary: If technical design in your team often lives in one person’s head, delivery becomes fragile.

At Protium, we help teams make delivery more resilient by connecting requirements, architecture, design decisions, implementation tasks, and testing considerations before development starts.

If you are seeing rework, late-stage clarification, inconsistent implementations, or key-person dependency in your delivery process, we can help you assess where the handover risk is entering the system and put a practical technical design process in place.

Reach out to us for a delivery process or architecture review, and we can help your team move from requirement to implementation with clearer intent, better handover, and less rework.

How We Build: Foundations > Foresight > Future-Proof

---

The Artifact: Technical Design Flight Plan Template

Click to view the checklist

---