STORY TIME: Episode 1: “Pre-Flight Briefing”

Ground Crew Journal Entry: 9th Feb

This week, we reviewed another delayed departure that wasn’t caused by weather, mechanical failure, or crew availability.

No. It was caused by assumptions.

Dispatch expected one route. The crew planned another. Compliance had a third set of constraints. Everyone did their part, but the parts did not align early enough.

So we introduced a simple pre-flight briefing across all three streams to capture the destination, constraints, success criteria, and “what changes if…” scenarios.

Nothing fancy. Just shared clarity before the work starts.

Translation: If business goals, constraints, and non-negotiables aren’t aligned upfront, engineering will build the wrong thing very efficiently.

---

The quiet failure mode: “We shipped it… but it’s not right”

Most delivery issues aren’t caused by a lack of effort. On the contrary, everyone is often trying to do their part, play for the team, and move the work forward.

They happen when the context is fragmented:

• Business knows what they want now and communicates the immediate need clearly.
• Engineering sees the ticket and optimises for delivering what has been requested as quickly and cleanly as possible.
• Quality assurance, security, or compliance joins when the work is done to ensure there are no issues.

On the surface, everything may look fine. There may not be a visibly broken feature. But underneath, the damage often looks like this:

• The feature works today… but fights the platform tomorrow
• Implementation choices harden too early because the future direction was never shared. Later requirements are then forced onto technical foundations that were never designed to support them.
• Late surprises appear after go-live because constraints arrived late. These are often solved under pressure with less-than-ideal decisions, creating delays, operational friction, and a more fragile system over time.
• Rework becomes normal. QA feedback arrives late. Timelines drift. The system quietly accumulates complexity through small patches, exceptions, and workarounds. Hundreds of small paper cuts are left behind and over time they compound.

That is how legacy systems are born.

Not through one dramatic failure, but through small misalignments that compound until delivery slows, confidence drops, and every new change feels harder than it should. That is the real cost: not one big failure, but death by a thousand paper cuts.

This is a hard pill to swallow in regulated environments (financial services included), where delivery success is not just “did it work”, but:

• Can we explain what we built, why we built it, and how it aligns with the business case?
• Can we prove controls and approvals were followed?
• Can we operate it safely under real-world pressure?
• Can we ensure delivery teams were not blocked by avoidable technical friction?

---

Alignment isn’t just “this feature”

Here’s the simple principle:

Alignment isn’t just agreeing on the next waypoint. It’s agreeing on the destination.

If developers only ever see tickets (the now), they’ll naturally optimise for local delivery:

• get it done quickly
• match the acceptance criteria
• close the work

But when engineers understand the trajectory (where the product/platform is going), they can make better decisions early:

• what should remain flexible vs what can be concrete
• where to invest in stronger foundations
• what to keep simple because it’s a dead-end path

That’s not “over-engineering.” That’s avoiding wrong turns. It is one of the differences between simply implementing tickets (“just coding”) and engineering a system with its future direction in mind. Our manifesto/How-We-Build focuses on Foundations > Foresight > Future-Proof

---

What “shared vision” actually means (without turning into long meetings)

This does not require a re-org, a new methodology, or a big process overhaul. It requires one repeatable ritual before work starts:

The Pre-Flight Briefing

A ~30–45 minute alignment session that produces one written output:

• a one-page brief/requirement on a ticket (A.K.A. a shared “source of truth”)
• plus a Definition of Ready gate for the work

This briefing answers:

• Destination: what are we building and why?
• Trajectory: where is this likely going next? Extrapolate where it could (at a high level) mutate to next month, quarter, year and beyond?
• Constraints: what must be true for compliance/security/operations to sign off?
• Success: how will we measure “done” beyond “it works”? What is the acceptance criteria?
• What changes if…: what events could force us to revisit decisions? Interrogate blind spots or areas that are out of control, such as downstream integrations and dependencies.

The key is that it becomes a deliverable, not a conversation that fades after a meeting.

Who should be in the room?

Keep it small and practical:

