Engineering leadership is a tough nut to crack. Even the greatest leaders admit it took them years to get good at it, and there’s no such thing as a perfect leader.
It’s especially hard when you’re getting into an engineering leader role after a successful run as an engineer. It’s a completely different role, and you have to do a lot to figure out what will make you good at it.
This post is here to help you.
We’ll go over the cornerstones of engineering leadership with Michael Lopp. Based on his many years of leadership experience from fast-growing tech companies, we’ll touch on challenges, solutions and habits you want to know to take your leadership skills to the next level.
I wrote my first book, Managing Humans, about the biggest challenge I’ve faced: transitioning from engineer into management and later leadership. I had to face the fact that the qualities that made me a good engineer weren’t going to make me a good leader. I didn’t have a great support system to guide me, so my situation was, “Figure it out, YOLO.”
The challenge was understanding what I should be doing and how to do it well to become an effective leader, when there wasn’t a tangible structure. I found the right people over time and learned things the hard way. The hardest part was relearning the skills I needed for success after having had a fairly successful career as an engineer.
Transitioning into management is a career restart, and I wasn’t prepared for that. No one tells you this when you get promoted to engineering manager. This was the first thing I needed to figure out without a strong community around me and with little support from my company.
Reading wasn’t helpful, because there weren’t many books about leadership. I focused on real experience by watching great leaders.
I looked for leaders I respected, and started watching how they worked. I looked closely at how they operate, especially when times are tense and people are freaking out. I wanted to learn the moves they use in these situations.
They’re doing simple things. It's the way they frame a sentence when there's tension in the room, and they need to defuse it. The way they encourage quiet folks.
I’m a collection of dozens of different leaders whom I looked at and thought, “The way you did this really speaks to me.”
The highest compliment I’ve ever received was, “I love watching you work. I like to see how you do things; that's how I'm learning.” You can say anything, but the important thing is how you're treating people and how you make decisions. I hope to show my values through my actions, which is the way I learned from others when I started out in engineering leadership.
I’ve heard this question a lot, and my answer has changed over the years. As I’m evolving, I consider different things as the most important. Currently, I'm an executive leader, rather than a frontline engineering manager, but this is what I wish I could have told to first-time manager Michael Lopp a million years ago:
It’s all about your ability to delegate, and it’s hard to do.
You get a big task, hand it to an engineer on your team, and you’re not doing the actual work. Maybe you slice it up into different tasks, and then give it to others. This is fundamentally tough for engineers, because we like building things ourselves.
Leaders don't get to do any of this work. Management is a ton of work, but you don’t do testing, don’t improve performance, don’t do anything that’s been your work as an engineer.
You need the ability to give up your toys and hand them to others to do the work. It sounds like you’re giving away everything, but you have plenty of work every day. The leader’s job isn't doing the work but building a group of talented engineers who get it done.
When the sky falls on new engineering managers, their reaction is, “I'll help to write code.” It’s the opposite of what they should do. They shouldn’t write code but figure out how to empower, teach, or coach others to get through the crisis.
I use it as a test for future leaders. It’s a good sign to see an engineering manager run a huge project without diving into coding.
Delegation is a powerful lesson for everyone to think about. It's about guiding and coaching others to get the work done as opposed to doing it yourself.
You need to understand that the act of delegation is work. Engineers tend to value tangible things, like the code they write, the features they build, and the bugs they fix. It's uncomfortable when they get into abstract leadership concepts of delegation and influence.
You have to learn that leadership is work, and there's value in it. When you’re managing humans, you can’t point out exactly what you did in a day. You may have had eight meetings, but you didn’t produce anything.
Here's the thing: you did a ton.
You helped your team understand something. You made a decision about another thing. You don't have a piece of code that you checked in, but you have to learn that your work is invaluable.
Being a good leader is situational. Different situations require different types of leaders.
There's a situation where you want a dictator driving everyone forward. It sounds horrible to me, but there are situations where it’s beneficial. In other situations, you want a great team builder, a human-focused leader.
You need to understand the situation and ask yourself, “What leadership style do I need now?”
Once you got that down, you should look through your teams and ask yourself:
These are my OKRs or goals; they help me measure my performance. Some of them are subjective; I often go by feeling. Others are objective, like shipping products or hitting metrics.
I share these with my team via the performance management process we use, but it’s still up to me to figure out what to focus on. Nine months later, I'll check back with my goals to see how well I predicted what I needed to do and how the team progressed. Some of my predictions will be wrong, but you can still check progress on the rest.
Your team will let you know how you're doing, and you have to listen to them. It could be your manager, your peers or the people on your team, but they’re telling you all the time.
Sometimes, there’s recency bias behind it, or people are mad because of one specific thing. Whatever you do, never take it personally. Sometimes you screw up, so you need to look at it holistically.
People tend to wait for performance management cycles for feedback, but it’s continuous. If you work for me, you're getting feedback all the time. You need a healthy feedback culture, limiting feedback to annual or bi-annual sessions is absurd.
Sometimes, you need to explicitly ask for feedback, and you need your team to be honest with you, which is an interesting test. Sometimes it's bad, or it gets political, but I need to understand what’s going on, so I learn how to change that perception.
One of the most important skills a manager needs to learn is reading the room. It's a poker term; I've written about this many times.
When you walk into a situation, you need to understand what's going on, who you’re dealing with, and what you know about them. It's exhausting. Especially in remote meetings over tools like Zoom that we must use because the COVID-19 situation is forcing us to work remotely.
You have to be aware of what's going on around you, because you depend on others to get things done. Someone could be mad at you, or refuse to engage you, and you need to handle that. Situational awareness is key, because groups of people work in complex ways, and you need to track the changes.
I’ve just written a book on this topic, called the The Art of Leadership. It's about leadership development through the small things I’m doing every day. I'm always working on something, always trying to improve a habit or a skill. You can never be a fully formed leader, just as you're never a fully formed human.
A key practice for me is to find something I’m bad at and get in the habit of fixing that shortcoming. It may be about communication, keeping track of things, or anything else.
I recently came back to task management, which I've worked on like 10 times. I've moved to an engineering leadership position in a new organization with its own culture, and there's so many things to do, and my current task management system won’t cut it. It needs to scale, so I’m working on figuring out how to do that.
It’s not only about task management, but it’s also about me being perceived as a reliable engineering leader. If you ask me to do something, and I agree to it, do you trust that it’s going to happen? This perception is a big deal; you want your boss and your peers to trust you to get things done.
Always learn; this is the short answer to the question.
It’ll be different for everyone, but I’ll share my practices.
I always have my notebook and a pen at hand. Anytime anybody says anything that sounds even remotely like a to-do, I write it down. Sometimes, it's a to-do item for me; other times, it's something I want to know.
I often fill a notebook in a day.
I use Slack a lot; I used to be VP of Engineering at Slack. I use the sidebar as a tracking system to keep DMs or projects there that I'm concerned about. It works as a reminder.
I'm also using “Things” for task tracking. I'm not sure if I’ll stick with it, but currently, it’s my personal set of things that don't fit in a channel.
I capture everything, and at the end of the day, I block off time to go through it all. A few hours later, I can put it into perspective along the lines of what are the things I must do, and what are the things I probably won’t get around to.
Even when something seems important in the moment, at the end of the day, it may turn out to be low priority and I need to drop it. I will still follow up, to let people know I’m not going to do that thing anymore.
The important part of an engineering leadership role is consistently listening, capturing the to-do items and the thoughts. Then going through it at the end of every day to clean up and screen-out whatever isn’t important.
I do this every single day.
It's easy to say, but it's hard to go through everything every day at 5pm. Sometimes I’m tired, but I need to get it done, because an engineering leader is in the nexus of many things. If I'm not perceived as reliable, then people start going around me and try to game the system.
You’re in a position of power as an engineering leader. Everyone knows that you're a leader, you have authority, and you have to respect the respect you get because of that. If you look unreliable, you make leadership at your company look unreliable; you don’t want that.
There are different approaches for different teams, but you need emotional intelligence and interpersonal skills. I currently work with many teams outside engineering, but I depend on them. My approach for this starts with building relationships; I call it bridge building.
These teams in different parts of the company have different goals than I do. I need to make sure they know that I want to work with them, I’m dependent on them, and they're dependent on me.
Building your influence starts with building credible professional relationships with the people around you. It sounds easy, but it's not. You have to do it a lot, it takes time, and you need to do different things with different people to build trust.
You want to have formative moments with teams in my situation where you all feel like, “We're all in this together.” You need a set of shared goals about what you want to do, and the feeling that you are one team, even if technically you aren’t. It’s a tricky relationship to build when you have different values or culture.
Bridge building is key, because when push comes to shove, you may have to ask something big from people outside your team. They don’t see it coming, and it’ll come down to a value judgement: “How much do I value this person?” If you have a good relationship with them, they’ll do their best to figure out how to get it done.
Even if they have to say no, they're going to say, “We’re sorry. We considered all the options, and we just can't do this.” You can always tell if there's respect in it, and if they really did their best to work out a solution.
My teams are always allowed to say no to me. It's about honesty, which is a powerful thing.
At the end of every one-on-one meeting, especially when I get started in a new team, I ask, “Do you have any feedback for me?” No one ever has given feedback to the VP of Engineering or Engineering Director in their first one-on-one or skip level meeting. They say, “No, I'm good. Thanks for asking.”
I keep asking every week, and they keep not giving me feedback. It usually takes a month until they realize that I'm not going to stop. Then they say something.
It could be a small feedback or a big one. The important thing for me is that they chose to do it, and they felt safe enough to tell me that I screwed something up. This is great, and I always thank them.
It's the same thing as saying no.
I tell them what I want to get done and why it’s important. If they say no, I say, “Cool, tell me why,” and they give me their reasons. To which I either say, “That makes complete sense. I retract my request,” or I say, “That's unreasonable; here's why,” and we have a debate. The no may turn to yes, or I may learn new information.
Saying "no" signals good communication. If they’re just jerks and do it because they don't like me, then I have failed as an engineering leader to build rapport around me. “No” signals truth coming your way from someone who knows the situation better.
Sometimes, it’s a drag when you really want something done and no one wants to do it. But when everyone says no, you need to understand the reasons behind it. When people say no to me, I think, “Great, we’re communicating like regular humans.”
Engineering management isn’t a higher power or a magical set of skills. It's just a different role with a different set of skills. There's more responsibility because you're growing the team, signing paychecks, and so on.
New engineering leaders and managers often get lost in the power of the role—I have done so in the past.
Another mistake I still keep making, but trying to improve on, is to think that what I'm saying is always clear.
I often say my three sentences, look around the room, and everyone’s silent. And I’m wondering why everyone isn’t getting what I'm saying. Usually, I phrased a couple of words in a confusing way, and no one got the message.
The mistake is thinking that because it’s clear in your mind, people will understand what you're saying. It’s one of the reasons I always ask, “Does that make sense?” If I sense confusion, I ask, “Can you repeat what you’ve just heard from me?”
Another common mistake is waiting for the least opportune time to give critical feedback. It’s typical for new engineering managers, because it's hard for them to tell a team member that they’re doing something wrong. It’s hard to do, so people tend to wait until they're forced to say it, like at performance reviews, when compensation and promotions are discussed.
That's the worst time to save it for, because people aren’t thinking about the feedback; they're thinking about the dollars. They're caught up in the consequences of your feedback. It may be the first time they hear they’re doing something wrong, and they'll think, “Why haven’t I heard of this all year?”
Holding back on critical feedback until you're forced to give it is a huge mistake and a great way to erode trust on your team. Your team members will be waiting for the Grim Reaper to show up every six months to tell them how they’re doing. It’s terrible for everyone.
If building my personal brand allows me to do my job better; I'll do it.
I run the Rands’ leadership Slack community with 13,000 members. It does a lot for building my personal brand, but that isn’t the point.
The point is to get leaders together and provide them with a safe place to teach each other. There are thousands of channels in there, so I often play a game, where I think up a topic that interests me, like AWS bills, and search for it in the community. I end up finding three AWS channels with hundreds of people discussing the question I had.
Throughout my career, I’ve picked notable companies: Apple, Slack, Pinterest, Palantir, Netscape, even Borland. One might think I was picking companies for their brand names, but that's not how I viewed them at the time.
They’re interesting, impactful companies that had either done something exceptional or were going to. I knew when I went into them that I would learn a ton. There was always something exciting, like growing an engineering organization quickly.
The first time I came to Apple, I learned a lot of what I needed to understand about design as an engineer. It may sound selfish, but these learning opportunities attracted me.
This may be viewed as building my personal brand as an engineering leader, but in my head, it was never a deliberate branding exercise.
This is an obvious thing, but most people don’t do this when they’re overwhelmed. Everyone thinks a leader is supposed to know what's going on and have a plan. But it’s easy to feel like there’s too much to do, and you have no clue how to prioritize everything.
When you’re there, ask for help in any direction. You can go to your boss, your peers, or your team. It's a powerful moment when you go to your team and say, “I'm overwhelmed. I don't know how to get this all done. Could you help me think it through?”
I did this just the other day. I said to a brand-new manager, “I can’t figure out how to frame this program. Do you mind if I walk you through it, and tell me what you think?” He's never done anything like this before, but I got a lot out of it.
He pointed out things that were overly complicated, and I said, “You're right. Why would I do that?” He was wondering why I asked him; my reason was that I wanted a different perspective. I needed help, and he helped a lot.
Relationship building is also essential. Asking for help and realizing that you're not alone is a key part of this. A diverse set of eyes can help you out, and people love helping each other out.
It lowers your status to ask your peers or your team for help, because it shows them you’re a regular human being who gets overwhelmed like everybody else. But it’s also a humanizing moment that builds trust. When I'm overwhelmed, I go to someone I trust and say, “Can you help me? I'm lost.”
The obvious thing is to start delegating.
New managers know how to do the tasks their team has, so they default to taking the tasks and doing them. As a manager or leader, you shouldn’t do them; delegate them instead.
When you give a project to your report, you need to give them the ability to do it their own way and not be too prescriptive about the process. You know how to do it right because you've done it before. You could give them a detailed checklist to follow. In some critical situations, you may do that, but ideally you want them to learn for themselves.
You need them to learn the lessons you’ve learned from doing the same tasks before. You should give them space to think on their own, because they may find a better way than yours. If you tell them what to do every step of the way, you stomp their ability to learn.
The question is, “How much room am I going to give them to work on this?”
You don’t have to be hands-off. You want to keep track of what's going on, guide them, and stop them before something blows up. You need to figure out how to give them space to work, allow them to be successful, and let them learn as they're moving forward at the same time.
If you tell me up front how everything is going to go, I won’t believe you 100%. After I fail, I will realize that you were right. You can learn while being successful, but everyone has to go through the critical learning cycle, and that’s more than reading from the script your boss handed to you.
You need to accept that early on, your team members may not do their tasks as well as you could. But remember, just making it work for the first time for a big project is a great result. They will learn, and seeing you delegate tasks builds trust.
Self-awareness is a critical element to becoming a leader. You have to know what you're good at and where you need to grow. Whoever you are, you have strengths and you have weaknesses.
We don't like to talk about our weaknesses, because we’re embarrassed that we’re not as good as we’d like to be. But when I'm doing interviews, I'm looking for self-awareness. No one's perfect, but the ability to know your strengths and weaknesses is an advantage.
Using your strengths and hiring or delegating for your weaknesses is a great strategy. Overvaluing your ability to improve your weaknesses, and blowing up important tasks along the way because of this, won’t take you far.
Being honest with yourself about who you are and what your abilities are is important. You can often hear horrible things from leaders like, “I'm the boss, so what I'm saying is the law.” A leadership position is about leveling up others, so they can learn and the organization can do things at scale.
You want to invest in improving both your strengths and your weaknesses.
I have managers who are great at doing X, but it’s boring for them. I always tell them to keep doing it, since they’re so good at it.
I had a manager at a previous job running a project that was adrift. I knew running that project wasn’t a stretch for her, because I’ve seen her do similar projects before, but she signed up for it. My thought was, “This year-long project is off my shoulders, because I trust this person to do it right.”
This was the right thing to do, because she was amazing at running this type of project. Her next project was more difficult, where she got to learn more.
You always want to balance using your strengths and improving your weaknesses.
Rands returned to Level-up Engineering Stories to tell leadership stories!
Michael’s passion is engineering leadership. When he became an engineering manager at Netscape, he couldn’t find useful literature for engineers to develop leadership skills. This is why he started talking to other leaders. He wrote down the ideas he found and turned them into a blog.
Some people consider him famous or “valley famous,” but he thinks of himself as just a guy who writes about engineering leadership and has been recognized for it. He’s built a leadership Slack community over the past 5 years. He enjoys the collective learning aspect and helping others develop.
He has worked as VP of Engineering at Slack, Head of Engineering at Pinterest, and occupied engineering leadership positions at other notable companies.
At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.
Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