Stakeholder Communication — Translating Technical Reality

What engineers say vs what stakeholders hear:

Engineer: "We need to refactor the prescription approval workflow before adding
           the INR integration because the current architecture couples the domain
           logic directly to the HTTP layer and we can't test it properly."

Stakeholder hears: "The engineers want to spend 2 weeks doing something invisible
                    before the feature I asked for."

The same information, stakeholder-translated:
  "The prescription approval code was built quickly for the pilot — it worked fine
   for 50 patients but we're now seeing it strain at 200. Before we add the INR
   integration, we need 2 weeks to restructure this area of the codebase.
   If we skip this, the INR integration will take twice as long to build and will
   be fragile in production. Doing it now saves roughly 3 weeks overall."

The translation work is YOUR job as the tech lead.
Stakeholders cannot be expected to understand architectural concerns.
You must make those concerns legible in terms they care about:
  → time, cost, risk, patient safety, clinical outcomes.

Before any technical communication, answer: who is in the room and what do they care about?

Clinical Director:
  Cares about: patient safety, clinical workflow, regulatory compliance, ward disruption
  Doesn't care about: database choice, API design, CI/CD pipelines
  Frame as: "This change means pharmacists will get drug interaction warnings
              before approving a Warfarin prescription — currently that check is manual."

Product Manager:
  Cares about: delivery timeline, feature scope, user feedback, dependencies
  Doesn't care about: implementation details
  Frame as: "The INR integration will be ready in sprint 3, but it depends on the
              lab team sharing the INR API schema by end of sprint 1.
              If that's delayed, we'll push INR alerts to sprint 4."

Engineering Director / CTO:
  Cares about: risk, cost, team capacity, technical debt accumulation, hiring needs
  Frame as: "We're building on a modular monolith now — this is intentional and
              appropriate for the team size. I've documented the decision.
              We'll need to revisit if the team doubles or the Labs module needs
              independent scaling."

Finance / Commercial:
  Cares about: budget, ROI, vendor costs
  Frame as: "Moving to Azure OpenAI for the prescription copilot adds £800/month
              at current usage. The pharmacist time saving is estimated at 45 minutes
              per pharmacist per shift — for 12 pharmacists, that's significant
              clinical capacity that can be redirected to patient care."

The engineer's trap: committing to timelines without accounting for uncertainty

Wrong approach:
  "How long will the INR integration take?"
  "About 2 weeks."
  [3 weeks later, still not done]
  Stakeholder trust: damaged.

Right approach: ranges with assumptions
  "How long will the INR integration take?"
  "If the lab team's INR API is available as documented, we can deliver in 2 weeks.
   If we need to parse it from existing lab report PDFs instead of an API, it's 4 weeks.
   Which scenario are we in?"

Communicate the dependencies that affect the estimate:
  → "I can give you a firm date once I've reviewed the lab API documentation."
  → "The design phase is 3 days — I'll have a more accurate estimate then."
  → "This estimate assumes no unplanned incidents and that two engineers are dedicated."

Updating estimates when things change:
  Change estimates proactively — don't wait until the deadline to say it's late.
  "I wanted to flag that the INR integration is running 3 days behind estimate.
   We hit an undocumented edge case in the lab API. New expected date: [date].
   I don't need anything from you — I'm heads-down on it. Just wanted you to know."

This is counter-intuitive: delivering bad news early builds more trust than
good news delivered on time. Stakeholders can plan around early warnings.
They can't plan around surprises at the deadline.

Clinical tech leads deliver bad news more than most — safety issues, data problems,
compliance gaps, missed deadlines — all require clear communication under pressure.

Structure for delivering bad news:

1. State the situation clearly (do not bury the lead)
   BAD:  10 minutes of context → "...so there might be a small issue with the data."
   GOOD: "I need to tell you about a data issue affecting prescription records.
          Here's what happened, what the impact is, and what we're doing about it."

2. State the impact (what does this mean for clinical operations or patients?)
   "This affects prescriptions created between 14 March and 17 March.
    It means the INR value shown in the ward round view may be incorrect for 23 patients.
    We've identified the affected records — clinical staff should manually verify INR
    for those 23 patients before acting on the displayed values."

3. State what you know and what you don't
   "We know the cause: a migration script updated the wrong field.
    We don't yet know if any clinical decisions were made based on incorrect values."

4. State what you're doing
   "We have corrected the data. We are auditing all prescription actions for the
    affected patients in the window. We are contacting the clinical leads for each ward."

5. Give a timeline for next update
   "I'll have a full impact assessment by 14:00 today. I'll send a written summary."

Do not speculate, minimise, or over-promise.
In a clinical system, wrong data is a patient safety issue — treat it as such.

Status updates fail because they report output without meaning.
"This sprint we completed 14 tickets" — meaningless to a clinical director.

What status updates should answer:
  → What can the system do today that it couldn't do last week?
  → What is the team working on this week?
  → What are the risks and what's being done about them?
  → What decisions do we need from you (if any)?

Format that works:
  ✓ Delivered this sprint:
    - Pharmacists can now see drug interaction warnings before approving Warfarin
    - The ward round view now loads in under 1 second (was 8 seconds)

  → In progress:
    - INR integration with the lab system (completing next sprint)
    - Prescription audit export for MHRA compliance review

  ⚠ Risks to flag:
    - The lab API documentation is incomplete — we may need a 1-week extension
      for the INR integration if we can't get clarification by Thursday

  → Decisions needed from you:
    - The MHRA audit export format: should it include historical prescriptions
      from the legacy system, or only records created in ClinicalRx?

Written updates: concise, action items clearly marked, decision requests explicit.
Verbal updates: start with the headline, then detail on request — not the reverse.

Technical credibility is earned by:

1. Being right about outcomes (not just right in the room)
   Predictions you make about timelines, risks, and system behaviour come true.
   When you say "this will be a problem at scale" — and then it is — credibility grows.
   Don't overclaim. Better to under-promise and deliver than the reverse.

2. Translating complexity without condescension
   Stakeholders will ask "simple" questions that aren't simple.
   "Can't we just add a button for that?"
   Resist the impulse to explain why that's not how software works.
   Instead: "Yes — it'll take about 3 days to add the approval flow behind it.
   Let's align on the priority relative to the INR integration."

3. Flagging risks before they become problems
   Every risk you flag proactively that comes true (and you handle) builds credibility.
   Every surprise you deliver destroys it.

4. Showing your working
   ADRs, architecture diagrams, design documents — non-technical stakeholders
   who see that engineering decisions are documented and reasoned trust the team more.
   "We considered three options and chose this one because..." builds confidence.

5. Knowing your limits
   "I don't know — I'll find out" is more credible than a confident wrong answer.
   Clinical systems particularly: never guess on compliance or clinical safety questions.