I’ve been an engineer for a long time and in multiple capacities.

First I was a desktop engineer, which was a mostly reactive job requiring me to remedy issues that my end users were having so they could get back to work.

Then I transitioned to being a virtualization engineer, where I was in charge of building out our multi-datacenter production environment. I needed lots of heads down time to configure and troubleshoot applications and infrastructure that we were building.

Then I started working as a Sales Engineer for a tech company, where I spent a lot of time in meetings with customers, but I also needed tons of heads down time to focus on building out Proof Of Concepts or learning more about the platform that I was selling.

Finally my career took a turn to Tech Marketing. This is a highly technical role that requires you to be a subject matter expert on the product you cover while also taking large chunks of time to build out labs, test features, write blog posts, or create demos/videos/interactive experiences.

I thought it was important to give a little background of my experience before diving into the main content of this post: How do you manage an engineer?

This post is not written from the perspective of management, but rather from the perspective of the Individual Contributor. It’s entirely based off of my experiences throughout my career, being in good management environments and bad.

In my experience, and from what I’ve seen with peers throughout the years, engineers need a few key areas of support from their management:

  1. Career and Self Development
  2. Air Cover
  3. Project Prioritization
  4. Project Support

Career and Self Development

Your number one goal when being a manager is to ensure that your team members have the support they need to move where they want in their careers and in their personal lives (to the extent they share with you). Many managers rely on Human Resources or People Development to take care of these tasks, when in fact they should have a vested interest in helping the employee develop. When I look back at the roles where I’ve been the most productive and happy, it was when I was a TME at Nutanix.

My management team at Nutanix had a vested interest in their team members, wanted them to succeed and to grow in the ways the team member wanted, while providing ample opportunities to make that happen. They knew that people don’t stay forever and supported them in leaving when someone grew out of a role or found other interests.

Often managers hyper focus on the deliverables, status updates on projects, or any number of other things that aren’t as important. If your team member doesn’t feel like you care about their growth in their career, if they feel like you aren’t working with them to achieve those goals, if they see that all you are concerned with is moving projects forward - you’ve got someone that’s going to run straight towards burnout or someone that will be sending a LinkedIn message to their recruiter.

1:1’s are not a place for status updates or task prioritization. Let me say that again: 1:1’s are not a place for status updates or task prioritization.

You should ensure that you have bi-weekly 1:1’s with your employees that are focused on Career and Self Development. Your 1:1’s should be lead by your team member, allowing them to choose the topics that are important to them. If you feel that you need to bring something to the table, put it in the Meeting Notes ahead of time. When I attend my 1:1’s I usually have a list of a few things I want to focus on for the 45 minute call. I often want to discuss my career path inside (or outside) the organization and provide a health check on how I’m feeling in my role. Am I feeling supported? Am I getting the tools that I need? Am I in need of some time away? Prioritize these 1:1’s over everything else. They should be at a time that is convenient for your team member, not just slotted in some opening you had. They should be recurring and rarely cancelled.

If you give your team member this space to develop and say what’s on their mind, they’re more likely to be happier in their job, more productive, and stay longer. But they most likely won’t stay forever. Because if they’re given the space to grow and follow their interests, they’ll eventually find something that excites them more. And that is okay. Your team member should never feel like they can’t tell you that they’re considering moving on. If they feel like they can’t tell you, you’re the problem, not them.

Note: It’s important to realize a lot of engineers will prefer to handle harder conversations through written and asynchronous communications. Itterating on ideas and feelings is common and we often don’t express ourselves in the moment well. I’m one of these people. You should give space and accomodation for this. There’s a psychological reason for this for a lot of us, that I could write 2000 words on, so I’ll save that for another time.

Air Cover

As a Senior/Principal level engineer I know how to get my job done and what is technically important. I’m very good at my job, when I’m given the space to do it.

Let’s look at the role that I’m in now. I’m a Senior TME, where I am currently covering one product, and specifically the implementation of that product with a partner vendor. I have mountains of deliverables due in just 6 days, but I’m here writing this post instead. Why? Burnout and frustration, a lack of support, and a complete disinterest in doing what the job has turned into.

How have I gotten here? A lack of air cover.

Air cover can be broken down into a four key areas, which I’ll dive into below.

Air_Cover[‘Shelter from meetings’]

Engineers rarely find a meeting productive. If we’re not committing code or moving a task to the Done column in Trello, we don’t feel productive.

Engineers should never be in meetings that are status updates or product updates. Status updates on projects should be provided through a commonly agreed upon tool and you as the manager are responsible for disseminating that information to various stakeholders. The closer to a project deadline you are, the more important it is that engineers are not in these meetings.

Product Updates should almost always be provided in written form, or be made available via video for review when the team member has time for it. This is not a reason to schedule another meeting.

Most engineers should not be in meetings that are strategic planning in nature. I say “most” here, because Principal, Staff, and Team Lead Engineers should spend some of their time providing technical input into strategy of the product that they work on, but that time spent should be largely determined by them.

Engineers are expensive, why waste their time on administrative tasks that can easily solved?

Air_Cover[‘Space’]

Engineering is an interesting skillset, which tends to attract people with minds that work in a similar way - most of us need long, uninterrupted time to produce quality work. There have been tons of studies about what context switching does for an engineer, but I’ll share my experience because I’m intimately familiar with how my brain works.

