Overcoming Some Challenges Engineering Managers Face

Transcript

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Ahmed Wasfy. Ahmed is a coach and supporting engineers, the thriving EM, supporting engineering managers. Ahmed, welcome. Thanks for taking the time to talk to us.

Ahmad Wafsy: Thanks for having me. I'm excited to be on the show.

Shane Hastie: A useful place to start, tell me a little bit of your background and what brought you to coaching engineering managers.

Introductions [00:35]

Ahmad Wafsy: Like a lot of engineering managers out there I started as an engineer myself, as an individual contributor. I've written software for everything from healthcare to gaming to productivity suites to cloud, and I've been fortunate enough to do that at some of the largest companies in the tech space today. I was even more fortunate to make the transition into managing people. And that's when I realized that almost our entire career as software engineers and ICs, we focus on technical skills. We don't really touch any of the skills required to be a good leader or a good manager. And that's when I decided, after having to go through that journey myself with the help of a lot of mentors and coaches along the way, I wanted to pay that back and I wanted to help the next generation of leaders to save years off their learning trajectory. So that's when I started at Thriving EM. I'm still an engineering leader by day, so I do that in my day job, but on the side I like to help engineering managers thrive.

Shane Hastie: What are the most common challenges that you see engineering managers who come and work with you? What are the things that they're struggling with?

Management has longer feedback loops [01:44]

Ahmad Wafsy: I typically work with managers in the first few years of their journey into management. And there are really three recurring themes that I see that come up a lot. The first one is this idea of feedback loops. As an individual contributor, as an IC, as a software engineer, you really have a very short feedback loop to know that you're doing a good job or you're doing your job well. You've got things like code reviews or code requests or what have you. You hopefully have some metrics, some instrumentation. When you push your code to production, you could actually see how well it's doing. You've got some performance benchmarks, sometimes even have some business metrics. And all of those are different ways to gather signals and get feedback to know that you're on the right track, you're doing a good job.

I think once you make the transition to managing people, your feedback loops by definition are much, much longer. You're responsible for growing individuals, developing them, you're responsible for delivering projects, things that often take months if not years to be done to completion end to end. And often new managers have a hard time with that. There isn't that tighter feedback cycle where you know for a fact what you're doing is right or you're on the right path, or you could course correct halfway through.

That's one of the biggest problems that I struggled with myself when I made that transition. And often what I tell people I work with is a couple of things. The first one is this idea of don't just rely on first order consequences of things. You got to look at second and third and nth order. And that's really where the big impact and the big results come from.

Perfect analogy, working out. You go to the gym. Day one, you're going to feel sore, you're going to feel bad about it. But if you stop there, if that's your only signal and you stop, you didn't get the benefit. But obviously if you do it for a longer period of time, you start to see better results. And a lot of the things in life that are worth doing are out of that nature. So I find kind of a reframe looking at management from that lens, just improve you as a manager, but also other aspects of your life improve with it. But at the same time, you do need to get feedback from the environment, from the people around you, from the surroundings. So we work on the proxies for those signals, things you could detect and measure in the short term to be able to iterate and improve and become a better leader. That's the first common that I see a lot.

Becoming a manager can feel overwhelming [04:04]

Another one is how overwhelmed people become once they transition to a manager. You're suddenly going from typical maker schedule where you don't really have that many meetings in your day or in your week, to running around from meeting to meeting pretty much all day. As one of my mentors affectionately put it, he told me I was like a deer stuck in headlights the first couple of months of my management career, until you get a better handle on that. I'd say there are very simple but effective strategies to use to get a better handle on your calendar and your time and how you manage emails, how you structure your weeks essentially for maximum productivity.

