I've just recently begun a new job. For 7 years I've been doing some form or or another of engineering management at GoHealth, Inc. There were definitely things that I appreciated about being a manager. Mentoring other engineers has been one of the more rewarding things I've ever done in my career. But being a manager is exhausting work. It's emotionally and mentally exhausting. I'm ready to take a break from it all for at least a bit. I don 't know for sure that I'll never do it again but I do know that I need to not be doing it for a while so I can rest.
I do want to take some time to write down what I've learned being a manager as I leave it behind. Some of what I learned is just general management learnings. But some of it is more germaine to being an engineering leader specifically. The following is a list of my collected notes over 7 years of being a manager of software engineering teams. I've broken them up into General management lessons and Engineering management lessons.
- Peer review is an important signal in employee reviews.
- An employee's peers have more on the ground knowledge of how someone is doing on the team.
- As a manager we have context on how their contributions contribute to the company's goals.
- It is easier to break culture than it is to fix culture.
- Your decisions as a manager have a wide blast radius.
- You need to have a light touch.
- Collaborative Working sessions are a useful forcing function.
- But asynchronous effort is often more efficient.
- Matrix organizations have a higher communication burden. Lines of communication are mutating and fuzzy.
- Part of managing up is not hiding problems.
- Sometimes you have to let things fail to ensure that problems get addressed.
- Part of managing down is owning and apologizing for mistakes.
- Good employees will forgive and respect you for owning your mistakes.
- Bad employees will be impossible to please. You will have to manage them out.
- Documentation is just as important as Code. Make sure you prioritize it.
- Doctests help to ensure code documentation is up to date.
- documentation that is versioned with the code is better than a wiki
- generating and publishing docs from a repo as part of a ci/cd pipeline is preferred.
- Automated Testing is better than Manual every time.
- Scrum/Agile or other methodologies are a defensive workaround not a solution.
- if you can fix the core problem then you won't need the methodology.
- Process can't fix the problem of too much process.
- CI/CD get's progressively harder to implement the more software you have
- You are better off starting out with it in place or very early on.
- All else being equal having a smaller set of supported technologies is an
organizational super power.
- It's important to choose a set that actually fits your needs.
- Zero Trust is hard if you didn't design for it in the beginning.
- During an outage it's not uncommon for people to be experiencing multiple
- Make sure your team is categorizing each type of issue so you can distinguish between them.
- Look for the systemic problem not the individual surface problems.
- If you have hired and run planning in a particular way for a long time then
any dramatic change needs to be planned and communicated well ahead of time.
- Make sure to include timelines and milestone in your communication.
- Be aware that you are probably violating some sort of social contract with your people when you do so.
- Expect emotions and departures in some cases.