Principles of Engineering Management

Principles of Engineering Management

August 2019 marked my second full year of being an engineering manager. Transitioning from a software engineer to a manager was challenging for me.

The two jobs require very different skillsets which aren’t immediately evident. Engineering is more black and white than management. In engineering, you can often arrive at the rational solution by applying logic and analysis. I am a very logical person (my wife jokes that I’m a robot 🤖) so “thinking” like an engineer was natural to me.

Management involves working with people. There are grey areas and logic does not dictate the final outcome. Different people can look at the same outcome and reach different conclusions. As a manager, you have to understand all of the view points and then make a decision. That decision affects the lives of people that you know and work with every day.

The other big difference between engineering and management is the sense of fulfillment and control. As an engineer, you are always in control. It’s your code, your features, and your bugs. You ship it. You are responsible for it. At the end of the day, you can gauge your progress by these metrics. As a manager, you are largely not in control. You can set certain rules but your team has to execute on it. Your day consists of meetings and 1-1s and at the end of the day, you can’t point to anything that you accomplished.

To be good at anything, I believe you have to have some guiding principles. In my last two years through reading and experience, I have adopted the following thoughts which govern how I manage my team.

Who is this guide for?

  • A new manager: I hope this helps you in your day-to-day and you nod along as you read.
  • An engineer who is considering management: This guide will help you understand what to expect from the new role.
  • An engineer without any interest in management: This guide will help you understand what goes through your manager’s head every day (good choice, engineering is way more fun 😀).

What is a manager’s role?

A manager’s role is not to do the work yourself, even if you are the best at it, because that will only take you so far. A manager’s role is to improve the purpose, people, and process of their team to get as high a multiplier effect on the collective outcome as possible.

Purpose: The outcome that your team is trying to accomplish, also known as the “why”. Why are we building this thing? Why does our work matter?

People: Are the members of the team set up to succeed? Do they have the right skills? Are they motivated? Do they understand the purpose?

Process: Do people know how to work together? Are there roadblocks in their way? Are there clear decision makers.

Every time I feel I have something more important to do than listen to people, I remember: “It’s your job.”

Kim Scott (Radical Candor)

Who should become a manager?

Ask yourself the following questions:

  1. Do you find it more motivating to achieve a particular outcome or to play a specific role? Good managers need to adapt and do the unglamorous work. As your team changes (people joining/quitting, goals shifting), you need to be adaptable and do different things. If you love something too much to give it up, you will get frustrated.
  2. Do you like talking to people? You will spend a lot of time talking to people, ensuring that your team knows what they are working on, and that folks outside of your team know what to expect of your team. This is a huge change from regular engineering where you get lots of downtime to yourself.
  3. Can you be stable in an emotionally challenging situation? Management is about working with people and making good decisions, even if they are hard. You have to offer criticism to people in your team that you care about. You have to compartmentalize professional duties vs. your personal relationships with your team mates.

Do managers call the shots?

Many people want to become managers because they want to call the shots. This isn’t true. A good manager serves their team, making sure that they have what they need to succeed. While they do get to make a number of calls (hiring, deciding who works on what projects), those decisions are in the best interest of the team. Otherwise, the manager will lose the trust of their team and be ineffective.

The most valuable asset that a manager can have is the trust of their team.

Don’t be too nice

There is a Russian anecdote about a guy who has to amputate his dog’s tail but loves him so much that he cuts it off an inch each day, rather than all at once. His desire to spare the dog pain and suffering only leads to more pain and suffering.

This is an extreme example of being too nice. In Radical Candor, Kim Scott calls this ruinous empathy. Ruinous empathy is responsible for the vast majority of management mistakes. Most people want to avoid creating tension or discomfort at work. Being nice should never be prioritized at the expense of critiquing, and therefore, improving actual performance.

Be as specific and thorough with praise as with criticism. Go deep into the details.

Kim Scott (Radical Candor)

Always be a coach

A manager’s job includes understanding your team’s career goals, what projects are well suited to their strengths and interests, what they need help with, and how they are doing relative to expectations. You should think of yourself as a coach who is there to support your team and help them reach their goals.

In my first year of management, I used to do a lot of work myself because I felt that it was “too hard” for a new engineer to take on. I thought I was helping the engineer, but didn’t consider the fact the negative consequences:

  1. I was creating more engineering work for myself, when my priority should have been to manage.
  2. I was not giving a new engineer an opportunity to learn something new.

Don’t protect a report from a challenging project. Instead, provide them with the tools and support so that they have the highest chance of succeeding.

It always comes back to people

What makes people do good work? One way to think about this is the inverse: what gets in the way of people doing good work? There are two possibilities:

  1. People don’t know how to do good work, because they lack the skills. You can help by helping them learn those skills, or hiring someone with those skills.
  2. People know how to do good work, but they lack motivation. This could be because they don’t have a clear picture of what good work looks like. Or maybe they can do good work, but they are not interested because they would rather be doing something else. Or they may think nothing will change if they work harder (no rewards or penalties).

As a manager, you have to diagnose whether the issue is due to lack of skill or due to lack of motivation. The only way to do that is by having honest, constructive conversations together.

Trust is the most important factor

The responsibility of building a trusting relationship lies more with the manager than the direct report of the manager. This is because no matter how you slice it, the manager has more impact on the report’s day-to-day, than the report has on the manager’s.

It is human nature to want your manager to think well of you. Coming across as a complainer or a problem employee seems like a bad idea. However, if your reports don’t tell you exactly how they feel, you cannot manage them well.