And then the last one is this, understanding that it's a completely different job that you're starting from scratch. It's not really a promotion. And approaching it from that way, approaching it with a beginner's mindset helps you focus on the key soft skills that you need to learn and develop and get better at to actually become an effective manager. A lot of the engineers that get into management, they often have the right intentions, they want to do the right thing. They want to help their team and their people grow, they want to help the businesses they work for, but understanding what's at stake and how much work is ahead of you is also an important one before you make that transition.

Shane Hastie: Let's delve into some of these. The overwhelm. I've certainly seen it and I can honestly say I've experienced it. Your day is suddenly full of meetings, you're responsible for a wide variety of different communications. You're having conversations that you never had before about strategy and vision and product roadmaps perhaps. How do you break that down to a manageable level?

Ahmad Wafsy: I wish there was an easy answer. I wish there was a flow chart or a checklist that you could just follow and that would work every time. Obviously it depends on a particular situation and where you are. But there's some general principles that I found that apply broadly in most organizations. I'll share some of those now, and folks need more details or more help with the implementation, please reach out to me, more than happy to walk you through it in depth.

I think it really starts by setting the right expectations with your leadership, with your manager and your leadership team, because oftentimes we put way more pressure on ourselves than is actually expected of us. You'd be surprised by how a simple discussion to make things explicit can alleviate a lot of that pressure right off the bat. You may think that you need to be doing a million different things when in reality, really it's a handful of things that you need to focus on and that's what's being asked of you really. So setting clear expectations is the first one.

Managing yourself is key [06:39]

And then I talk about one of the three pillars in my coaching is managing yourself. And really it's about a set of really building the foundations, the fundamentals, where we start by managing your calendar, your email, and your to dos effectively. Prior to these three, what I call the fundees, the fundamentals of sleeping well, eating well, and moving. I'm not going to go into a lot of depth there, but generally sleeping seven, eight hours a night, eating generally healthy, organic food, mostly plants, and some protein in there, and generally moving some sort of exercise in a regular cadence that just keeps you healthier and more effective over the long-term. And consistency is really important here as well because these things compound over time.

And then to some of the more tactical stuff when it comes to a calendar for example, it's something that surprises me a lot, but really it's your calendar, it's your time. As a manager, as a leader, you've got control over 70, 80% of that. Yeah, sometimes you can't really control other meetings, especially if they're coming from a couple of levels above you, but 70, 80% of your week it's really on you to control and to schedule. So structuring your weeks effectively, making sure, for example, I'm a big proponent of having focus blocks in your week where you need to do deep work. The entire week is not just going to be meeting with people. You have to do a lot of work as a maker or as an IC yourself. Doesn't mean coding sometimes it could be anything, product strategies, vision, roadmaps, could be career growth plans, et cetera. You need the time, so set aside that time, those focus blocks in your week. That's the first principle when it comes to managing your calendar.

Another important one is making sure you have breaks throughout the week and throughout your day. I've worked through a lot of days where I'd come to the end of the day at 6:00 PM or so and be like, I haven't had lunch yet, and it would just be an afterthought for me. Block your lunches. Block coffee breaks. These things are not just important for your own energy levels throughout the day to make you... They actually do make you a better leader. There is a lot of research that shows as our blood sugar level drops throughout the day, we make worse and worse decisions. So doing those, you're not just helping yourself, you're actually helping your team as well, so scheduling those and being very intentional about them.   The third principle I'll mention here is this idea of managing your energy, not just managing your time. For instance, it's a lot easier to have a block of three or four one-on-ones in a row compared to a one-on-one here, a product meeting there, an operational thing. It's just that context switching actually really drains your energy throughout the day. So as much as you can, controlling your energy by having blocks of similar meetings, by choosing when to have certain types of meetings. Some meetings would be better for in the morning, some meetings would be better suited for the afternoons depending on where your most productive hours typically tend to be. That's just a quick overview of the calendar side of things.

Shane Hastie: I see this very firmly sitting in that manage yourself. One of the things that I'm curious about, and you touched on, is you've got control of 80%. There's 20% of your calendar that is coming from outside of your control.

