Search

Engineering Leadership

My philosophy is about the human and organizational work of leading. This one is about the technical work of leading engineers: how technical I stay, where I engage with the code and systems, how I think about on-call, how I influence architecture, and how I keep the engineering bar high without becoming a bottleneck myself.

Everything below is the 3 A's applied to engineering. If my team doesn't have the autonomy, authority, and accountability to do the work, that's my failure, not theirs.

On this page↓
01

Technical Credibility

Here's the honest framing I hold myself to: technical enough that my engineers trust my judgment on the things I weigh in on; not so deep in the code that I do their jobs for them. I don't measure my credibility in PRs shipped. I measure it in whether my engineers feel I understand the work.

Anchoring principles

  • I don't need to be the best engineer in the room. I need to be the person who can ask the question that unsticks the room.
  • Depth beats breadth here. I pick one or two areas of the system I commit to understanding deeply, and I'm honest about the rest.
  • Decay is real. Six months out of hands-on work and my instincts start to lie to me, so I build deliberate routines to stay current.

Tactics

  • I read PRs as a learner, not a reviewer. I skim 5-10 a week from across the team — I'm absorbing patterns and naming, not gatekeeping.
  • I pair quarterly. I sit with an engineer on a real task for an hour, so I learn what the dev experience actually feels like.
  • I run the system end-to-end once a quarter: build it locally, deploy a change to staging, follow it through. The painful steps tell me what to fix.
  • I shadow on-call for a rotation each year. Not to drive, but to feel the load.
  • I attend design reviews and read the RFCs, even the ones I don't need to weigh in on.
  • I subscribe to alerts and key dashboards. I don't act on them; I just notice the rhythm of the system.
  • I keep one personal coding habit: a side project, an Advent of Code, a small internal tool. Just enough to keep the muscle alive.

What I avoid

  • Reviewing PRs to prove I still can. Engineers can tell.
  • Forming architectural opinions from skimming. If I don't have time to engage seriously, I defer with grace.
  • Hiding from a topic because it's outside my background. I'd rather ask. Engineers respect a manager who says "explain this to me" far more than one who fakes it.
02

Code Review Participation

How much should I review code? It depends, but the wrong answers are obvious to me. Reviewing nothing tells my team I've left the work behind. Reviewing everything tells them I don't trust them.

A working model

  • Default: I stay off the required reviewer list. My reviews shouldn't be load-bearing.
  • I do review: changes to things I uniquely know about (auth, infra I built, customer-facing copy), high-risk changes flagged for extra eyes, and PRs from new hires in their first month.
  • I skim, but don't block: broader patterns, naming, what people are working on. This is signal-gathering, not gatekeeping.
  • Time-bound: if my review is taking more than about 15 minutes, I'm probably the wrong reviewer.

Conventions I set

  • I distinguish blocking comments from suggestions from questions, in writing. I use prefixes like nit:, q:, blocking: if the team doesn't already have a convention.
  • I don't drop a review and disappear. If I'm going to be the bottleneck, I hand it off.
  • I praise good code in writing. Reviews are one of the few public artifacts of the work.

Anti-patterns I watch for in myself

  • Skipping the review, then second-guessing the decision in a 1:1.
  • Leaving "drive-by" stylistic comments that derail substantive review.
  • Asking for changes I'm not willing to defend on a call.
03

On-Call Philosophy

On-call is where engineering culture gets revealed to me. How my team responds to a 2 AM page tells me more than any survey could.

My role as a manager

  • I'm responsible for the load, not the rotation. If on-call is brutal, that's my problem to fix, even if I'm not on the rotation.
  • I stay on the escalation path, not the front line. My team should never have to think about whether to wake me for a serious incident.
  • I attend incident reviews. Quietly. My presence signals importance; my silence signals trust.

Questions I answer in my first 60 days

  • What's the page volume per engineer per week? I aim for fewer than 2 actionable pages per person per week, ideally lower.
  • What percentage of pages are actionable versus noise?
  • What's the trend on MTTR?
  • How is on-call compensated: money, time off, neither?
  • Who's been carrying a disproportionate load? There's always someone.
  • Is there a runbook? Does it match reality?

Investments I make

  • I reduce paging noise aggressively. Every false page erodes my team's willingness to respond to the real ones.
  • I make the on-call handoff a real ritual: a 15-minute weekly meeting, documenting what's outstanding.
  • I track on-call as work. Engineers on-call shouldn't be expected to ship features that week.
  • I run a quarterly on-call retro: what pages came up, what we fixed, what we didn't.
  • I insist on blameless postmortems, real action items, and owners. Action items without owners are just wishes.

Things I push back on

  • Heroics. When an engineer stays up all night fixing things, I see someone who needs rest and a process fix, not another bonus.
  • "We can't change the rotation right now." If the rotation is unsustainable, I make it the priority.
04

Architecture & Technical Decisions

I'm not the architect anymore. My job is to make sure good architectural decisions get made by the right people, with the right information, at the right time.