Therefore, a manager has to do everything possible to build the trust so that their reports feel that they can be completely honest without fear of retribution.

Strive to be human, not a boss

A manager has to genuinely care about their team. Good managing is caring. If you do not respect or care about people who report to you, you cannot manage them well.

However, caring about your team does not mean always supporting their side of the story. You can and should still disagree and offer critical feedback.

Caring for your team means doing your best to help them be successful and fulfilled in their work. It means taking the time to learn what they care about.

Respect and caring should never be linked with performance.

Give constructive and timely feedback

One of the most important things you can do for your reports is to give them regular feedback. This is something I have struggled with, but I think I’m getting better at. Here are some opportunities for feedback:

  • Deploying a project
  • Speaking up in a meeting
  • Submitting new code for review

More important than task-specific feedback is career-related feedback. Smart people want to know what they can do to grow professionally. Your role as a manager is to help facilitate this by continuously giving them feedback based on what you see. To do this, Julie Zhao from The Making of a Manager suggests spending one 1-1 every two months on growth and behavioural feedback.

Own your decisions and don’t sugar-coat

When you give feedback or make a decision, your report may not agree with you. It’s important to listen to their side of the story, but in the end, you have to own the decision. As long as you think you have the best interest of all parties in mind, be transparent, honest, and direct. In the future, your report will thank you for it.

It’s brutally hard to tell people when they are screwing up. You don’t want to hurt anyone’s feelings; that’s because you’re not a sadist. You don’t want that person or the rest of the team to think you’re a jerk. Plus, you’ve been taught ‘if you don’t have something nice to say, don’t say anything at all‘. Now all of a sudden, it’s your job to say it. You’ve got to undo a lifetime of learning.

Kim Scott (Radical Candor)

Focus on documentation, processes, and mentorship

These three concepts really helped me transition from an engineer to a manager, so I use them as pillars in my management philosophy.

Everything should be documented

When I was struggling between juggling coding and management, one of the decisions I made was to remove myself from engineering and replace my presence with documentation.
Every time someone would ask me a question, I would add a new entry to an FAQ page and publish it. Over time, people started asking me less and the documentation became a source of truth. People became unblocked and self-sufficient. Through this, I learned the value of good documentation.

Continuously improve processes

As my team grew, engineers came to me with common questions such as:

  • How do we ensure we are performing good code reviews?
  • How do I know if my code is written well?
  • Can I try <Framework-X> for my new project?

These aren’t questions that you can solve through documentation. You can’t write a guide explaining what code is messy and what code is clean. You can’t write blanket generalizations disallowing new frameworks. However, you can introduce processes to help resolve these issues.

For example, introducing processes such as code linting, type-checking and unit testing can ensure that code quality is maintained and improved. Adding processes decreases deployment speed, so be careful when considering what to introduce.

Provide opportunities for mentorship

Mentorship is the final piece of the puzzle. Once you have documentation and processes in place, your team will have the necessary tools to be productive. As they gain experience, they will become more confident. In turn, they will be able to mentor new engineers. This leads to a cycle of fulfillment and productivity where everyone feels involved and has ownership. Your role as a manager is to ensure standards are maintained and be there to remove roadblocks.

Always explain why

Being a former engineer, I have the benefit of putting myself in the shoes of the person who I am managing. When I am asked to build something, the question I always ask is “why”:

  • Why am I building this?
  • Why is it important?
  • Why aren’t we doing something else?
  • Why is <something> not being prioritized?

A manager should always emphasize the why. Every discussion follows from that. Answering the why provides motivation, scope, focus, and excitement.

“People don’t buy what you do, they buy why you do it.”

Simon Sinek (Start With Why)

Practice proactive management

A year into my management, a report came to me and gave me the news that he was moving on to another opportunity. At the time, I didn’t really know what to say. After all, I had never gone through that experience before. There were several seconds of complete silence as I gathered my thoughts. Naturally, a few things came into my mind:

  • I was a bad manager.
  • Why are they leaving? Is there anything that I can do to change this person’s mind?
  • Think through all the projects that would be affected.
  • This person oversees a lot of things and will be impossible to replace.

That experience taught me two important lessons:

  1. Manage proactively to lessen the impact of any departures in your team.
  2. People usually leave due to lack of growth, lack of autonomy, or lack of compensation. As a manager, you may not be able to control all of these factors, but you should be able to diagnose what the underlying issue is ahead of time and take steps to talk about it.

Rules of proactive management

  • Ensure all projects are documented. This involves the “what”, “why”, and “how”.
  • Ensure that no one is a gatekeeper of knowledge. Knowledge must be spread across the team and the broader organization.
  • Ensure that architectural decisions are written so they can be referred to in the future.

There are many aspects of management that I haven’t captured in this guide, but I feel they deserve their own sections. These involve:

  • What to look for when hiring
  • How to build remote teams
  • How to have effective meetings

Follow me on Twitter to be notified when I publish updates to this guide, or post new guides.

Lastly, there are other aspects of management which are completely new to me and I am not prepared to write about them at this time. They involve:

  • How does management change as your team grows to over 10 people?
  • How do you foster a team culture over the long term?

I recommend reading the following books as well. However, as my manager once told me, take the lessons from the books but you must determine your own management style that works for you. There is no one-size fits all.

Up Next:

Using Environment Variables on the Front-end with NextJS

Using Environment Variables on the Front-end with NextJS