• Business owner / Product Owner / Key Business Stakeholder (can confirm outcomes and priorities)
• Tech Lead / Architect (can confirm feasibility and trade-offs)
• Delivery lead / SME (can confirm slicing and sequencing)
• Quality Assurance/Compliance/security representative (as needed)

Too many people = wasted time/resources and often also causes confusion by bringing the wrong people into the fold or bringing them in too early.

Too few people = wasted time/resources as you’ll have probably have repeated conversations, a game of broken telephone, and teams filling in the gaps themselves.

And one simple rule:

If someone can veto the approach later, bring them in early enough to avoid rework.

When to run it?

Run a pre-flight briefing when any of the following are true:

• it introduces new workflows, new areas of the system, fundamental changes to the system or new/updated integration decisions
• it touches sensitive customer data, facilitates money movement/transacting, statements, reporting, or auditable entities
• it has compliance/security requirements (explicit or implied)
• it’s cross-team (multiple systems, vendors, or dependencies)
• it’s “simple” but high-impact (simple changes can still have high risk)

---

The outcome you’re aiming for

A good pre-flight briefing creates three things:

1) A shared mental model

Everyone leaves with the same answer to:

• “What are we doing?”
• “Why are we doing it and why does it matter?”
• “What’s non-negotiable?”
• “What does success look like?”
• “Where is this likely going to go in future?“

2) Better engineering decisions

Engineers can design and build with the destination in mind, not just the ticket. Thus making the right foundational decisions early on and limiting system technical debt.

3) Faster delivery (through less rework)

You don’t go faster by skipping alignment. You go faster by removing surprises and friction in the development and delivery process.

---

Final checks

“Doors armed and cross-check”

If you want a quick test of whether you’re aligned, ask the following:

• Can the business owner state the top 3 success criteria in one minute?
• Can the tech lead state the top 3 constraints in one minute?
• Can both agree on what is explicitly out of scope for this release?
• Can any developer, after reading the pre-flight checklist, state 3 criteria of what the business is trying to achieve with the initiative/epic, and why, in one minute?

If not, you’re not ready to build. You’re about to discover the missing decisions later… When they’re expensive.

---

Signals you’re getting this right

You’ll notice alignment improving when:

• Fewer clarification questions appear mid-sprint
• Fewer tickets get reopened due to “misunderstanding”
• Fewer instances of business stakeholders needing to ask “Are we still going to be able to have xyz” or “Is ABC included in the {month} deadline?” in demos.
• Less late-stage scope creep (“oh also…”, “can’t we just…”, “It should be easy..”)
• Reduced variance in cycle time (delivery becomes more predictable)
• Fewer QA feedback item/surprises late in the process (STG or PROD environment)

---

Last Boarding Call for all passengers

Part 1 Summary: If business goals, constraints, and non-negotiables aren’t aligned upfront, engineering will build the wrong thing very efficiently. Stay tuned for Part 2 and more, where we will go into more detail on how a well defined technical design process makes intent portable, speeds up delivery and minimises key person dependencies.

If you want to implement a pre-flight briefing in your organisation, get started with the pre-flight briefing template supplied below. Alternatively, reach out via our contact page on the site, so that we can assist you in implementing this effectively and tailor it to your environment.

At Protium, we run a lightweight Delivery Alignment Review to help teams identify where alignment is breaking down before delivery risk becomes visible. As part of this review, we:

• take one active and one upcoming initiative from your pipeline
• sit in on scoping, requirements, design, technical design, handover, and demo sessions
• facilitate a structured pre-flight briefing with the right people
• produce a finished one-page brief and Definition of Ready gate
• identify the process gaps most likely to create rework, delivery risk, or technical debt

How We Build: Foundations > Foresight > Future-Proof

---

The Artifact: Pre-Flight Briefing Template

Use this as a 1-page document (or a single Jira/ADO/Notion page) and make it part of your Definition of Ready.

(Prefer the raw markdown? Send us a message in the contact page asking for the Pre-Flight Briefing Template and we’ll email it through to you)

Tip: Keep it short. If it turns into a novel, you’ve lost the point.

Click to view the checklist

---