How to improve your engineering management skills

How to improve your engineering management skills

You might have studied the basics of engineering from a textbook or viewed a series tutorials to learn more.

Management engineers is a complex task that is not easy to master.

My experience has shown that learning is best done by listening to the collective wisdom of people who have managed engineering teams.

This is why Ian Nowland from Datadog was so kind to speak with me.

Ian has 20 years experience in the engineering industry, 10 of them in management roles. He developed a unique approach to engineering management that is encapsulated into seven categories.

These seven categories of engineering management were based on his 10 years of software-engineering experience. They are intended to help managers direct, motivate, and retain their employees and maintain a positive company culture.

Ian’s framework includes taking the ego out mistakes, developing a learning mindset toward management and building social capital among teams.

This is what we’ll be discussing below.

The 7 Categories of Engineering Management

When it comes to managing people, the three P’s are often used: 1) People; 2) Process and 3) Product.

Ian thinks that this is limiting, especially when it comes to engineering management. It doesn’t take into account the entire range of engineering activities.

Ian thinks it’s better to look at the following:

  1. People: Are you happy with what’s being built and are you growing?
  2. Engineering: How are things built? This article focuses on the processes your engineers use to get things done, and how they work. For example, how efficient is a code-review process.
  3. Product: Are customers happy with what’s being constructed? Ian refers to this category also as “portfolio managing.” This involves communicating with engineering teams about their roadmaps, the milestones they intend to reach in each quarter, and the story they want to tell through their work.
  4. Partners Do your partners fully understand and agree to the above? Healthy relationships are vital between employees and all affiliated groups within the company.
  5. Execution How are things being built? Managers need to consider what needs to be done and how to organize their teams to achieve annual milestones.
  6. Operation: Does your product/org have a future? Software engineering projects are only as successful as their operational processes. Managers must ensure that these processes are efficient and effective.
  7. Company – Does your company match all of these answers? Every engineering manager is responsible for promoting the company’s culture. Managers’ actions and inactions will set the example for their direct reports and teams.

The “Missing” Approach to Managing Engineers

Ian believes that engineers are a complex task to manage. There are many chances for making mistakes. They can and will happen. Ian has found that mistakes, or “misses”, are the best way to learn.

An “miss” is when something goes wrong that could have been avoided. Here’s the key: A miss is not a mistake. It’s a learning moment.

It is a subtle shift in mindset. Instead of dwelling on the error (which can be detrimental to an individual’s ego), see it as an opportunity to grow.

It becomes much easier to understand if you think in terms of missed opportunities. It’s like saying, “That’s okay, it’ll happen next time.” Ian found that this was especially useful for perfectionists (and I can attest to it).

A Miss to Build Social Capital (AKA Get what You Want)

Ian gave a wonderful example to show what he was talking.

Let’s get specific. Here’s an example of a misstep I made in my previous job dealing with company partners.

I was the manager of a software team responsible for a network device. The previous manager had decided to use another vendor. The network team said We’re out. There was friction between the two teams. It was obvious that this group of software engineers were out of control by the time I began working with them.

I asked the woman in charge of the network device team if she would let us turn it over to her team. Software engineers are not allowed to run networking devices. We were using our vendor, and her team was very busy, so she refused to agree.

In a previous stage of my career, I would feel frustrated and have given up. But my past failures (and seven categories!) have taught me to look at the bigger picture. I have learned to see the larger picture from past mistakes (and the seven categories!) She is well-intentioned in this instance and does her best.

Because I believe it is important to build good relationships between team members, this is what I concentrated on. One time, one of my engineers even offered to help her with a project related to software. This was to build goodwill.

A year later, she approached me again to inquire about taking over the network device. I was again able to get an answer.

What happened? It was a matter of trust. We had taken the opportunity to show her we care about the company (by helping out), and so we had the social capital to receive a positive answer when we asked.

Ian shares his lessons learned from others. Listen in at 11.50 to hear Ian talk about his miss in execution and how it helped him recover from a disastrous project.

Is it effective? How to Measure Success

Ian does not believe that there is a universal measurement of impact. It will vary depending on the situation.

Michael Lopp, an engineering leader, has written about management using “mechanics and organics.” Ian tends toward being “organic,” which is essentially intuition driven.

Ian is responsible for managing many managers in his current position. He focuses on whether managers spot potential missed opportunities early, before they become a surprise.

Your job is to manage many people and delegate effectively. How many surprises are there? This is an indicator that everyone is in control of their responsibilities. If there are few surprises you can assume things are moving along well.

Different standards are useful when measuring delivery goals and operations. Objectives and key results (OKRs), for example, are more useful the higher you climb on an organizational chart. Ian asks managers to answer the following question when evaluating them: Did they achieve what they set out? If it didn’t, why wasn’t it as planned?

Ian says that you would not expect team leaders to be concerned about OKRs. A team leader should be more concerned about measuring scrum.

Surveys can help to uncover sentiment. Ian does not find engagement surveys useful for determining a team’s happiness and its impact.

One-on-one meetings should be fluid and unique

One-on-one meetings between managers, employees and supervisors are often discussed. It is an essential interaction in any coaching relationship. However, a one-on-one approach to coaching is not always the best.

Keep in mind that these meetings are not meant to be one-size fits all. Engineers should not be presented with a generic solution to every problem in one-on-one meetings. Sometimes, you may need to be an advisor, listener, coach, or coach. Best is a fluid, authentic approach.

Ian recommends that managers ask open-ended questions in order to guide these discussions. He might say, “Hey, somebody else has this opinion on something you are doing or aren’t doing, what do they think?”

It allows you to have a conversation with them so they don’t feel like you’re trying to trap or attack them. It helps them to see things from a different perspective, and it also allows them to gain a better understanding of their work situation.

How to Avoid Burnout among Engineers and Managers

Many engineers burn out in their 20s. It took Ian a long time. Ian realized his work load was not sustainable when he was in the middle of his career.

He was taking on too many tasks and was so obsessed with perfection that he wouldn’t or couldn’t delegate this work to others. He was working too hard for far too long. He felt powerless. Ian went from being enthusiastic and motivated to feeling unmotivated.

Ian eventually realized that he needed to slow down and find a way to stop being so overworked. He was actually burned out.

Managers should first try to delegate as much as possible in order to avoid burnout. This will allow you to spend more time on avoiding missed opportunities.

Delegation is a way for people to grow. You want your direct reports to be able to make mistakes so they can avoid them next time. This article was based on which is an episode of Dev Interrupted . It features expert guests from all over the globe to discuss strategy and other day-to-day topics, including dev team metrics and accelerating delivery.

Leave a Reply

Your email address will not be published.