Feynman Algorithm, Chaleff Matrix and 95 other things for Engineering Managers

Review — 97 Things Every Engineering Manager Should Know

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 — flip a few pages and you will learn something new. Combination of tools, easily digestible aphorisms, frameworks and a set of “simple rules” will leave the reader at a much richer elevation irrespective of her management 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 new book.

Some notes and ideas I took away -

• Make every fourth 1-on-1 a retrospective to improve your 1-on-1s.
• Brainstorm a Glad-Sad-Mad list and follow up with the latter two.
• Ensure you can always take at least a week off without business disruptions. Ensure everyone else in the team can too!
• If you are not able to provide your reports with meaningful, in-depth feedback — change the structure.
• 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.
• 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.
• 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”.
• 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!
• Eyes on, Hands off — you are a guide, not a mapmaker.
• “You want to give people a little more freedom than you’re comfortable with”
• 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.
• A manager is like a logger — depending upon the organization and complexity “log” information on various levels — debug, warn, error etc.
• Push bursty updates even about things mostly on track. Patterns for communicating upward are almost the inverse of communication with your team.
• You will rarely run into a problem over communicating, especially the larger the org grows.
• 3-step process of TED talk -

X because of Y

Details of Y

Let’s do Z so we can accomplish X because of Y

• Before every presentation, write down the narrative. Then reframe for positivity.
• Constantly reinforce the “why”
• 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”.
• Culture is like gravity in an org — when no other force or explicit direction is present culture determines what happens next.
• Be aware that culture naturally resists quantitative metrics.
• A company’s product is the what. Their customers are the why. Their employees are the who. Culture is the how.
• Ensure stand-ups happen early in the day. Ensure at least one meeting free day for the “makers”. Delegate leading stand-ups to a senior engineer.
• Set up a “read only communication channel” in Slack or agree on “quiet hours”.
• Intentionally not doing certain things is a manager super power.
• For your teams, don’t be a shit umbrella. Provide context as you would provide an adult.
• Evaluate candidates on this order — Values >> Abilities >> Skills.
• Skills are depth, perspectives are breadth.
• Project Management should be integral to engineering management. Whenever possible, do your own project management.
• Two things demarcate great teams from not-so-good ones — (a) psychological safety and (b) regular shipping of code. Provide the former so people could do the latter.
• Multiplier — when one’s work enables other people’s work. I.e., your work exerts leverage.
• What you’re good at test — what’s a topic you can speak (a) at any level and (b) for any length of time?
• Deliver the conclusion at the start.
• For a manager — scope of control. For a leader — scope of influence.
• When your team is struggling, ask two questions -

How do I create clarity?

How do I create capacity?

• Chaleff Model of followership — junior engineers aren’t expected to be implementers or partners. Value partners as they will keep you honest.

• Estimation fallacy — estimation is done in a low-information environment. When you have enough information, you do not need to estimate much.
• Rituals are tools to shape culture.
• 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.

• Measure commit-to-deploy time for development velocity.
• Feynman algorithm -

Write down the problem

Think very hard

Write down the solution

• The best test run is cheap and narrow.
• You may keep a running Google doc for 1x1s. They are also “safe spaces”, if you or your report is holding back it is not a good 1x1. Start with “how you feel”. Also, regular 1x1s are like 8-hour sleep. You will see a negative impact when skipped regularly.
• Pay attention to not when, but how one gets stuck.
• Don’t surprise people.
• “Wherever there is authority, there is a natural inclination to disobedience”. Leadership is responsibility, not authority.
• Over-index on in-person, two-way communication over one-way, hierarchical power communication.
• Homogeneity will facilitate smooth and effortless interactions, but diversity drives better decisions.
• Management is not a promotion, but radical career change.
• Think of API responses when working with people — 200-OK, 500-server error (does the employee have a family problem?), 300-may be it’s you, etc.
• CapEx is omitted from EDITDA, OpEx is included and both have very different tax treatments- always remember this when dealing with finance. Also, Cloud is OpEx.
• Accountability is a capability, not a measure.
• Good managers know when to amplify or dampen the corporate leadership line.
• Definitely don’t be the first one in and last one out every single day. You may overwhelm the team.
• Develop an awareness of when you’re gaining political capital and when you’re spending it. Do spend it strategically.
• 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.
• 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.
• 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.
• Be extremely careful of “thinking out loud” when you’re in a powerful position. The team may take it as a directive!
• 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. Think of this especially when you are new to a situation — org, role, team.
• 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. Don’t change it often.
• 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?

• Avoid causing anxiety. Do not throw a bomb before the weekend.
• Before getting angry at a complainer remember that complains are predicated on the complainer’s experience. Try to dig that relevant experience out with deliberate discussion.
• Deep Work: Leaders define communication protocols to reduce overhead of collaboration (most often measured in meetings).
• Ultimately, you can win most arguments with good code.