Great Engineering Managers

Great Engineering Managers

Photo by Zac Durant on Unsplash

Over time, I have noticed a subtle difference between an "engineering" manager and an "engineer" manager. Ajey Gore and Charity Majors have eloquently explained this difference in some of their tweets and blog posts, which I highly recommend everyone to follow.

💡Subtle Difference

  1. An engineering manager focuses more on the "engineering" aspects, such as processes, release flows, and deliverables, rather than on managing people. Some companies also call this role a "program manager," which can create further confusion.

  2. An engineer manager is more focused on managing people, such as team and individual performance, mentoring, coaching, and resolving conflicts between team members. They do not necessarily unblock technical problems themselves but rather unblock people who can solve the problems as a first party.

Unfortunately, many companies in the software industry confuse these two roles. This confusion can be further compounded when an individual contributor (I.C) is offered a promotion to "engineering manager" after working as a staff/principal engineer for years. If you find yourself in this position, I highly recommend reading the following two blog posts first:



😎 Key Traits of Great Managers

Regardless of the difference between the two and whether your role is a mix of both (which is often the case in many companies), here's what I believe distinguishes an average manager from a great one:

  • Schedule regular 1:1s with all of your direct reports, regardless of their level. There should be no excuses. You should be meeting a new joiner from a university just as frequently as an architect with 20 years of experience. It should be set up by you as a recurring/scheduled meeting. I have seen managers ask the engineers to schedule one if needed. This is not acceptable. As a manager, it is your job to schedule these meetings.

  • Use this time to see, understand, and discuss how the person is working and how their trajectory is looking. If time permits, you can also use this time to talk about general/non-work-related topics. This strengthens trust between each other.

  • If you conduct regular standup meetings, do not (I repeat! do-not) use this 1:1 time to discuss ongoing work.

  • Ensure there is a clear agenda set before the meeting starts, and make sure you record action items during the meeting. Notion is a great tool to help with this. Recurring templates are a boon. Here is an example of my meetings list 👇🏻. (And yes, I am a template freak!)

  • Don't lose touch with technology as it greatly hinders how you communicate effectively with your team's engineers, architects, or anyone technical. Charity Majors gives a sample of recommended tasks (mentioned below) a manager can do, to keep the hands warm, as opposed to following a broad bad advice like “A manager shouldn’t code” :

    • Authoring/Coding a feature ? No

    • Covering on-call when someone needs a break ? Yes

    • Diving into the biggest project after a post-mortem ? No

    • Code reviews ? Yes

    • Picking up a P2 bug that's annoying but never seems to become top priority ? Yes

    • Insisting that all commits be gated on their approval ? No

    • Cleaning up the monitoring checks and writing a library to generate coverage ? Yes

  • Attend tech spec review meetings.

  • Clearly define the focus areas for your team, and make sure anyone higher up is well aware of them. I call them "Focus Trains."

  • Every task every engineer picks up should belong to one of the Focus Trains.

  • Don't ever define an "adhoc" Focus Train and accept all adhoc tasks in that. It's counter-intuitive and does more harm than one can imagine.

  • Make sure all the work your team does flows through you and you alone. No team member should be pulled to work on some deliverable which takes more than an hour and that you didn't know about.

  • Set up incentives to boost the team's motivation to achieve something substantial. Why? Because motivation is always temporary. Therefore, staying on the path to high performance should be nurtured sometimes with external factors. (This topic requires a full blog post in itself. Leave a comment if you wish to see one.)

  • Conduct performance reviews every quarter or every 6 months atleast to provide more detailed and precise data for salary raises, which typically occur once a year.

    • Do not take data from the last 2 weeks into account. Recent experiences will always skew the final results, whether positively or negatively.

    • Keep a log/journal of your remarks (both positive and negative), mentioning the context (i.e., the task) and date. Ensure you communicate this feedback early on as opposed to once in 3 or 6 months. Every perf review should never have any shocks.

  • If anyone is eyeing for a promotion, help them out by suggesting a structure to the promotion packet if you don't find one. ( Promotion Packet for Abc Xyz is a template I prepared, which you can freely use as a reference/inspiration.)

  • A person is expected to get a promotion if they are already performing at that (next) level. And officially, you just want to call it out. Yes! Titles matter as they give a sense of influence/authority when there is a conflict. Positive influence/authority is required sometimes.

  • Pass "appreciation notes" at least once every 3 months to team members in areas in which they are excelling.

  • Be a shield that protects your team from all the negativity they receive from others.

  • Be totally transparent with all the appreciation your team members receive from others.

  • Remember that "Agile" is not just about using "Jira" or any other ticketing tool. There are other factors to consider. One way to ensure important tasks are not forgotten is to schedule periodic reminders, for example, to review security vulnerabilities or team velocity metrics. While anyone can log thousands of tickets for the future, it is important to have a system in place to resurface high-impact tickets before it's too late.

  • Use O.K.Rs as a measure to get better at the process, but not like a weapon that punishes people. “Measure What Matters” (mentioned below) is a must-read book in this regard.

  • When managing a project with bigger timelines (like months/years), ensure there is a clear roadmap/swim-lanes view for everybody, for short/frequent and consistent releases.

  • Use numbers to quantify everything. People are suckers for numbers. A wise man said If something can't be measured, it can't be mastered.

    • When managing a service team that is working on a critical/strategic release, what numbers show consistent release cycles? What is your lead time (feature-request >> development >> deployment)? What is your defect escape rate?

    • How much time does a new joiner take to push code to production? How much time does a resigned employee take to complete knowledge transfers?

    • When managing a team that makes other developers productive, by how much, on what dimensions?

    • When managing a project that makes customer lives happier, by how much, on what dimensions?

    • When managing a hiring team, what is the average time required to fill a vacant position?

    • To master knowledge-sharing/collaboration, how many knowledge-sharing sessions are done, code reviews done, cross-function collaborations done, in a quarter?

    • And many more.

  • Demand excellence (from the team) while remaining humble enough to help others achieve it by setting the path towards excellence. Ensure while Mediocrity never thrives, High performance never goes unnoticed.

There are many more things (like hiring etc…) a great manager excels at. But this post is already too long 🤷🏻.

⌛ Conclusion

Remember that every human being is a "learner." By seeing you as a manager, every one of your team members learns how to work and/or how NOT to work. Which example you set, is up to you.