Where I engage

  • Cross-team or cross-system decisions. These need someone with organizational context, and that's often me.
  • Decisions with long reversibility horizons — picking a database, a primary language, a vendor — need rigor, and I make sure they get it.
  • Decisions affecting hiring, headcount, or roadmap, because architecture and people are coupled.

Where I stay out

  • Internal implementation choices within a team's scope.
  • Style and naming. I give my opinion in writing once, then leave it to the team.
  • Anything reversible in a week.

Rituals I establish or protect

  • An RFC / design doc process: lightweight template, async review, decision recorded. If a team doesn't have one, I set one up.
  • An architecture review forum: weekly or biweekly, optional attendance, reserved for designs that touch multiple teams or systems. I keep it small, and I kill it if it becomes theater.
  • A tech radar or "we use X for Y" document, to reduce re-litigation of solved questions.
  • A decision log for every non-trivial architectural decision: context, options, choice, who decided, and when to revisit it.

My tells that something is going wrong

  • The same architectural debate happens three times in three months.
  • A major decision gets made and I only hear about it after.
  • Engineers are afraid to push back on a senior IC's preference.
  • Designs ship without being written down.
05

Tech Debt and Migrations

I'll inherit some, I'll create some, and I'll lead at least one migration that takes longer than anyone expected.

Tech debt

  • I make it visible. Untracked debt is invisible debt is unfunded debt, so I get it into the same backlog as features.
  • I allocate explicitly. Some fraction of every cycle goes to debt, because "when we have time" means never.
  • I distinguish the kinds: deliberate-and-temporary (fine), deliberate-and-permanent (rare but real), accidental (the dangerous one).
  • Sometimes the answer is "live with it." Not all debt should be paid, and I try to be honest about which is which.

Migrations

  • I never start one without an end date and a kill criterion. "We'll migrate everything to X eventually" is how organizations end up running three databases.
  • I resource it like a project: an owner, a plan, milestones, regular check-ins.
  • I count down, not up. My dashboards show what's left, not what's done.
  • I celebrate the deletion. The win is removing the old thing, not standing up the new one.
06

Hiring Engineers

What's specifically engineering-flavored about how I hire:

  • I set the technical bar. I'm specific about it in writing, I calibrate with my team, and I don't let urgency lower it.
  • Interview design is my job. I audit the loop in my first 60 days: am I measuring what I actually care about? Does it bias against anyone I'd want?
  • I stay on the loop, even when busy. The signal I get from interviewing is irreplaceable.
  • Debrief discipline: decisions in writing, with evidence, before anyone shares their lean. Otherwise the loudest voice wins.
  • I'm honest in offers. I sell the role and the team, but not by misrepresenting them — the cost shows up in month four.
07

Working With Staff+ Engineers

The senior individual contributors on my team are my technical peers, my force multipliers, and often the hardest people for me to manage well.

What they need from me

  • Real problems. Staff engineers atrophy on small work.
  • Air cover. They'll have unpopular opinions sometimes; my job is to make sure those opinions get heard.
  • Honest feedback. They get less of it than anyone, because they're "too senior." This is wrong.
  • Visibility. They often do work that's invisible until it isn't — a migration enabled, an incident prevented. I surface it.

What I need from them

  • A clear read on the technical state of things. They see things I don't.
  • Mentorship of the rest of the team: explicit, not assumed.
  • Early signal on architectural problems. I treat their concerns as data, even when I push back.

Pitfalls I try to avoid

  • Treating them as junior managers. They're not.
  • Avoiding hard conversations because they're senior. They want them.
  • Letting them become single points of failure. I work to diversify the knowledge.
08

Engineering Quality & Culture

I don't set engineering culture by declaring it. I set it by what I reward, tolerate, and notice.

Testing. I'm explicit about what I expect: what gets tests, what doesn't, what coverage means and doesn't mean.

Documentation. I reward writing. I pair every "we should document this" with "and here's the hour to do it."

Code quality. I establish norms and let the team enforce them. I'm a tiebreaker, not a hall monitor.

Postmortems. Blameless, written down, public, action items with owners. This is the cultural artifact I protect most fiercely.

Production ownership. "You build it, you run it" is a value statement to me, not just an org structure. I make sure the team feels the consequences of what they ship.

09

The IC → Manager Identity Question

I came from engineering, and I know the grief. The work I was great at is no longer the work I do.

  • Catching myself sneaking back into the code at night because it feels like "real work."
  • Feeling like I accomplished nothing on a day full of meetings.
  • Defining my value by what I produced rather than what my team produced.

What helps

  • Redefining the unit of work. My output is my team's output. I internalize this even when it feels uncomfortable.
  • Keeping a "what I enabled" log. Friday afternoons, I write down what happened this week that wouldn't have without me. Some weeks it's short. That's fine.
  • Finding a peer group: other managers, inside or outside the company. They're the only people who understand the specific weirdness of the job.
  • Having a coach or mentor. Even informal. Even occasional.