- Published on
Engineering Leadership: Building Teams
- Authors
In Part 1 and Part 2, we covered the breadth of engineering leadership and the decision-making muscle that runs through it. This third part zooms in on what may be the highest-leverage activity in the role: building the team itself. Hiring well, onboarding well, and growing people deliberately compounds over years. Hiring poorly compounds in the other direction.
Engineering leaders rarely get explicit training in this. Most learn on the job, often by being burned a few times. The principles below are practitioner-tested and meant to give a faster path through that learning curve.
Table of Contents
- Hiring with Signal
- Onboarding Well
- Mentorship and Growth
- Common Pitfalls
- Conclusion
- Appendix: Recommended Resources
Hiring with Signal
Hiring is where engineering leaders make some of the most consequential and irreversible decisions of their tenure. Every hire shapes the team's culture, code, and capacity for years afterward. The aim of a good loop is not to find the "best" candidate in some abstract sense, but to gather enough signal across the dimensions that matter for this team and this role.
Designing the Loop
A hiring loop is a sequence of interviews that, taken together, should produce a confident yes/no decision. Each stage should test something distinct; duplicating signal across stages wastes everyone's time and exhausts candidates without adding information.
A typical engineering loop has four to five stages:
| Stage | What It Tests | Common Format |
|---|---|---|
| Recruiter Screen | Communication, motivation, basic role fit | 30-min phone call |
| Hiring Manager Screen | Career trajectory, level alignment, values fit | 30-45 min video call |
| Technical Coding | Practical problem-solving, code quality | 60-90 min, paired or take-home |
| System Design (mid-plus) | Architectural thinking, trade-offs | 60 min whiteboard or doc-based discussion |
| Behavioral / Team Fit | Collaboration, handling conflict, growth mindset | 45-60 min, often with cross-team peers |
Examples:
- A Tech Lead hiring for their team builds a 90-minute paired-coding interview around a realistic codebase, not a leetcode puzzle, because the work the candidate will actually do is 90% pattern-matching against existing code.
- An Engineering Manager explicitly drops the system design stage for junior roles because it produces more noise than signal at that level, and replaces it with a longer behavioral interview focused on learning velocity.
Treat your interview process like production code. Measure it, refactor it, version it. Most companies hire candidates through interview loops that have not been intentionally designed in years. - Will Larson, Author of An Elegant Puzzle
Signal vs Noise
Not every interview signal is reliable. Some classic signals are well-correlated with on-the-job performance; others have been studied to death and shown to be near-useless. The single biggest improvement most teams can make is to replace impressionistic "did I like them?" feedback with structured rubrics that interviewers fill in before they discuss the candidate with each other.
Approximate Predictive Value of Common Interview Techniques
Reliable signals tend to be:
- Working through a realistic problem with the candidate (paired coding on representative work).
- Structured behavioral questions tied to specific past situations the candidate actually owned.
- Take-home or work-sample exercises (when scoped fairly and time-bounded).
- Reference conversations with people who actually managed the candidate, not generic referees.
Lower-signal-but-popular techniques tend to be:
- Trick coding puzzles unrelated to the actual work.
- Vague "culture fit" questions without a defined cultural rubric.
- Brain teasers and abstract IQ proxies.
- Single-interviewer impressions captured without a structured rubric.
Unstructured interviews are the equivalent of judging a book by how it smells. Structured interviews are how you actually predict whether someone can do the job. - summary of decades of meta-analyses on interviewing
Leveling and Calibration
Engineering leaders are also responsible for placing each hire at the correct level. Get it wrong on the high side and the new hire underperforms expectations and becomes a performance management problem. Get it wrong on the low side and they leave within a year, having outgrown the role on contact.
Examples:
- An Engineering Manager runs a calibration meeting after every hiring loop where the panel argues for a specific level (Senior, Staff, Principal) using concrete evidence from the interviews, not titles from the candidate's prior company.
- A VP of Engineering publishes an internal leveling rubric that defines what "scope," "complexity," and "leadership" mean at each level, so loop debriefs are anchored on shared definitions rather than feelings.
Levels are not titles. They are contracts about scope, autonomy, and impact. Get the contract right at hire time and you save yourself a year of misalignment. - Camille Fournier's writing on the subject
Onboarding Well
Hiring is only half the equation. A great hire who is poorly onboarded can take six to nine months to reach full productivity, instead of two to three. Worse, the early experience shapes how engaged a new hire feels for the rest of their tenure.
The First 30, 60, and 90 Days
A useful structure for new-hire onboarding is the 30/60/90 day plan: a written, shared document that defines what good looks like at each milestone. It gives the new hire a clear target, the manager a calibration tool, and the team a shared definition of "ramped up."
| Window | Goal | Typical Activities |
|---|---|---|
| First 30 Days | Learn the lay of the land | Environment setup, complete a small starter task, meet stakeholders, read the most important docs |
| 30-60 Days | Contribute on real work with support | Own a meaningful feature or improvement end-to-end with code review and pairing |
| 60-90 Days | Operate independently on common cases | Take on-call shifts, lead a small project, give early feedback on team practices |
| 90+ Days | Begin to influence team direction | Propose improvements, mentor newer hires, contribute to roadmap discussions |
Examples:
- A Team Lead writes a fresh 30/60/90 plan with each new hire in week one, customising it to the hire's level and the team's current priorities, rather than reusing a generic template.
- An Engineering Manager schedules weekly 1:1s with a new hire for the first three months specifically to surface blockers early, then drops to fortnightly once the hire is fully ramped.
Buddies and Mentors
Two roles consistently make a difference for new hires:
- Onboarding Buddy: A peer who answers small questions in real time so the new hire is not blocked or embarrassed asking the manager every five minutes. The buddy relationship typically lasts the first month.
- Mentor: A more senior engineer who provides longer-term coaching on technical depth, navigating the organisation, and growing into the next level. The mentor relationship is intentional and should outlast the buddy relationship by months or years.
The two roles serve different needs and should usually be different people. Conflating them tends to overload the buddy and underdeliver on real mentorship.
The most underrated lever an engineering leader has is the quality of the first month. Get that month right and you compound for years. Get it wrong and you spend a year rebuilding trust. - Camille Fournier, Author of The Manager's Path
Mentorship and Growth
Once a team is past initial ramp-up, the question shifts from "are they productive?" to "are they growing?" Engineers who are growing tend to stay. Engineers who are stagnating tend to leave, often without warning. Mentorship and growth planning are how engineering leaders create deliberate growth, rather than hoping it happens.
From Performer to Mentor
A common pattern in engineering organisations is that strong individual performers are asked to mentor others without much guidance on how to do it. Mentoring is a different skill from performing, and it has to be learned.
Practical mentorship habits that work:
- Ask, do not tell. Help the mentee reason their way to the answer. Telling them the answer feels efficient but builds dependence rather than independence.
- Pair on real work, not contrived exercises. Real codebases teach more than tutorials.
- Give feedback close to the moment. Saved-up feedback is harder to act on and feels heavier than feedback in the moment.
- Be explicit about what you are coaching. "I am going to push you on how you scope this design" is much clearer than vague "let's chat about your project."
Examples:
- A Senior Engineer taking on their first mentee blocks two 30-minute slots per week explicitly for coaching, separate from their normal collaboration time, so mentorship does not get crowded out by deadlines.
- A Tech Lead rotates which junior engineer leads the team's design reviews each month, then debriefs with that person privately afterwards on what went well and what to try differently next time.
Teaching forces clarity. The best way to deepen your own understanding is to explain something to someone earlier in their journey. - Feynman technique
Growth Plans That Stick
A growth plan is a written agreement between an engineer and their manager about what the engineer is working toward over the next 6-12 months. The "stick" part comes from making it concrete, dated, and revisited on a regular cadence rather than written once and forgotten in a shared drive.
A useful growth-plan template:
| Section | Purpose |
|---|---|
| Current Level and Strengths | Anchor the plan in an honest baseline |
| Target Level or Role (12 mo) | A specific destination, not a vague aspiration |
| Skills to Develop | Two or three concrete capability areas |
| Specific Opportunities | Projects, mentorships, or stretch assignments mapped to those skills |
| Evidence of Growth | What success will look like, observable from the outside |
| Check-in Cadence | When this plan will be revisited (usually monthly or quarterly) |
Examples:
- An Engineering Manager uses a quarterly growth-plan review to recalibrate against the engineer's actual work, dropping items that no longer fit and adding new opportunities that have emerged.
- A Tech Lead explicitly maps the next promotion criteria onto the growth plan, so the engineer knows what evidence they will need to make the case for promotion and is not guessing.
Career conversations are not annual events. They are ongoing. Annual reviews are where you confirm what should already be obvious, not where you deliver surprises. - Russ Laraway, Author of When They Win, You Win
Common Pitfalls
Even experienced leaders fall into team-building traps. Awareness is the first step toward avoiding them.
| Pitfall | Description | How to Avoid |
|---|---|---|
| Hiring Clones | Pattern-matching on yourself or the existing team's profile, narrowing the team's range over time | Define the gaps you are hiring against, not the qualities you already have |
| Lowering the Bar | Backfilling roles fast at the cost of long-term quality | Keep the bar; raise headcount visibility with leadership instead |
| Onboarding by Osmosis | Assuming new hires will pick things up by being in the room | Write the 30/60/90 down; assign buddies and mentors explicitly |
| Mentor as Project Manager | Treating mentorship time as another channel to push project work through | Reserve protected mentorship slots; track conversations, not just deliverables |
| Growth Plans on a Shelf | Writing the plan once and never revisiting it | Build the review cadence into 1:1s; tie growth conversations to real work |
| Promotion Surprises | Engineers learning at promotion time that they were misjudging their level | Make level expectations transparent; calibrate as a leadership group |
| Letting Stars Go Quietly | Top performers leaving because no one asked what would keep them | Stay-interview your strongest people every 6-12 months, not just exiting ones |
Conclusion
Building a team is the slowest, highest-compounding investment an engineering leader makes. The decisions you make about hiring, onboarding, and growth shape what your team is capable of one, three, and five years from now.
The key takeaways:
- Hire for signal, not impressions. Design the loop deliberately and revisit it every year.
- Onboard intentionally with a written plan, a buddy, and a mentor. The first month sets the trajectory.
- Grow people on purpose with mentorship time and concrete growth plans. Hope is not a strategy.
- Avoid the well-known pitfalls - clones, lowered bars, shelved growth plans, and promotion surprises - because they tend to be invisible until it is too late.
In the next and final post of this series, we will turn outward to Stakeholder Management and Influence: how engineering leaders communicate engineering work to non-technical audiences, defend technical debt, navigate roadmap politics, and influence outcomes far beyond the formal authority of the role.
Appendix: Recommended Resources
- Books:
- The Manager's Path by Camille Fournier - The clearest guide to growing into engineering leadership, with strong chapters on hiring and onboarding.
- An Elegant Puzzle: Systems of Engineering Management by Will Larson - Practical systems thinking for managing teams at scale.
- Who: The A Method for Hiring by Geoff Smart and Randy Street - A structured hiring process that has held up well across industries.
- When They Win, You Win by Russ Laraway - Career conversations and growth planning at depth.
- Articles:
- "Validity and Utility of Selection Methods" by Schmidt and Hunter - The classic meta-analysis on what actually predicts job performance in interviews.
- "Onboarding Engineers" by Will Larson - Practical patterns for the first 90 days.
- "A Senior Engineer's Checklist" by Lijo Vinod - Useful as a calibration anchor when leveling.
- Videos:
- How to Hire Software Engineers - Practitioner talks from companies known for thoughtful hiring loops.
- Russ Laraway on Career Conversations - The career conversation framework explained on stage.