I just hit 20 years in my career as an engineer and a manager of engineers. I like to think I’ve been able to keep a pretty good perspective on both roles. I’ve done the pendulum swing a couple of times, and I’ve even been an engineer and a manager at the same company multiple times. I enjoy both roles for very different reasons.
I talk to friends and colleagues often about the tension between engineer and manager. I’m able to put on multiple hats and try to bridge gaps. Engineers often find themselves at odds with their managers. Sometimes for good reason. But in my experience, there’s often a healthy dose of mismatched expectations as well. It’s not easy for managers to give people a clear and direct understanding of what those expectations are. In a recent conversation, I tried to put on my manager hat and do that.
This is gonna sound like a humble brag, but bear with me. During one of my stints going back to being an engineer, managers kept using me as an example of how to do good things. This is despite the fact that I wasn’t on a very visible or important project. Engineers would come and ask me what I was doing in order to get recognized. I ended up generating this informal list of things that managers expect from engineers:
Give effective status updates. Learn better ways to communicate about your project so people understand what's going on.
Tailor updates for your audience. There are good project updates and bad ones. Learn what details are important to put in them. Learn what to leave out unless they ask.
Give timely updates. You don't need to give updates every day. But definitely don't go a week without communicating.
Stay ahead of problems. You can learn to anticipate what might go wrong on your project. You may not entirely avoid it, but it can inform your estimates.
Give trustworthy estimates. If your estimates change all the time, people aren't going to trust them. Find out why you keep sliding and learn to stay ahead of those things.
Learn what the true scope of the project needs to be. Back away from "story points" and understand what the project needs to accomplish. More context about the goals will help you negotiate what's in and what's out of scope.
Understand business timelines. Find out how long stakeholders expect your project to take. It's not the same as whatever estimate you gave.
Help your team improve. If you're leading a team, learn to recognize when they're not progressing because they don't have the skills. Your team won't always ask for help explicitly.
Teach other engineers how to do things. Don't just do it yourself because it's "faster". Give other engineers explicit permission to take more time so they can learn something important for their growth. Account for this extra time in your estimates.
Collaborate on designs. Designs never have the level of detail that matters. When you run into UX problems, work with people to develop a solution. Don't just ask for more mocks. Own the details of what you're building.
Bring good judgment to technical recommendations. Learn what's reasonable and what's not in terms of system capabilities. If an API call takes 10 seconds, that should probably be fixed. If the requirements call for loading a million rows into a web browser, that's probably not feasible.
Fix bugs that frustrate other teams. Don't wait for them to get prioritized. If a bug is stressing out your support team, just go fix it. Then take credit for fixing it.
Talk to customers. Especially about issues that have been outstanding for a while. Find an opportunity to talk directly to a customer and find out what the problem is. The real problem often gets lost in translation.
Learn the business. Pay attention at all-hands and other big meetings about strategy. It impacts your work. Don't wait for someone else to explain it to you.
Learn the strategy. Ask people about strategic goals and actively draw a connection to your own work
Don’t just write code. Solve problems. Make sure you understand the value of your work and you talk to people about that. Not just "features". For example, “this needs to ship by Fall because it's our big strategic bet for the year.” Tell people how to achieve the strategic goal.
This is not an exhaustive list, but when I shared it with people, there was a lot of vigorous head nodding. Engineers who do the above are also usually the people everybody loves to work with. These are the folks who get not just shoutouts, but promotions and raises as well. Most of these things are separate from developing more technical skills. I believe engineers at any level can see success by focusing on these things. Not just “senior” people. These are the skills and behaviors that help you create impact, and more importantly, get credit for it.
At the same time, I want to acknowledge that this list may seem daunting to some people. Especially engineers who are earlier in their career. This shouldn’t be seen as a checklist that you have to achieve immediately. It took me almost 20 years of experience to learn these behaviors. My goal here is to lay them out explicitly so you can at least be thinking about it, and potentially match it up with feedback you receive from managers or elsewhere. If nothing else, I hope this post serves as a helpful reference to remind people over time.
Before I take off my manager hat, I also want to talk about the flip side of this coin though. Even when I talked to people about this as a peer engineer and not a manager, I got all kinds of reasons why people can’t or won’t take this advice. I want to share some of these as well. This is not to criticize or shame anyone. But I’d like to be part of pushing for more honest evaluations of why people might struggle to do better. Here are some of the responses I’ve gotten:
"I'm not sure how to do that". They need to build skills and haven't found a way to level themselves up. Each of the bullets above could probably be a blog post with more details.
"I thought I was doing that". Some people aren’t great at evaluating themselves or getting feedback reflected back at them.
"I can't do it because X". A lot of passing the buck. Bad project managers, too many conflicting messages from leadership, etc.
"I tried to tell people, but they're not listening". Having trouble creating the right relationships with other people.
"I'm too busy with meetings and stuff". Not feeling in control of their own time.
"This won't get done unless I do it myself". Biting off big pieces of technical work for themselves because it's more fun. Or they don't trust their coworkers.
"I've got too many other things I'm responsible for". Overwhelmed by too many priorities. Having trouble context switching.
"I don't think that's important". Hubris and a poor understanding of what matters to other people.
"That's somebody else's job". Poor understanding of what it means to become a linchpin.
In each of these cases, my goal as a manager is to support people in working through the barriers they’re experiencing so that I can eventually see the behaviors I want to see. As an engineer, I have appreciated those managers who remind me of what’s expected while not being overbearing about it. I still have this fanciful notion that engineers and managers can build trust and help each other be more successful together. I plan to keep sharing what I’ve learned from both roles and doing my best to bridge that gap.