Building High-Performing Engineering Teams: Early Thoughts
Initial thoughts on what makes engineering teams successful, based on recent experiences
Created Jan 1, 2024 - Last updated: Jan 10, 2024
Building High-Performing Engineering Teams: Early Thoughts
Note: These are early thoughts I’m developing based on recent experiences leading engineering teams. This is very much a work in progress.
I’ve been thinking a lot about what separates high-performing engineering teams from average ones. It’s not just about technical skills - there are other factors that seem to matter more.
What I’ve Observed So Far
1. Psychological Safety is Everything
Teams that ship fast and with quality seem to have one thing in common: developers feel safe to admit mistakes and ask questions.
In my recent experience with a team that was struggling:
- Developers would hide bugs until the last minute
- Code reviews were defensive rather than collaborative
- Innovation was low because people were afraid to try new things
After focusing on psychological safety:
- Bug reports increased 3x (which was actually good!)
- Code review discussions became more productive
- Team started proposing architectural improvements
2. Clear Context > Detailed Instructions
I used to think good leadership meant giving detailed instructions. I was wrong.
What doesn’t work:
- “Implement feature X using technology Y following these 15 steps”
What works better:
- “Users are struggling with workflow Z, impacting our retention metric. Here’s what we’ve tried before and what we learned.”
The team comes up with better solutions when they understand the why.
3. Metrics Should Be Visible, Not Punitive
We started showing team metrics (deployment frequency, lead time, etc.) on a dashboard. Initial fear was that it would create pressure.
Opposite happened:
- Team started suggesting process improvements
- Deployment frequency increased 40%
- Fewer firefighting, more planned work
Key insight: When people understand the game, they play better.
Questions I’m Still Exploring
How do you scale culture?
- Works great with 5-8 engineers
- What about 20? 50?
- How do you maintain consistency across multiple teams?
Technical vs. People Skills for Engineering Managers
- How much coding should an EM do?
- When do you transition from IC to pure management?
- How do you maintain technical credibility?
Remote vs. In-Person Team Dynamics
- Some collaboration feels different on video calls
- How do you build trust remotely?
- Are there types of projects that work better in person?
Initial Hypotheses to Test
- Pair Programming might be more valuable for knowledge transfer than code quality
- Async communication could be better for complex technical decisions
- Rotating project ownership might prevent knowledge silos
- Regular architecture reviews could improve code quality more than stricter linting
Next Steps for Research
I want to dive deeper into:
- Team topologies and Conway’s Law
- Measuring developer experience quantitatively
- Effective techniques for technical mentoring
- How to structure career growth for senior engineers
Reading List
Currently exploring:
- “The Manager’s Path” by Camille Fournier
- “Accelerate” by Nicole Forsgren
- “Team Topologies” by Matthew Skelton
- Various engineering leadership blogs and podcasts
These are very early thoughts that I’m sure will evolve significantly. If you have experience with engineering leadership, I’d love to hear your perspective. What patterns have you seen work well?
Connect with me on LinkedIn or Twitter to continue the conversation.