What a Principal Engineer Actually Does

⏱ ~8 min read · 🎧 6 min listen · ✎ 3 quizzes · 🧪 ~30 min lab

Here's the uncomfortable truth this whole course is built on: the thing that made you a great Senior Engineer is not the thing that makes a Principal Engineer. You got here by taking a well-defined problem and solving it excellently. The next level is graded on something else entirely — and if you keep doing more of what got you promoted last time, you'll plateau doing it.¹ So before any architecture or strategy, this lesson answers one question precisely: what is the actual job?

The delta: three things change

Tanya Reilly — a Senior Principal Engineer, and author of the best field manual for this level¹ — organizes the staff+ job into three pillars. Read them as the delta from your current job:

Reilly's three pillars name the work itself: big-picture thinking (seeing beyond your team's horizon — technical vision and strategy), execution (making ambiguous, cross-team projects actually finish), and leveling up (raising the standard of everyone around you — through reviews, teaching, and being the engineer others calibrate against).¹ Notice what's not on the list: writing the most code. You'll still code — but code stops being your primary output. Your output becomes decisions, documents, and direction. That's why so many labs in this course produce a written artifact, not a program.

The four archetypes — which shape is the job?

"Principal Engineer" is not one job. Will Larson, after interviewing dozens of staff+ engineers, found the role clusters into four archetypes² — and companies usually hire or promote for one specific shape, whether they say so or not:

Why this matters now, for you specifically: it sharpens both of your paths. For the internal promotion, ask "which archetype is my org actually missing?" — that gap is your promotion case. For external interviews, job ads that all say "Principal Engineer" are describing different archetypes; recognizing which one saves you from interviewing for the wrong job. Most Principal openings at product companies are Tech Lead or Architect shaped.²

The trap on the way up: invisible glue

One more idea completes the picture, and it's the most-shared career essay in engineering for a reason. Reilly calls it glue work: noticing what's falling between the cracks, unblocking others, improving processes, doing the coordination that makes the project succeed.³ At Principal level, glue work is the job — expected and rewarded. But on the way to Principal, glue work done invisibly can sink you: your promotion packet shows less shipped code and no named wins. The move is to do the glue work visibly and narratably — attach your name to the outcome, write the doc, send the summary. That habit starts this week, not after the title.

🧪 Lab: map your current scope

This course's labs produce artifacts — every one becomes promotion evidence or an interview story. The first artifact is a half-page scope map. Open a doc and write, honestly:

1. Three problems you currently touch — and for each, whether it's team-scoped or crosses teams.
2. One org-level problem nobody owns — something falling between teams that you could credibly pick up. (This is promotion-case raw material.)
3. Your archetype fit — which of the four shapes matches what you already do, and which one your org is missing.
4. Your invisible glue — one piece of glue work you did last month that nobody saw. How would you have made it visible?

Feedback loop: bring it back to me in chat. I'll review it against a Principal-level rubric — is the org problem genuinely org-level, is the archetype claim backed by evidence, is the glue story narratable in an interview. Keep the doc; Lesson 12 assembles these artifacts into your promotion packet.

You are a seasoned Principal Engineer reviewing my work: a half-page scope map listing three problems I currently touch, one unowned org-level problem, my archetype fit, and one piece of invisible glue work.

Grade each criterion as Strong / Adequate / Missing, with one sentence of evidence:
- The org-level problem is genuinely org-level: it falls between teams and has no owner — not just a large task inside my team.
- The archetype claim (Tech Lead / Architect / Solver / Right Hand) is backed by evidence of what I already do, not aspiration.
- The glue-work story is narratable in an interview: a concrete outcome I could visibly attach my name to.
- Each of the three current problems is honestly labelled team-scoped vs cross-team.

Be skeptical — challenge my weakest claim first. Then ask me 2–3 follow-up questions a promotion committee would ask. Finish with the single highest-leverage improvement.

My scope map follows below.

Check yourself — diagnose the level

Scenarios, like always. Diagnose from the mental model — don't scroll up. Wrong picks stay live.