Career Growth and Visibility — Getting Promoted

Passive career development:
  → Show up, do the work, hope someone notices and promotes you
  → Wait for your manager to tell you what to do to advance
  → Assume good work automatically leads to recognition

Active career development:
  → Know what the next level looks like and work toward it deliberately
  → Have explicit conversations with your manager about growth
  → Seek out the work that builds the skills you're missing
  → Make your impact visible — not through self-promotion, but through clear communication

The harsh truth about passive development:
  Good engineers who wait to be noticed often get passed over for promotion.
  Not because they're not good — but because promotions require advocacy,
  and advocacy requires your manager to have a clear picture of your impact.
  If you don't help build that picture, someone else will.

The tech industry myth: "my code will speak for itself."
Code is judged by the people who read it and the system it runs.
If the right people don't see it, know its context, or understand its impact —
it doesn't advance your career, however good it is.

Most engineering career ladders have these dimensions, weighted differently per level:

Junior Engineer:
  Technical scope:   implements well-defined tasks within a feature
  Independence:      needs guidance on approach, frequent check-ins
  Impact:            quality of their own code
  Collaboration:     receives feedback and implements it
  What gets you here → what advances you: broader ownership, less supervision needed

Mid-level Engineer:
  Technical scope:   owns a feature end-to-end (API, domain, DB, tests)
  Independence:      works from requirements without needing approach guidance
  Impact:            feature or component quality and delivery
  Collaboration:     gives and receives useful code review feedback
  What gets you here → what advances you: cross-cutting impact, mentoring others

Senior Engineer:
  Technical scope:   designs components and modules, sets technical direction for a feature area
  Independence:      breaks down ambiguous requirements into deliverable tasks
  Impact:            raises the quality or velocity of the people around them
  Collaboration:     influences team technical decisions, mentors mid-level engineers
  What gets you here → what advances you: org-wide impact, leading initiatives

The mistake engineers make: continuing to do what got them to the current level.
What got you from junior to mid is individual output.
What gets you from mid to senior is multiplying the team's output.
The skills that advance you are different from the skills that brought you here.

Have this conversation with your manager every 6 months:

"I want to grow to [next level]. Can we talk about what the gap looks like today?"

Prepare for this conversation:
  1. Know what the level above yours requires (read the career ladder)
  2. Self-assess honestly: where are you strong vs where are the gaps?
  3. Have 1–2 specific projects in mind that would build toward the gap
  4. Ask your manager: "Am I seeing my gaps accurately? What would you add?"

A good manager response gives you:
  → Specific skills or behaviours that need development (not vague "be more senior")
  → Context on how you compare to others at the target level
  → Concrete opportunities to demonstrate growth

If your manager says "you're doing great, keep it up" — press further:
  "That's helpful. What specifically would I need to demonstrate to be promoted to senior?
   Can you give me an example of what success looks like for someone at that level?"

If you still don't get specific guidance:
  → Look at the career ladder and interpret it yourself
  → Look at engineers at the target level — what are they doing that you're not?
  → Talk to a mentor outside your team for perspective

Making impact visible is not self-promotion.
It's giving your manager the information they need to advocate for you.

Your manager goes to promotion calibrations.
They defend your case to other managers and senior leaders.
They need evidence, not just impressions.

How to make impact visible:

1. Brag document (internal)
   Keep a running list of your contributions: features shipped, bugs caught, mentoring done,
   design decisions made, incidents resolved. Update it monthly.
   Before your performance review or promotion conversation: share relevant items with your manager.
   Not as a boast — as information: "Here's what I've been working on this quarter."

2. Write about technical decisions
   ADRs, design documents, post-mortems with your name on them.
   Permanent, searchable evidence of your thinking and impact.

3. Communicate completions clearly
   "The INR integration is deployed and running in production.
    It's reduced manual INR lookups by 80% based on the first week of data."
   Not: "I finished the INR work."

4. Connect your work to outcomes
   "The prescription search improvement reduced query time from 8s to 1.2s —
    pharmacists on Ward B said this made their morning drug round significantly faster."
   The outcome matters more than the implementation.

