Giters

andrablaj / engineering-management-handbook

💻 Resources for leading fantastic teams of software engineers

Repository from Github https://github.comandrablaj/engineering-management-handbookRepository from Github https://github.comandrablaj/engineering-management-handbook

engineering-managementhandbookleadershipmanagement

Table of Contents

Engineering Management Handbook

💻 Resources for leading great teams of software engineers.

👩‍💻 About Me

I am a tech professional, international development enthusiast and language geek with more than 12 years of experience in software engineering and leadership roles, committed to using technology for positive social impact. I deeply believe that when you care, more people will care, too, and I apply that belief to everything I do.

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.

🗺️ Legend

Emoji Description
📜 Template
🌎 Remote Work
📹 Video
🧰 Tool

📚 Books

🤓 Courses

🤝 Management Resources

👥 Engineering Management Handbooks

💡 Thoughts from other Engineering Managers

🗄️ Management

💻 To Code or not to Code

📧 Newsletters

  • 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.

🫂 Communities

  • Rands Leadership Slack. The Rands Leadership Slack (“RLS”) exists to help longtime, new, and aspiring leaders to learn through conversation and sharing of ideas.

⚙️ Engineering Management - All The Things

Managers READMEs

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.

Engineering Playbooks

Software Development Process

Development

Technical Specifications/ADRs/Design Docs

Spikes & Experiments

Technical Debt

Technical Radar

System Design

Knowledge Management

Hiring

Onboarding

1:1s

Engineering Objectives

Engineering Roles

Engineering Values

Culture

  • 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.

Delegation

Team Scaling

Build great stuff

  • 📹 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."

Engineering Metrics Indicators

Performance Management

Feedback

Engineer - Manager - Engineer

Performance Improvement Plans - PIP

Remote Team Management

Conversations

  • A field guide to dudes who ruin meetings
  • Meetings for an effective eng organization.
  • What is Open Space Technology?
    • 1. ‍Whoever comes are the right people: Since people can choose what sessions to attend there has to be to trust, that the people that come are the right people. Even if a session only has two participants these two people might be exactly the right people to meet at that time to do something great together. ‍ - 2. Whatever happens is the only thing that could have: Open Space Technology events have an emerging character. No one can possibly predict, how things might unfold. Therefore, participants are invited to concentrate on the moment with an open mind.
    • 3. Whenever it starts is the right time: Creativity moves on its own timeline independent of the meeting or event schedule. Therefore, participants should be attentive to when creativity arises. Whether that is as part of the group sessions or in one to one conversations at the lunch buffet.
    • 4. When it is over, it is over: Getting the work done is more important than sticking to the schedule. When a group is in the perfect flow, then they can decide to continue their discussions. Or, if they finish their topic earlier, the can also close the session and do something else instead.

Ice breakers

Dailies

Retros

After-Action Reviews (AARs)

Weekly updates

Team Contracting

People Management Misc

Offboarding

Misc

🤡 Fun

About

💻 Resources for leading fantastic teams of software engineers

engineering-managementhandbookleadershipmanagement

License:GNU Affero General Public License v3.0

Languages

Language:Shell 100.0%