🎬 The Identity Crisis
You got promoted to Principal Engineer. Congratulations! 🎉
It's been 3 months. You've attended 47 meetings. You've written 3 Architecture Decision Records that nobody read. You haven't committed code in 2 weeks and you feel profoundly useless.
A junior engineer asks you for help with a Terraform module. You pair with them for 2 hours, fix the issue in 10 minutes, and spend 110 minutes explaining WHY the fix works, what patterns to use, and how to avoid the problem in the future.
You think: "I could have fixed that in 10 minutes myself."
But here's the thing — that junior engineer will never make that mistake again. And they'll teach the next person. And the next. Your 2-hour investment just saved the team 200 hours over the next year.
Welcome to being a multiplier. It feels weird. It's supposed to.
🧠 The Mindset Shift: Senior → Principal
This is the hardest part. Nobody prepares you for it.
Senior Engineer Principal Engineer
═══════════════ ═══════════════════
Question: "What's the best "What's the right
solution?" solution for the ORG?"
Impact: What YOU build What OTHERS build
because of your guidance
Code: Write a lot Write strategically
(prototypes, critical fixes)
Scope: Your team's project Multiple teams,
department, company
Time horizon: This sprint, quarter This year, next year
Meetings: "Ugh, another one" "This IS the work"
Success: "I shipped it!" "The team shipped it,
and they didn't need me"
The Hardest Truth
Your value is no longer measured by the code you write.
It's measured by:
- Decisions you make that save the org months of wasted effort
- Engineers you mentor who grow into the next generation of leaders
- Technical debt you prevent before it's created
- Systems you design that scale without constant firefighting
- Alignment you create between engineering and business goals
If that makes you uncomfortable, you're in the right place. Let's work through it.
📊 How to Spend Your Time (The Reality Check)
If you're writing code 60%+ of your time, you're doing
a senior engineer's job with a principal title.
Healthy time allocation for a Principal:
30% │████████████████████│ Architecture & Strategy
│ │ ADRs, tech strategy, research,
│ │ roadmapping, system design
│ │
25% │█████████████████│ Collaboration & Influence
│ │ Design reviews, cross-team
│ │ alignment, stakeholder mgmt
│ │
20% │█████████████│ Mentoring & Teaching
│ │ 1:1s, pair programming,
│ │ tech talks, documentation
│ │
15% │██████████│ Hands-On Technical Work
│ │ Prototypes, POCs, critical
│ │ fixes, proof of concepts
│ │
10% │██████│ Learning & Community
│ │ Industry trends, conferences,
│ │ writing (like this blog!)
Warning Signs You're Not Operating at Principal Level
🚩 You're the only person who can deploy to production
🚩 You fix bugs instead of teaching others to fix them
🚩 You don't have time for strategy because you're always coding
🚩 Other teams don't know who you are
🚩 You can't explain what you did last quarter without listing PRs
🚩 You haven't written a document that influenced a decision
🚩 Nobody has mentioned learning something from you recently
📝 Architecture Decision Records: Your Decision Paper Trail
ADRs are how Principal engineers make their impact visible and lasting. When you make a technical decision that affects the organization, write it down.
Why ADRs Matter
Without ADRs:
2026: "Let's use Kafka for event streaming!" (decision made in meeting)
2027: Half the team left. New engineers join.
2027: "Why are we using Kafka? Can we switch to Azure Event Hubs?"
2027: 3 months debating the same decision again
2027: "Wait, we tried that before and it didn't work because..."
2027: Nobody remembers why
With ADRs:
2026: ADR-042: Event Streaming Platform Selection
2027: New engineer asks "Why Kafka?"
2027: Reads ADR-042 in 5 minutes
2027: "Oh, we evaluated Event Hubs but it didn't support
schema registry at the time. That's changed now.
Maybe we should revisit." (Productive conversation!)
ADR Template That Actually Gets Used
# ADR-042: Event Streaming Platform Selection
## Status: Accepted (2026-01-15)
## Context
We need an event streaming platform for our microservices
architecture. Currently, services communicate via synchronous
HTTP calls, causing cascading failures and tight coupling.
## Decision Drivers
- Team has 2 engineers with Kafka experience
- Must support schema evolution (backward compatible)
- Need at least 100K events/second throughput
- Budget: $2,000/month maximum
## Options Considered
| Criteria | Kafka (Confluent) | Azure Event Hubs | Azure Service Bus |
|----------------|-------------------|-------------------|-------------------|
| Throughput | ★★★★★ | ★★★★ | ★★★ |
| Schema support | ★★★★★ (Registry) | ★★★ (basic) | ★★ |
| Team expertise | ★★★★ | ★★ | ★★★ |
| Cost | ~$1,800/mo | ~$1,200/mo | ~$800/mo |
| Ops overhead | ★★ (self-managed) | ★★★★ (managed) | ★★★★★ (managed) |
## Decision
Use Azure Event Hubs with Schema Registry.
## Rationale
- Kafka expertise exists but managing Kafka clusters is expensive
in engineer time (estimated 20% of one engineer)
- Event Hubs is Kafka-compatible (apps use Kafka client libraries)
- Schema Registry is now available in Event Hubs
- Managed service reduces operational burden
- Fits within budget
## Consequences
- Teams must use Kafka client libraries (not Event Hubs SDK)
to maintain portability
- Schema Registry enforces backward compatibility
- We accept Event Hubs' partition limit (100 vs Kafka unlimited)
## Review Date: 2026-07-15 (6 months)
Decision Types: Know Which Ones Need ADRs
Type 1: One-Way Door (Irreversible)
"Which cloud provider?"
"What's our platform technology?"
→ Broad consensus required. ADR mandatory. Exec approval.
→ Take your time. Get it right.
Type 2: Two-Way Door (Reversible)
"Which monitoring tool?"
"Terraform vs Pulumi?"
→ Principal decides with team input. ADR recommended.
→ Don't over-deliberate. You can change it later.
Type 3: Team-Level (Delegate)
"Which testing framework?"
"How to structure this service internally?"
→ Team decides. Principal advises only if asked.
→ Don't micromanage. Trust your people.
The Principal skill: knowing which type each decision is.
Common mistake: Treating Type 2 as Type 1 (over-thinking)
or Type 1 as Type 2 (under-thinking)
👥 Mentoring: The Highest Leverage Activity
The Mentoring Spectrum
Teaching Mentoring Sponsoring
═════════ ═════════ ══════════
"Here's how to do X" "What do you think "I recommend Alex
about X?" for this project"
One-time knowledge Ongoing relationship Using YOUR influence
transfer Growth over months to advance THEIR career
Low leverage Medium leverage Highest leverage
(helps one person) (grows an engineer) (creates new leaders)
How to Mentor Effectively (Without Being a Bottleneck)
❌ Bad mentoring:
Junior: "How should I implement this?"
You: "Use pattern X with library Y. Here's the code."
Result: Junior learns nothing, keeps asking you.
✅ Good mentoring:
Junior: "How should I implement this?"
You: "What options have you considered?"
Junior: "I was thinking about pattern X or pattern Z."
You: "What are the tradeoffs between them?"
Junior: "X is simpler but Z scales better..."
You: "And which matters more for this use case?"
Junior: "...simpler, because we only have 100 users."
You: "Great thinking. Go with X. If we scale beyond 10K
users, we can revisit. Write it up in a mini-ADR
so the team knows why."
Result: Junior learned to think. Won't need to ask next time.
The 30-Minute 1:1 Template
First 10 minutes: THEIR agenda
→ "What's on your mind?"
→ "What's blocking you?"
→ "What are you struggling with?"
Next 10 minutes: Growth
→ "What did you learn this week?"
→ "What would you like to get better at?"
→ "Here's a stretch opportunity I think you'd be great for..."
Last 10 minutes: Feedback (both directions!)
→ "Here's something you did really well..."
→ "Here's something to think about..."
→ "Is there anything I could do differently to help you?"
🤝 Stakeholder Management: Speaking Business
The Communication Translation Table
To Engineers:
"We need to migrate from VMs to Kubernetes for better
resource utilization, automated scaling, and to enable
GitOps-based deployment workflows."
To Engineering Manager:
"Migrating to Kubernetes will reduce our deployment time
from 2 hours to 15 minutes, and reduce infrastructure
costs by 30% while improving reliability."
To VP of Engineering:
"The platform migration will reduce time-to-market for
new features by 40% and save $180K annually on
infrastructure, with a 3-month break-even point."
To CTO:
"This enables us to ship features 3x faster than
competitors while reducing operational risk."
Same project. Different audiences. Different language.
🚨 Real-World Disaster: The RFC Nobody Read
What Happened: A Principal Engineer wrote a 42-page RFC (Request for Comments) for a major platform migration. It was technically brilliant. It covered every edge case, every migration step, every rollback plan.
Nobody read it. Not the VP. Not the other teams. Not even the author's own team (they skimmed the intro).
Result: The migration was approved based on a 5-minute conversation in a meeting, without the nuance of the RFC. Key assumptions were missed. Migration hit problems that were addressed in section 7.3 of the RFC that nobody read.
The Fix: TL;DR First, Detail Below
# RFC: Platform Migration to Kubernetes
## TL;DR (Read this. It's 30 seconds.)
We're moving from VMs to AKS. It saves $180K/year, cuts deploy
time by 85%, and takes 3 months. Risk is medium — mitigated by
a parallel-run strategy. I need approval by March 15.
## One-Page Summary (Read this if you're a decision-maker)
[1-page executive summary with key points and ask]
## Detailed Proposal (Read this if you're implementing)
[The full 42 pages for people who need the detail]
🛣️ Building a Technical Roadmap
The Vision Statement
Every roadmap starts with where you're going:
Vision: "Enable any team to deploy a production-ready service
in under 1 hour with enterprise-grade reliability."
That's the North Star. Every quarter maps toward it:
Q1: Foundation
├── AKS cluster standardization (2 clusters → 1 standard)
├── Pipeline template library v1 (golden paths)
└── SLO framework for tier-1 services
Q2: Developer Experience
├── Self-service namespace creation (< 5 min)
├── Standardized observability stack (auto-instrumented)
└── Cost dashboard per team
Q3: Maturity
├── Canary deployments by default
├── Chaos engineering program (game days)
└── Internal Developer Platform v1
Q4: Excellence
├── Multi-region capability
├── Platform API for self-service
└── DORA metrics: Elite level
How to Get Buy-In for Your Roadmap
Step 1: Start with PAIN, not technology
❌ "We should adopt Kubernetes because it's industry standard"
✅ "Teams wait 3 days for infrastructure. Let's fix that."
Step 2: Quantify the business impact
❌ "This will improve our architecture"
✅ "This will save $180K/year and cut delivery time by 40%"
Step 3: Show quick wins AND long-term vision
❌ "In 18 months, we'll have an amazing platform"
✅ "In 2 weeks, we'll have templated pipelines. In 3 months,
self-service deployments. In 12 months, the full platform."
Step 4: Address risks honestly
❌ "There's no risk" (nobody believes this)
✅ "Risk: team needs 4 weeks of K8s training.
Mitigation: phased rollout, starting with non-critical services."
⚖️ Navigating Technical Debt
The Technical Debt Quadrant
Deliberate
┌───────────────────────────┐
│ │
│ "We'll ship now and │
Prudent ──▶│ refactor later" │◀── This is OK
│ (Known risk, tracked) │ (if you actually do it)
│ │
├───────────────────────────┤
│ │
Reckless ────▶ │ "We don't have time │◀── This is dangerous
│ for design" │
│ (Shortcuts, no plan) │
│ │
└───────────────────────────┘
Inadvertent
┌───────────────────────────┐
│ │
Prudent ──▶│ "Now we know how we │◀── This is learning
│ should have done it" │ (natural, improve it)
│ │
├───────────────────────────┤
│ │
Reckless ────▶ │ "What's layered │◀── This is a skills gap
│ architecture?" │ (training needed)
│ │
└───────────────────────────┘
How to Sell Technical Debt Reduction
Never say: "We need to refactor the codebase."
(Leadership hears: "Engineers want to play with code instead of building features.")
Instead, say: "Our deployment failure rate is 30% because of the legacy pipeline. Investing 2 sprints to modernize it will drop failures to 5% and save 4 engineer-hours per week in debugging."
The formula that works:
"[Business metric] is impacted because of [technical debt].
Investing [effort] will improve [metric] by [amount],
resulting in [business outcome]."
🎯 Key Takeaways
- Your impact is measured by what others accomplish because of your work
- ADRs are your legacy — they outlast code and save the org from repeating debates
- Mentor by asking questions, not giving answers
- Translate tech to business language — same project, different story for each audience
- TL;DR everything — if it's longer than 1 page, add a summary at the top
- Sell debt reduction with metrics, not technical arguments
- The best code you write is the code that enables 10 others to write better code
🔥 Homework
- Write one ADR for a decision you made recently. Share it with your team.
- In your next 1:1 with a junior, ask 5 questions before giving a single answer.
- Identify one technical debt item. Write a 3-sentence business case for fixing it.
Next up in the series: **Distributed Systems: Where Physics, Murphy's Law, and Your Career Collide* — where we decode CAP theorem, resilience patterns, and the system design thinking that separates staff engineers from everyone else.*
💬 What was the hardest part of transitioning from IC to lead/principal? Was it letting go of the keyboard? The meetings? The imposter syndrome? Share below — we've all been there. 🫂
Top comments (0)