First, I have ADHD. I have gone undiagnosed until about 6 weeks ago. So my experience is slowly changing here, but this is definitely not an uncommon story in engineering.

If I wake up and look at my calendar to find that I have more than 2 meetings on my calendar, no matter the duration, I can basically write off the possibility of any productive work being done for that day. Why? Context. Most engineering, creative, problem solving work requires building context in your brain for the task at hand. Often I’m working with complex architectures, with various machines and pieces of code communicating, while also trying to remember snippets of code or IP Addresses.

If I’ve spent an hour working on a task, I’ve got a pretty solid context built up and I become way more productive as the context improves and time goes on. If I have to step away from the task to take a 30 minute call a few things happen:

  • I lose the context I had built up in my head
  • I lose the way I’m thinking about the task (double edged sword here)
  • I will be thinking about the task I was working on, during the meeting (so what’s the point?)
  • I lose the following hour to re-building the context in my head

So for a 30 minute call, which most likely could have been asynchronous, I’ve now lost 90 minutes of time that would have been extremely productive. For an hour call, I would lose 120 minutes of productive time at a minimum. If the call is stressful in any way, it gets worse.

It’s important that you, as the manager, give me the air cover and the space to feel good saying no to these meetings and know that you will speak in my stead. It’s also important that you fight to batch meetings as much as possible. It’s often very difficult for engineers to push back and ask a call of multiple people to reschedule to a specific day/time and create a meeting day. It is up to leadership to create a culture that enables people to have long uninterrupted time for work to get done.

Everyone has a part of their day that is more productive than another, for instance, I find that I write some of the best code very late at night: 10p-2a. But I’m not going to be willing to do that often for work if I’m also working a full 9-5. I also have a very productive 10a-12p, largely for creative work, it’s when my medication is at it’s peak and my brain is excited. Giving me the space and air cover to choose what work gets done when, will make me a more productive engineer.

I fight to arrange my days in a way that is suitable for me, but in an organization that has a cultural issue with being able to do this, it makes managing my work time a chore. When my job becomes a chore, my LinkedIn app gets twitchy.

In order to be a truly successful engineer, I’ve found it’s also important that we have time to learn, to grow, to make mistakes, to try weird ideas, and to explore things that are interesting to us in the moment.

Our brains crave interesting and creative things, so when we don’t find it in the task at hand, sometimes we need to go feed that need elsewhere, so we can come back to the task at hand and work on it with a fresh and happy mind. It’s why I have so many personal projects that almost never get finished, I explore them to fill an intellectual curiosity and interest long enough to satisfy that need, then I return to what needs to get done.

We should have this space at work and not just explore these things in our personal time. Honestly, this is why I have such a problem with the Home Lab concept. It’s important, for sure, but if you’re not being provided the time at work to explore and try things, then all you do is spend time in front of a screen.

Air_Cover[‘Help’]

If an engineer ever asks for specific help, make it happen. Full stop. If they ask for it multiple times, there’s a real problem. If you are unable to provide this help, or the organization is unwilling, don’t just let time lapse and leave your employee waiting. Be upfront and tell them the situation. Don’t give them false hope that help is on the way, if it’s not.

Air_Cover[‘Tools’]

There should never be a single instance where engineers should not have the tools they need to get the job done. Be it a powerful enough laptop so they don’t spend 8+ hours rendering a video they’re working on, multiple displays, a good chair, or lab gear to ensure that certain things work. Fight for the budget if you have to, but never leave an engineer sitting there without the tools to get their job done. Thankfully, my current role is very good at this, but my last role fought me over needing a $2500 laptop instead of the 3 year old, used, underpowered one they gave me that was basically useless.

Project Prioritization

I expect that my leadership is able to prioritize the projects that are assigned to our team, then inform the team members what the expectations are from above. Leave space for the team to do their own prioritization at a lower level (tasks), but it’s up to you to set the long term direction for the team. The more senior your team, the less you should need to do this. But the greater expectation is that you would be able to provide feedback on what upper level leadership expects, otherwise engineers will focus on what is more intellectually interesting to them - or - try to guess what upper level leadership wants.

You need to also manage up for your team, ensuring that upper level management understand the feasibility of completing the projects that they’ve assigned, in the timelines they’ve requested. That could mean pushing to re-assess delivery schedules, feature payloads, staffing levels, and tooling.

Project Support

You need to ensure that your team members have the project management they need to move things forward. Speaking for myself, I am not a project manager. I’m able to see the big picture, understand market fit and need, and roughly who all the stakeholders are - but I will never be good at chasing down updates from multiple departments, ensuring that tasks are being completed by multiple people in the proper order, tracking dependencies between orgs and teams, or keeping track of multiple delivery deadlines. This is a skillset that I don’t have, have no interest in, and I would imagine that a large percentage of engineers feel the same way. Ensure that your team has access to proper Project Management and Product Management to make them as productive as possible.

In Conclusion

Being an engineering manager is hard, but understanding what your employees need and then getting them what they need is the job. It’s the entire job. Engineers want to be productive, they want to produce content|code|products|documentation, and they’re very good at doing that - when they have the support.

Engineers command high salaries in our industry, it’s a shame that so much of that person power and money is wasted on things unrelated to what our primary skillsets are. Work with your team members to find what they need, what you could do differently, and what the organization could do differently.

<3