How I build great engineering teams
This document captures how I think about engineering management—not as a set of rigid rules, but as a living philosophy built on clarity, trust, and continuous improvement.
Core Principles
These are non-negotiable. Every decision I make, process I design, and conversation I have flows from these foundations.
Outcomes over outputs
Shipped code is not success. Customer impact is. I push teams to define what "done" looks like in terms of user behavior and business metrics before writing a single line.
Context, not control
My job is to give engineers the context to make good decisions independently—not to be in every decision loop. I optimize for team autonomy, not personal oversight.
Psychological safety first
Teams that can't say "I don't know" or "this is broken" can't improve. I actively create space for honest failure—and protect the people who surface problems early.
Slow down to speed up
Sustainable pace beats heroics. I invest in engineering foundations, documentation, and clear processes because they compound over time. Technical debt is a leadership failure.
Career growth is non-optional
Every engineer on my team has a clear, documented growth path reviewed quarterly. My success is measured by how many people grow under my leadership—not by features shipped.
Bias toward asynchronous
Synchronous time is expensive. I default to written communication for decisions and context-sharing—preserving live time for nuanced conversations that benefit from real-time dialogue.
My Management Style
“Management is not about being the smartest person in the room. It's about building the room where smart people can do their best work.”
Personal CredoAsk before telling
I ask questions before offering solutions. "What have you tried?" develops engineers faster than "here's what you should do."
Default to open
Strategy, roadmap rationale, compensation bands, and team performance data are shared openly unless there's a compelling reason not to.
Commitments are kept
I hold myself to the same standard I hold the team. If I miss a commitment, I name it clearly and course-correct in public.
Meeting Cadence
Every recurring meeting has a clear purpose, owner, and documented outcome. Meetings without agendas get cancelled.
| Meeting | Frequency | Duration | Purpose | Owner |
|---|---|---|---|---|
| 1:1 | Weekly | 45 min | Coaching, growth, blockers, trust-building | IC |
| Team standup | 3×/week | 15 min | Coordination, blocker surfacing, async by default | Rotating |
| Sprint planning | Bi-weekly | 90 min | Capacity, commitments, risk identification | EM + PM |
| Sprint retro | Bi-weekly | 60 min | Process improvement, team health, celebrate wins | EM |
| Design review | As needed | 60 min | Technical decisions, architecture alignment | Lead eng. |
| Team all-hands | Monthly | 60 min | Strategy, roadmap, wins, open Q&A | EM |
| Career conversation | Quarterly | 60 min | Growth trajectory, skills gaps, promo readiness | EM |
| Skip-level | Quarterly | 30 min | Unfiltered signal, trust-building above | EM's manager |
1:1 Frameworks
The 1:1 is the most important meeting I have. It belongs to the engineer, not to me. I come prepared; they set the agenda.
Before every 1:1
What's one thing I can unblock for this person? What signals have I noticed? What's their energy level? Have they grown since our last career conversation?
Shared doc template
What went well? What's stuck? What do you want to talk about? What feedback do you have for me? What's one thing that would make your work better?
First 1:1 checklist (new team member)
- Share my working style doc and ask them to annotate before we meet
- Establish communication preferences and calendar blocking norms
- Understand their career goals and what success looks like in 6 months
- Agree on format, frequency, and agenda ownership for future 1:1s
- Ask what made their last role great—and what made it hard
- Share one thing I'm actively working on improving as a manager
Decision Making
Clear decision ownership prevents the most common team dysfunction: decisions that get relitigated because nobody knew who owned them.
| Decision type | Owner | EM role | Example |
|---|---|---|---|
| Technical implementation | Lead engineer | Available, not approving | Library choice, code structure |
| Architecture | EM + Tech lead | Ensures alignment, documents outcome | New service boundary, data model |
| Scope trade-offs | EM + PM | Represents engineering capacity/risk | Cutting scope for a launch deadline |
| Hiring | EM (debrief consensus) | Breaks ties, owns final call | Extend offer vs. pass |
| Team process | Team (retro-driven) | Facilitates, implements changes | Standup format, PR review SLA |
| Compensation / promo | EM + HR | Primary advocate and owner | Promotion packet, comp adjustment |
Hiring Pipeline
Signal over credential
Demonstrated curiosity, clear thinking, ownership mindset, and productive disagreement. Degrees and company names are noise.
Written before verbal
Every interviewer writes their assessment independently before the debrief call. This kills anchoring bias and ensures every signal gets surfaced.
Candidates evaluate us
I give every candidate unscripted time with the team—no EM in the room. They should be evaluating us as hard as we evaluate them.
Career Growth
I use a three-horizon model for growth conversations. The near-term is concrete, the mid-term is directional, and the long-term is aspirational.
Current quarter
2–3 specific, measurable skills to develop. Tied to real projects. Observable by the team, not just me.
Next 6–12 months
The scope expansion that closes the gap to the next level. What would a promotion packet need to demonstrate?
3–5 year direction
Manager track, staff IC, technical specialist, founder? This shapes which opportunities I help them pursue today.
“My job is not to be the ceiling for anyone's career. It's to be a launchpad.”
On retention vs. growthFeedback Culture
SBI model
Situation — what happened. Behavior — what I observed. Impact — what the effect was. I never skip steps. I always ask 'what are your thoughts?' after.
Listen, then ask
I don't defend, explain, or apologize in the moment. I listen, take notes, ask one clarifying question, and thank them. Processing happens offline.
Feedback culture health checklist
- Engineers give each other feedback in code review without tagging me
- Retros surface systemic problems, not just one-off complaints
- People tell me when I'm wrong—publicly, not just in private
- Anonymous feedback channels exist and get used
- Nobody is surprised by their performance review
Team Health
I track four dimensions of team health and review them every sprint retro. Red on any metric triggers an immediate focus change.
Delivery
- —Sprint commitment hit rate ≥ 80%
- —P0 incident rate < 1/month
- —Cycle time trending down or stable
- —DORA metrics tracked weekly
Engagement
- —eNPS ≥ +20 on monthly pulse
- —Voluntary attrition < 15% annually
- —1:1 agenda ownership by IC
- —Retro participation ≥ 90%
Quality
- —Test coverage ≥ 80% on critical paths
- —PR review time < 24 hours
- —Tech debt allocated sprint capacity
- —Regressions per release declining
Growth
- —Every IC has a documented growth plan
- —Internal promotions ≥ external hires
- —Stretch project assigned per engineer
- —Knowledge sharing: 1 talk/month/team
Incident Response
One incident commander
Clear command structure. One person owns comms, one person owns technical resolution. I handle stakeholders so engineers can focus on fixing.
Blameless postmortem
Published within 48 hours. Timeline, impact, root cause, and action items with owners and due dates. "Who caused this" is never a useful question.
System fixes, not people fixes
If the same class of incident recurs, we didn't fix the system. Action items get tracked in the sprint board—not in a separate graveyard.