The influencing that, managing up is perhaps a challenge that a lot of new managers and experienced managers struggle with, is how do we communicate my needs, my team's needs up the organizational hierarchy, whatever that hierarchy might be?

Managing up is an important skill [10:01]

Ahmad Wafsy: I think managing up is one of those skills that pays for itself over and over again once we learn it and actually master it. In a lot of ways you need to know how to manage your manager because that really gets you further in your career than most people think.

Two very general takes on this that I have. The first one is, there's often this resistance that I hear from a lot of individuals that, hey, I don't want to play politics. Politics is not for me. I just want to stay away from all that. I want to do my work, get things done. I reframe, I once heard a conference and I loved it and unfortunately I forgot who mentioned it, so I can't give them proper credit, but this is not my idea. But just reframing that, instead of politics, it's about making friends and telling stories. And when you think about it this way, it's slightly more positive.

It's a slightly better spin on it, making friends. I actually enjoy hearing about other people and their lives and what's going on and then sharing stories about myself and or what's going on and hearing their stories. And when you think about it this way, it sits better with you. You don't feel like you're doing something soul crushing or energy draining. So that's kind of the first reframe. And knowing that you're doing it with a good intention, you're doing it to be more effective, period. As an individual, more effective for your team, more effective for your org, for your business. Ideally, in a healthy organization, incentives are aligned and that positive attitude going into it helps.

And then my second general comment in this, and it's very, very related, is no one is stupid. If you ever saw something that happened and you think that's a stupid decision or who would do that, or I'd never do this if I were in their shoes, they either have info that you don't have or you have info that they don't have, and bridging that gap is really ultimately where it gets you that clarity and those results. And most of the time approaching it from that angle and being like, okay, cool. I think I'm too smart. Clearly that's not true, let's be curious here and let's ask a couple of questions to see maybe they have data I'm missing or maybe I have data they don't have. And approaching it from a curiosity standpoint leads to a much better, a more productive discussion and more productive outcomes overall.

Shane Hastie: Another thing that we've seen and we've been exploring a little bit with some speakers on InfoQ, is this stepping in and stepping out. As an individual contributor, wanting to grow that leadership management muscle, and then realizing that, hey, this isn't actually for me. How do I step in, step out? And maybe I do this once or twice. What does that do in terms of career progression, but also how do I do that as a technologist?

Stepping into and out of management roles [12:28]

Ahmad Wafsy: It's very interesting. I think we are very risk averse as engineers and technologists in general. We're trained to look for how everything could break and how to avoid it as much as possible. And oftentimes you get both sides of that question. You get individual contributors that want to get into leadership roles because they perceive it as better, as a promo or a status perhaps. And then you have the other way around where, hey, what if I don't succeed in this? I don't want to lose all my technical skills, so I want to try and balance things and be able to return to being an IC if I have to. I think it's interesting from a few different angles.

My general advice there for individual contributors that want to get into leadership, anyone can be a leader. You don't need to have a formal authority or the formal individuals that report into you to be a leader. But really what you want to do is you want to demonstrate to a potential employer that you have the skills to be a good leader or you've done it before. And the easiest way to do that is to do it on your current team. I typically advise folks to lead by example. There's always something that could be improved in your current organization. It could be a bunch of technical debt, could be in new project, could be improving the process or how we run our meetings or scrums or whatever project management methodology you have going on. There's always room for improvement. So starting with that, identifying a challenge, a problem, proposing a solution and volunteering to take it on and do the work to address it, is typically a good place to start to gather some of those leadership skills.

The next one is really about finding the right opportunity to make that transition or make that switch. Again, I typically advise by telling your current manager about your ambitions, because oftentimes they know more about the org and where things are headed and they could actually help you with more opportunities in the meantime. If that doesn't work, start looking externally. If that's really what you want to do and you're sure you want to become a manager or a leader, the shortest path between two points is a straight line. Sometimes for different reasons, your current company, your current org wouldn't have the opening or the opportunity, look elsewhere. And there's a lot of roles, especially with startups where you would be a hands-on manager, where you'd still be expected to write some code and do some of your IC duties, but at the same time manage a team. So those are typically will be the ways that you start.