5. Visibility beyond your team
   Presenting in a department tech talk, writing an internal blog post,
   contributing to company-wide architecture discussions.
   Impact you have outside your immediate team demonstrates senior-level scope.

Promotions that succeed are rarely surprises.
If you're surprised by a promotion — you probably weren't advocating enough.
If you're surprised by a non-promotion — something wasn't communicated.

The promotion conversation (when to have it):
  → Not: "I've been here for 2 years, I deserve a promotion."
  → Yes: "Based on our growth conversations, I believe I'm ready for senior.
          Can we talk about how to make the case at the next calibration?"

What your manager needs from you:
  → Evidence of impact at the target level (not just current level)
  → Examples of the senior-level behaviours (mentoring, design ownership, scope)
  → Your brag document or equivalent

What you need from your manager:
  → Honest assessment of your readiness (not just encouragement)
  → Clarity on timing — is this calibration or the next one?
  → What specific things would strengthen the case if there's doubt

If the promotion doesn't happen:
  → Ask for specific, actionable feedback: "What would I need to demonstrate?"
  → Get a timeline: "If I do X and Y, when would you feel comfortable making the case?"
  → If the answer is vague or the goalposts keep moving: that's information about
    whether this is a development gap or an organisational problem.

Promotions at different companies:
  At small companies: promotions can be fast but may not be systematic.
    Advocate for yourself and ensure compensation keeps pace with responsibility.
  At large companies: promotions are calibrated — your manager needs to defend your case
    against other promotion candidates. Evidence and documentation matter more.

The clinical AI and systems engineering space creates specific growth opportunities:

For junior and mid-level engineers:
  → Clinical domain knowledge becomes a differentiator
    Most engineers don't understand FHIR, INR monitoring, prescription workflows, MHRA compliance.
    Learning these domain concepts — not just the technology — makes you more valuable
    in this space than an engineer with the same technical skills but no domain knowledge.

  → AI integration skills are rare and growing fast
    Building production AI features (not demos) — rate limiting, output validation,
    prompt injection prevention, streaming, agent patterns — these are skills most
    engineers haven't built yet. Building them now creates early expertise.

For senior engineers and tech leads:
  → Architecture decisions in clinical AI have regulatory implications
    Understanding what CQC, MHRA, and NHS Digital require from clinical software
    is a senior-level differentiator. Very few engineers have this combined knowledge.

  → Safety-engineering mindset translates across domains
    Clinical AI forces rigorous thinking about failure modes, hallucination, output validation,
    human-in-the-loop patterns. These skills transfer to any safety-critical system.

Communicating clinical AI work on CVs and in interviews:
  Don't say: "Built an AI feature using Semantic Kernel."
  Say:       "Designed and shipped a production AI prescription copilot that reduced
              pharmacist INR lookup time by 80%. Implemented output validation to prevent
              medication hallucination, prompt injection prevention for clinical safety,
              and a human-in-the-loop approval flow for write actions."

The outcome and the safety thinking are what differentiate clinical AI work.

Clinical systems add pressure that non-clinical software doesn't:
  → The stakes feel higher — software bugs have clinical consequences
  → On-call for production incidents in a clinical environment is stressful
  → Regulatory pressure, complex integrations, and clinical stakeholder expectations
    combine into high ambient stress

Signs of approaching burnout:
  → Work that was interesting feels tedious or pointless
  → You're less patient in code reviews, meetings, and conversations
  → You're working longer hours but feeling less productive
  → Small problems feel disproportionately large
  → You're making more mistakes than usual

What to do before burnout arrives:
  → Name it. Say it to your manager: "I'm running close to empty — I need to talk
    about how to rebalance before it becomes a problem."
  → Protect non-work time actively. Clinical urgency can colonise evenings and weekends.
    Clear boundaries: on-call is for incidents, not for all-hours availability.
  → Ask what can be dropped or deferred. Burnout is often caused by accumulated
    commitments without a removal mechanism.

Career sustainability:
  A brilliant two-year career that ends in burnout is less valuable
  than a sustainable twenty-year career at a solid pace.
  Growth requires recovery. Recovery requires boundaries.
  Protect them — especially in clinical systems where the work always feels urgent.