97 Things Every Engineering Manager Should Know: Collective Wisdom from the Experts

There are management tomes taught in MBA classes, and then there are books like this where practitioners share what works in real life. The leaders in this book come from diverse backgrounds, geography and culture and are at various phases of their journey - some VPs and some trying out technology management for a few months. Such kaleidoscopic nature makes “97 things” a unique learning tool - you flip a few pages and you will learn something new. Combination of tools, easily digestible aphorisms, frameworks and often a set of “simple rules” will leave the reader at a much richer elevation irrespective of her leadership tenure. At least a third of the articles are indeed practicable and should pass a rigorous test in most learning organizations. I highly recommend the book.Some notes and ideas I took away -1. Make every fourth 1-on-1 a retrospective to improve your 1-on-1s.2. Brainstorm a Glad-Sad-Mad list and follow up with the latter two.3. Ensure you can always take at least a week off without business disruptions. Ensure everyone else in the team can too!4. If you are not able to provide your reports with meaningful, in-depth feedback - change the structure.5. Pay attention to the topics people seem to value your opinion on. Those areas make you a “multiplier” - where you can scale an organization non-linearly.6. Do you have your README? A simple one-page document that lists out your personality quirks. Writing it down will make you vulnerable - that’s actually a good thing.7. Always remember that you have a huge power differential over a person who reports to you. Behave in an ethical, reliable and - more importantly - repeatable manner cognizant of that power differential. It’s all about “Servant Leadership”.8. Outcomes are more important than outputs. However, do not fall in love with outcome over process. At some point, you will stop lifting more weights. I.e., your outcome won’t excite you as much. Sticking to process will ensure you still work out at that point!9. Eyes on, Hands off - you are a guide, not a mapmaker.10. “You want to give people a little more freedom than you’re comfortable with”11. As the team grows, bring in more specialization. Generalists are more motivated to work on the hardest business problems. Specialists are more motivated to work on most difficult technical problems.12. A manager is like a logger - depending upon the organization and complexity “log” information on various levels - debug, warn, error etc.13. Push bursty updates even about things mostly on track. Patterns for communicating upward are almost the inverse of communication with your team.14. You will rarely run into a problem over communicating, especially the larger the org grows.15. 3-step process of TED talk - a) X because of Y b) Details of Y c) Let’s do Z so we can accomplish X because of Y16. Before every presentation, write down the narrative. Then reframe for positivity.17. Constantly reinforce the “why”18. Practice “Continuous Kindness” - you don’t have to be nice, but you are expected to be kind. Remember Agile mantra of “individuals and interactions over processes and tools”.19. Culture is like gravity in an org - when no other force or explicit direction is present culture determines what happens next.20. Be aware that culture naturally resists quantitative metrics.21. A company’s product is the what. Their customers are the why. Their employees are the who. Culture is the how.22. Ensure standups happen early in the day. Ensure at least one meeting free day for the “makers”. Delegate leading standups to a senior engineer.23. Set up a “read only communication channel” in Slack or agree on “quiet hours”.24. Intentionally not doing certain things is a manager super power.25. For your teams, don’t be a shit umbrella. Provide context as you would provide an adult.26. Evaluate candidates on this order - Values >> Abilities >> Skills.27. Skills are depth, perspectives are breadth.28. Project Management should be integral to engineering management. Whenever possible, do your own project management.29. Two things demarcate great teams - (a) psychological safety and (b) regular shipping of code30. Multiplier - when one’s work enables other people’s work. I.e., your work exerts leverage.31. What you’re good at test - what’s a topic you can speak (a) at any level and (b) for any length of time?32. Deliver the conclusion at the start.33. For a manager - scope of control. For a leader - scope of influence.34. When your team is struggling, ask two questions -How do I create clarity?How do I create capacity?35. Chaleff Model of followership - junior engineers aren’t expected to be implementers or partners. Value partners as they will keep you honest.36. Estimation fallacy - estimation is done in a low-information environment. When you have enough information, you do not need to estimate much.37. Rituals are tools to shape culture.38. Two simple rules of deployments -Everybody should be able to deploy. Never have an “approver”.Deployment should be automatic and done on-demand, if not continuously.39. Measure commit-to-deploy time for development velocity.40. Feynman algorithm -Write down the problemThink very hardWrite down the solution41. The best test run is cheap and narrow.42. You may keep a running Google doc for 1x1s. They are “safe spaces”. Start with “how you feel”.43. Pay attention to not when, but how one gets stuck.44. Don’t surprise people.45. “Wherever there is authority, there is a natural inclination to disobedience”. Leadership is responsibility, not authority.46. Over-index on in-person, two-way communication over one-way, hierarchical power communication.47. Homogeneity will facilitate smooth and effortless interactions, but diversity drives better decisions.48. Management is not a promotion, but radical career change.49. Think of API responses when working with people - 200-OK, 500-server error (does the employee have a family problem?) etc.50. CapEx is omitted from EDITDA, OpEx is included - remember this when dealing with finance.51. Accountability is a capability, not a measure.52. Good managers know when to amplify or dampen the corporate leadership line.53. Definitely don’t be the first one in and last one out every single day. You may overwhelm the team.54. Develop an awareness of when you’re gaining political capital and when you’re spending it. Do spend it strategically.55. Micromanagement is anti Agile! Autonomy is the sole key to top-performing people and teams. Do not be an order giver, be facilitator and enabler. Your only job is to provide psychological safety.56. You, and the organization, are always just five decisions away from death. And you’ve taken the first one by starting here. Ensure multiple redundant safety systems - both in technology and in people.57. Scale communication through writing. Avoid any meeting that can be a short note or a 6-pager readout. 6-pagers do “introvert inclusion” in decision making.58. Be extremely careful of “thinking out loud” when you’re in a powerful position. The team may take it as a directive!59. In any situation, you can be either a “minus one”, a “zero” or a “plus one”. When you do not have enough context, be a zero rather than be a +1 and make your presence felt.60. Team stability is extremely important. Be extremely careful of disrupting it. Psychological safety (Google study found it to be #1 attribute of high-performing teams) is positively correlated with team effectiveness and negatively correlated with membership changes.61. 3 good questions for interview -What have you learned in the past 6 months?Tell me about a failure and what you learned from it?Do you have skills, expertise and experience - in that order - to do the job?62. Avoid causing anxiety. Do not throw a bomb before the weekend.63. Before getting angry at a complainer remember that complains are predicated on the complainer’s experience. 64. Try to dig that relevant experience out with deliberate discussion.65. Deep Work: Leaders define communication protocols to reduce overhead of collaboration (most often measured in meetings).

this is not as good as the other book: the manager's path. It's not organized. It seems the author didn't spend time in writing the way she wrote the first book

This book seems to have good information so far, but I wanted to highlight that it is based on software engineering. That certainly doesn't negate the information, but the context is important.

Just like any numbered list, its important to check your sources. I have worked and/or know a few of these authors and can attest that the worst of the business are the ones with the time to write these books. They are the one's spamming their company slack bragging about what they are published in and say a lot of buzzwords in meetings but the only thing they really contribute to a project is chaos. I am afraid that less experienced folks will eat this up and take the words of books like these as gospel truth even though they come from charlatans.

Lots of great information ranging from new ideas to basic reminders. I love the layout of the book, it enables a "choose your own adventure" style rather than "read everything to get anything".

Full of advices that I hope will be useful for my collegues that are starting in this role. I acquired copies for them after I read my copy.I had no such book many many years ago when I started as a Dev Manager so most probably I did a lot of mistakes or invented many things already invented by others, at the expense of company’s time :). This book will help you to do your job better , that is for sure.