Now, the flip side to that is how do I balance those two things and how do I keep my options open, really, is the heart of that question. My recommendation there is don't do it for too long. My recommendation is, at some point it's easier to burn the ships, make the decision and go all in into one of those paths. Because you're trying to do two jobs at once. You're not doing yourself any favors and just accept that you're going to be a bad manager when you first start because you don't know what you're doing. There's a lot of skills that you need to learn.

I think it's useful in a lot of companies, Google for example, has a TLM role, literally tech lead/manager where you're doing a little bit of both. You have a small team, four or five direct reports, plus your duties as a tech lead where you can kind of get a taste for what this new role looks like. Would I enjoy having one-on-ones? Would I enjoy having performance discussions and trying to subjectively evaluate people's performances? And I think it's a good way to dip your toes in and see if you'd like it, but I often see people getting stuck there and sort of analysis paralysis. So a little bit where it's just after a certain point in time, you're not doing yourself a favor. Typically, when we need to make a decision, most of the time we're missing some data points. Once you've done that in between role for three to six months, you've got all the data points you'd ever need and it's time to decide. Anything beyond that, you're just procrastinating

Shane Hastie: As a leader, as a manager, we're responsible for the teams that we look after, the people. And developer experience, removing friction for others. How do I do that well?

Improving the developer experience [16:20]

Ahmad Wafsy: That's a really tough question. It depends on what that means in your current org. I've worked with interesting systems, Microsoft for example, I was part of the office org for a while. I remember it would take something like 12 to 14 hours to compile the entire code base for Microsoft Office. It was a large monolithic code base. The build command at the time, I think it was “go home”. You literally ran it and you go home and then you come in the next morning once the build was complete to start your day again. You could just imagine how slow the dev experience was there and morale associated with it and all the tips and tricks and different things that people came up with to try and circumvent that as much as they can. But it's one of the biggest, I think, morale issues on any team.

Typically the way I see it, as a leader one of my duties is to optimize for overall happiness on the team. That means a number of different things, like making sure individuals are growing in their career, they understand the expectations of where they're going and how to get to the next levels and stuff like that. But it also means fixing the house and making sure that engineers have the right tools to be successful, and more importantly, have the autonomy to do the work and suggest improvements and come up with changes.

Most organizations have some form of agile or scrum running and in a typical scrum instance, you've got sprint retrospectives where you supposedly looking through the sprint and looking at things that have gone well and things to improve. I often employ team-wide retrospectives at different cadences, depending on what works better for you, but really leveraging those to look for the recurring pain points that the engineers are running into, and more importantly, allocating time and the resources on your roadmap to address them. It's not going to be fixed overnight. Most engineers love a greenfield project where they'll be like, "You know what? Let's just throw this whole thing and we'll start fresh." I've never seen those projects be successful, but oftentimes you'd want to do that, incrementally change the tires as the car is running kind of thing. But make sure, give the engineers the autonomy to do that. They know what the problems are. They can start working on brainstorming iterative approaches to improve that developer experience over time.

Shane Hastie: Another aspect of leadership is that, and you've mentioned it more than once, the one-on-one. This can be a motivational, powerful experience or it can be a nightmare. How do we make it the former, not the latter?

Having good one-on-ones [18:42]

Ahmad Wafsy: I've had a lot of interesting one-on-ones. I don't think there's a sort of a very clear definition or very clear standard of how one-on-ones should run. I've had everything from what felt like a therapy/venting session to what felt like my better motivational speeches. But really I think one-on-ones, there's a few principles that I like to stick by to help one-on-ones be effective and really successful.

