- Engineering Management Handbook
- 👩💻 About Me
- 🗺️ Legend
- 📚 Books
- 🤓 Courses
- 🤝 Management Resources
- 👥 Engineering Management Handbooks
- 💡 Thoughts from other Engineering Managers
- 🗄️ Management
- 💻 To Code or not to Code
- 📧 Newsletters
- 🫂 Communities
- ⚙️ Engineering Management - All The Things
- Managers READMEs
- Engineering Playbooks
- Software Development Process
- Development
- Technical Specifications/ADRs/Design Docs
- Spikes & Experiments
- Technical Radar
- System Design
- Knowledge Management
- Hiring
- Onboarding
- 1:1s
- Engineering Objectives
- Engineering Roles
- Engineering Values
- Culture
- Delegation
- Team Scaling
- Build great stuff
- Engineering
MetricsIndicators - Performance Management
- Feedback
- Engineer - Manager - Engineer
- Performance Improvement Plans - PIP
- Remote Team Management
- Conversations
- Team Contracting
- People Management Misc
- Offboarding
- Misc
- 🤡 Fun
💻 Resources for leading great teams of software engineers.
I am a tech professional & international development enthusiast with more than 10-year experience in software engineering and leadership roles.
I started as an Engineering Manager in May 2021 and learned a lot through the great resources I found online. My life would have been a lot tougher without these fantastic authors who shared their experiences and advice, and I am incredibly grateful for that. This handbook is a compilation of links and templates that supported me in my Engineering Management journey. I am sharing it here, hoping it will serve others going through the same career transition.
| Emoji | Description |
|---|---|
| 📜 | Template |
| 🌎 | Remote Work |
| 📹 | Video |
| 🧰 | Tool |
- Turn the Ship Around - A True Story of Turning Followers into Leaders, David Marquet
- Become an Effective Software Engineering Manager - How to Be the Leader Your Development Team Needs, James Stanier
- Effective Remote Work - For Yourself, Your Team, and Your Company, James Stanier
- Leading Snowflakes - The New Engineering Manager's Handbook, Oren Ellenbogen
- Software Engineering - The Soft Parts, Addy Osmani
- High Output Management, Andrew S. Grove
- Mythical Man Month - Essays on Software Engineering, Frederick Brooks Jr.
- Crucial Conversations - Tools for Talking When Stakes Are High, Joseph Grenny, Ron McMillan, Al Switzler, Kerry Patterson, Laura Roppe
- Radical Candor - Be a Kick-Ass Boss Without Losing Your Humanity, Kim Scott
- Continuous Discovery Habits - Discover Products that Create Customer Value and Business Value, Teresa Torres
- Leverage Points - Places to Intervene in a System, Donella Meadows
- The Manager's Path, Camille Fournier
- An Elegant Puzzle: Systems of Engineering Management, Will Larson
- Drive - The Surprising Truth About What Motivates Us, by Daniel H. Pink
- Team Topologies, by Matthew Skelton and Manuel Pais
- Nonviolent Communication: A Language of Life, by Marshall B. Rosenberg
- Presentation Zen: Simple Ideas on Presentation Design and Delivery, by Garr Reynolds
- Rippleworks - Growing Yourself - Mastering leadership begins with managing self
- Rippleworks - Managing at Your Best - Leading with intention and purpose as a rising manager
- 🧰 Building a Second Brain: The Illustrated Notes. Building a second brain is about creating a system – outside your physical skin-and-bone bodily boundaries – for storing, organising, and eventually transforming information.
- Code with Mosh
- Educative.io
- 📹 Speaking with confidence
- The Management Center
- LeadDev - Learn effective engineering management and leadership
- GitLab Handbook
- How Engineering Management Works at GitLab
- ostronom/awesome-engineering-managers-handbook
- jesselpalmer/the-engineering-managers-booklist
- ksindi/managers-playbook
- charlax/engineering-management
- The Big List of Engineering Management Resources
- Surprise! You’re an Engineering Manager. What now?
- Managing the First Year, Alex K Gold
- Developer turned Manager
- Things I've learned transitioning from engineer to engineering manager
- Eng Mgmt series, Matthew Vanderzee
- Good engineering manager vs Bad engineering manager
- Why should you (or anyone) become an engineering manager?. (...) technical skills do decay and become obsolete, particularly language fluency, but people skills do not. Once you have built these muscles, you will carry them with you for life. They will enhance your ability to connect with people and build trust, to listen perceptively and communicate clearly. Whatever you decide to do with your life, they will increase your optionality and make you more effective.
- How New Managers Fail Individual Contributors
- Soft Skills for Managers. Initiative, Emotional Control, Dispassionate Empathy.
- Evaluating Managers: 5 heuristics to measure managerial impact. Five signals that should provide some early to medium-term signals to facilitate early course correction or doubling down on strengths: Execution, Strategic Vision, People Management, Team Growth, and Organizational Influence.
- Don't Create Chaos. Great leaders vacuum up chaos. Be a source of stability.
- How to Build Trust. You can’t build trust through artificial “trust building” exercises, nor can you say “trust me” and expect it to work. The only way you can build trust is by demonstrating, over time, that you’re deserving of trust.
- New Engineering Managers Have a High Failure Rate — This Figma Leader is on a Mission to Fix It
- The Good Engineering Manager Framework
- The Hagakure #80: Why Coaching (Really) Matters for Engineering Leadership
- The Manager as Debugger
- "Can't Code! Not inclined to Hire?" - Why Engineering Managers Don't Need to be Great Coders
- Should you Stay Technical as an Engineering Manager?
- Software Lead Weekly. A weekly email for busy people who care about people, culture and leadership.
- LeadDev. Develop your engineering management skills with weekly email updates from top tech experts through the LeadDev community.
- The Pragmatic Engineer. Relevant for software engineers and engineering managers, useful for those working in tech.
- The Engineering Manager. Tools, tips and discussions for current and aspiring engineering leaders.
- Pointer.io. A Reading Club For Software Developers.
- Rands Leadership Slack. The Rands Leadership Slack (“RLS”) exists to help longtime, new, and aspiring leaders to learn through conversation and sharing of ideas.
I have a love-hate relation with Manager READMEs, as I am never confident that I am 100% self-aware (I am working hard to get better at that). While I do believe READMEs can be a great tool for getting to know our colleagues and their working preferences, I also believe that one needs a high level of self awareness and humility to get it right.
- Manager README. Great examples in the Community section
- GitLab Engineering READMEs
- 49 Manager READMEs
- A user guide to me
- I hate manager READMEs, by Camille Fournier
- Why I stopped using Manager READMEs and no longer recommend them
- Microsoft Code-With Engineering Playbook
- GitLab Engineering Handbook
- Thoughtbot Playbook
- Atlassian Engineering’s handbook: a guide for autonomous teams
- How to make (almost) anything
- Human Made - Engineering Handbook
- Reduce Friction
- Creating Good Process. Triggers - Actions - Review.
- 24 Fundamental Techniques for Software Architects
- Choose Boring Technology
- Code Review Best Practices
- The Practical Test Pyramid
- Consultative QA as a way to empower engineering teams
- DevOps culture: Westrum organizational culture
- 📜 Design Document Template
- Design Docs at Google
- A practical guide to writing technical specs
- Painless Functional Specifications
- Architectural Decision Records (ADRs)
- On Architectural Decision Records ADRs
- Markdown Any Decision Records
- Elements of the Tech Stack Canvas
- How to write a good software design doc
- Accumulation of tech debt; experiments and shortcuts are core components.
- The Effects of Technical Debt on Morale. It wastes time, it makes developers unhappy, it makes developers less productive, it leads to turnover, it influences developer morale.
- ThoughtWorks Technical Radar
- Technology Radar for Technology Strategy. What is it and how to build it?
- AOE Technology Radar
- 🌎 Hiring in a Distributed World
- How I interview engineers to assess ability to deliver impact + 1-Pager
- 'Just Say No' to These 4 Interview Formats
- 📜 Welcome message
- 📜 First 90 Days - Software Engineer
- 🌎 How to successfully onboard remote engineering staff in four weeks
- Feelings Wheel
- Atlas of Emotions
- 📜 My 1:1 Template
- 📜 The Management Center - Check-in Meeting Agenda Template
- 📜 GitLab - 1-1 Suggested Agenda Format
- 96 Questions To Ask Your Manager During Your One On Ones
- 📜 32 One-on-one Meeting Templates
- 📜 Objective Setting Workshop
- 📹 Goal-Setting Workshops for Managers, Melinda Seckington
- 📜 Objective Tracker Template
- 2024 Guide to Goals for Software Engineers
- Engineering Goals and OKR Examples
- Good Goals, Bad Goals
- Forget About Setting Goals. Focus on This Instead.
- Team Leader Venn Diagram
- Career framework inspiration from the world's best companies
- 📜 CircleCI Engineering Competency Matrix
- What We Did Differently With Pleo’s Engineering Career Framework
- Software Development/Leadership Ladder, multi-track, public
- An incomplete list of skills senior engineers need, beyond coding
- Engineering Org Structures— The QRF Team Model
- Uber’s engineering level changes
- Navigating the Software Engineering career ladders
- Deltas to the Global Maxima - Better conversations beyond the career track
- Driving Cultural Change Through Software Choices.
- Developers have more power than they imagine to change the engineering culture around them. As you build software that others will use or that your peers will work on, are you making it easy for them to do the right thing? If you build platforms, bake in easy integrations for the software values you want to see. If you’re in the position to choose new tools, pick ones that support the standards you want taken seriously. And as you write code, make it easy for others who will copy-paste what you’ve done to then do the right thing.
- I’ve never met an engineer who didn’t occasionally copy-paste-modify some code. One of my earliest professional software lessons was that when you set up a codebase full of tests, other engineers are likely to write tests for their code because there will be lots of examples for how to test. This generalizes to the observation that people are most likely to take an existing thing and tweak it into a new thing that does what they need, and in the process they will take the good and bad from that existing thing. So if you want them to follow a best practice, put it in their starting templates.
- We can go further than observability. Security can be a process, or a cultural value, but you can also go quite far by providing tools and platforms that have good security practices baked in to them, so that you’re not relying on the good citizenship of your development team. Testing is often hampered by the overhead of running tests, and investment into infrastructure that makes tests easy and fast to run is important to supporting a culture of software quality validation.
- Be a thermostat, not a thermometer. Since humans tend to mirror each other, you can intentionally change the energy in the room, setting the thermostat to a more comfortable temperature.
- Own It Mentality. I give people lots of autonomy. I don’t micromanage. In return, I expect people to take initiative, be proactive, communicate well, and follow through on their commitments. So long as they have an Own It Mentality, I don’t care how much somebody works, when they work, or where they work from.
- How To Fix Broken Teams
- The Disappointment Frontier
- Status games- Technical decisions should be based on merit, not the relative status of the protagonists.
- How to scale a unicorn-building engineering team (and stay sane)
- Heuristics for Effective
Software DevelopmentOrganizations: A continuously evolving list.* - The Five Stages of Team Development
- A framework for balancing and budgeting engineering resourcing
- Theory of Constraints 105: Drum-Buffer-Rope at Microsoft
- Shipping the org chart
- How to go for 10X
- Rands Leadership Slack - Engineering Effectiveness
- Parkinson's Law: It's Real, So Use It. Parkinson's Law states that "work expands so as to fill the time available for its completion." Projects that don't have deadlines imposed on them, even if they are self-imposed, will take a lot longer than they need to, and may suffer from feature creep and scope bloat.
- 📜 A guide for announcing change to your organization
- 📹 Output vs. Outcome & Impact
- When they don’t know what to do, they’ll do what they know.
- Jason’s perspective on effective product development culture
- A decade of building (pretty) great software data products
- PM & EM: Rules of Engagement
- The Product Culture Shift
- DORA Metrics: We’ve Been Using Them Wrong. The 4-step Process to Improve DORA Metrics: Benchmark Your Performance, Look at the Leading Indicators, Establish Team Working Agreements, Optimize Developer Workflow.
- How to do great things.
- "When you read biographies of people who've done great work, it's remarkable how much luck is involved. They discover what to work on as a result of a chance meeting, or by reading a book they happen to pick up. So you need to make yourself a big target for luck, and the way to do that is to be curious. Try lots of things, meet lots of people, read lots of books, ask lots of questions."
- "I think for most people who want to do great work, the right strategy is not to plan too much. At each stage do whatever seems most interesting and gives you the best options for the future. I call this approach "staying upwind." This is how most people who've done great work seem to have done it."
- Getting buy-in to get things done
- "When you are in one of these roles and you're championing an initiative, it can feel like the goal is to get people to agree with you on the proposal. But what you really need is for people to actually do the work, not just say that it sounds good. There's a big difference, because it's much easier for someone to agree something should happen than to actually do it themselves."
- How we decide what to build
- "While it’s fun to discuss whether an application should be implemented in Ruby or Clojure, to write beautiful and succinct code, to see how far purely functional programming can be taken, these are all secondary to defining the user experience, to designing a comfortable interface, to keeping things simple and understandable, to making sure you’re building something that’s actually usable by the people you’re designing it for. Those are more important decisions."
- KPIs, Velocity, and Other Destructive Metrics
- 17 popular software engineering metrics, and how to game them
- The False Trade-off Between Quality and Speed
- How to talk about deadlines at work
- 📜 Performance Review Questions
- 📹 Drexler/Sibbet Team Performance Model
- The 9-Box Grid: Benefits & Limitations in 2023
- 📜 9 Box Template
- Management Basics: Determining a Performance Rating. Method that splits goals up into three categories: must be achieved, stretch goals, and moonshot goals.
- Your Career - Performance & Promotion
- Moving Motivators
- Managing High Performers
- Managing Underperformers
- Underperformer
- How hard should your employer work to retain you?
- 📜 The Management Center - 2×2 Feedback Form
- The Management Center - Give More (and Better) Feedback with CSAW - CSAW (Connect, Share, Ask, Wrap up)
- Radical Candor — The Surprising Secret to Being a Good Boss
- 11 ways to get better feedback from your manager
- Engineering Managers' Guide to Effective Annual Feedback
- 📜 Formal Performance Warning Sample
- 📜 Performance Improvement Plan PIP Template
- The Management Center - Performance Problems. Includes a Performance Improvement Plan Toolkit.
- GitLab - The Remote Playbook
- GitLab - How to embrace asynchronous communication for remote work
- 10 ideas for building high-performing remote teams
- 330 Icebreaker Questions to Try with your Team
- 🌎 Zoom Icebreakers: Comprehensive List of Ice Breakers and Zoom Games for Virtual Meetings in 2023
- Icebreakers, via The Art of Noticing by Rob Walker
- 🧰 Standup Alice Bot
- 🌎 Goodbye Standups, Hello Wrap-Ups: Rethinking team alignment for asynchronous, remote work
- Why Your Team Members Need Daily Check-Ins
- Async daily standups: the pros & cons
- 57 Daily Standup Questions for More Engaging Updates
- Awesome Retrospectives
- 🧰 Stickies.io
- 📜 FunRetrospectives - Activities and ideas for making agile retrospectives more engaging
- Growing our team with retrospectives
- SWOT Analysis
- Bricks of Love: create purpose and engagement with weekly updates
- 📜 Bricks of Love Template: weekly update to your team
- 1:1 Contracting
- 📜 The Team Contracting Template - Miro board
- Team Contracts to outline the ground rules of a team
- Are you serious?
- Classic Mistakes Enumerated
- Why Projects Fail
- Why Projects Fail - 101 Common Causes
- The 15 Commitments
- Speak in Stories. Studies have shown that emotion is critical to memory. Given two stories with the same facts, we remember the more emotionally evocative story far longer. One thing that’s amazing is that memory isn’t zero sum. If we heard ten good stories today we could remember them all better than we would remember even one list of facts.
- '68 Bits of Unsolicited Advice ' by Kevin Kelly
- Mental Health in Software Engineering
- Separation
- How To Understand Things
- How to Build Engineering Strategy
- How to gather people and create communities in ways that are low-stress and high-payoff
- Writing. If you're thinking without writing, you only think you're thinking. (...) Moreover, writing isn’t just about the self. It’s also about contributing to the larger discourse.
- Design Your Organization for the Conflicts You Want to Hear About."The primary goal in organization design should not be reducing of span-of-control, but in surfacing conflicts most important to the company. Determine the conflicts you want to hear about — presumably because you can add the most value in resolving them — and then design the organization to make sure you do. No department should report into an executive who can’t add value to it."