I think that some of the main principles there would be have them regularly. It sounds obvious. I've met a lot of managers, including managers of big companies, that do not have one-on-ones at a very regular cadence. I have them regularly, at least 30 minutes a week. I've seen people that do an hour, some people do an hour every other week. I prefer the weekly cadence personally myself. So that's one of the principles. Don't make it a project status meeting. There are hopefully other mechanisms, other ways to do those or to get project status. One of the goals is to focus on your relationship with the individual and building that relationship and building that trust over time.

As an example, it's usually a sign of an inexperienced or an ineffective manager when their one-on-ones are very short and they never actually fill the 30 minutes. I'll see a lot of managers do that too. They'll come in and how are things going? What are you working on right now? Cool, you're not blocked. Great. Then we don't need to spend the rest of the time talking about anything. And they just end the meeting there. Or the opposite where engineers are mostly introverted, so they're not going to be very chatty. They're not going to come up with a ton of topics. And as you become more and more experienced, you get to know how to ask the right questions, how to tailor your one-on-ones to different individuals and their different styles and preferences.

So on that note, I usually advise having a combination of a fallback template where you have, if we have nothing to talk about, then let's have some sort of template where we can discuss, and I keep it very simple, highlights, lowlights, feedback for you, for me. And then I like to ask, back to the feedback loops we discussed earlier, I usually like to ask a happiness rating question. We'll ask the individual to rate their happiness on a scale of one to 10. Two interesting things happen. First off, I think engineers like to quantify things as much as possible, so it's interesting for them to actually quantify that. And I usually actually track it, we keep notes and stuff like that, but I track individual happiness and more importantly, team happiness. And you can see how overall the averages move with your organization, like when there are layoffs around or when there are big reorgs, you could see that actually dropping.

But the other important reason to ask that question is it opens up avenues for more follow-ups. Like, oh, you're seven out of 10, you were a nine last week. What happened? Or what changed? Or why not a nine? Why not a six? And both of those questions actually take you in different directions, and this is one of those kind of signals for shorter feedback loops where you could tell how things are going. So that's some of the things. And then having some canned questions that more open-ended questions that would help you dig a little bit deeper.

The importance of aligned incentives [21:25]

And then lastly, the last principle I'll talk about is, this idea of aligned incentives. Because ideally, if everything is working well, the incentives that the individual has, not just make them better and they could hit their career goals, but they make the team better, they make you look better as a manager. They make the business better and make the business grow. And ideally all of those are aligned, but to help ensure and drive that alignment, I typically have a set cadence to do to career discussions. It's not helpful to talk about career every single week. And then depending on the individual and how experienced or how junior they are, it could be anything from every fourth one-on-one is a career focused discussion, so roughly once a month or maybe every quarter. Every six or every 12 one-on-ones we'll do a career focused discussion. And that usually helps folks align incentives and know exactly what we're working on and more importantly, how the goals relate to them as individuals.

That entire combination, I've found to be very, very effective. And it takes time. You're not going to build trust and have people open up to you right away. It takes time for them to warm up to you, for them to see that you actually care, they actually follow through, et cetera, et cetera.

Shane Hastie: A lot of really interesting and valuable points in there. If people want to continue the conversation, where do they find you?

Ahmad Wafsy: Easiest thing would be on my website, thethrivingem.com. I'm sure we'll link it in the show notes somewhere. We've got a free engineering management assessment on there that folks could take just to evaluate and see where they are. We'll link it in the notes as well if folks are interested. I'm also on Instagram, a1wasfy. I'm not very consistent with the posting there, but I do post reels with tips every once in a while so folks can follow along and hopefully learn a thing or two and teach me along the way.

Shane Hastie: Ahmed, thank you so much for taking the time to talk to us today.

Ahmad Wafsy: Thank you. Thanks for having me.

Mentioned:

• Website thethrivingem.com
• Ahmad Wafsy on Instagram