Michelle Salvado has spent 28 years in tech, product development, and software development, including as an engineering executive at McAfee and Fireeye (now Trellix). Today, she is an executive coach working with engineering leaders.
We spoke with her about the role that context plays for engineering leaders trying to make data-driven decisions, communicate with business teams, and develop their managers as they grow in their careers.
Here are some selected excerpts (watch the video for the full conversation!):
We’ve moved from huge digital acceleration initiatives to some tech layoffs as budgets seem to be coming under more scrutiny. What are some of the trends that you're seeing in engineering leadership in response to these changes?
I'm seeing engineering managers with larger spans of control and larger numbers of direct reports, which can really be difficult for them. I'm seeing longer hiring cycles, mostly because leaders want to be sure they’re hiring the right candidates. They're also definitely giving preference to direct referrals because they’re a known entity and there’s less risk.
This comes as leaders are trying to figure out how to do more with less. They're not getting the budgets that they thought they were going to have, so I’m seeing a reduction in what I would call supporting roles like dedicated agile coaching teams, project management, and scrum masters as a way to bring cost efficiencies to the organization.
And of course, everybody's trying to figure out how to leverage AI in development.
I can imagine that all of these shifts are creating a lot of tension and challenge for these leaders.
Yeah, engineering management was already a difficult job that I think a lot of people didn't realize, because it's not just technical, right? There's really three pieces: the technical piece, general leadership, and then performance management of individuals.
And so I think a lot of people don't recognize that engineering management is a difficult job to begin with. But when you throw in the current market conditions and what's happening in some of those trends that I mentioned, it puts even more pressure on on the leaders themselves.
Where are some of the misconceptions that engineering leaders tend to bring as well? Are there ways that they are perhaps setting themselves up for failure?
I coach a lot of different leaders across several different engineering organizations at different levels, whether they're VP level or below. What I see is that definitely in those lower ranks and even at some of the higher ranks, they're missing the intentional switch into management.
The misconception is that if I was a really great technical lead, then I'm obviously going to be a really great manager.
This idea has been around for a long time, and I would say the industry hasn't done a really good job of onboarding people into management. Let's be more intentional about, you know, giving them the basic skills that they need, helping them learn what they need as they grow.
What does that evolution from engineer to proficient engineering leader look like?
There's a leap from engineer to engineering manager, and that leap is really about the intentionality that you bring as a manager.
Many don't recognize how to measure the efficiency and effectiveness of their organization. As an engineer, I'm always focused on delivery: the delivery of the product, the code I'm writing, how good is the code I'm writing, how clean is it, how automated are my tests, like all of those things. Those are the things I focus on.
But as I become an engineering manager, not only do I have to look at the product pieces, so the code and all of that, but now I have to look at the people part too and think about the effectiveness and efficiency of my engineers and my engineering team. And many don't know how to make that switch.
[Want to learn more about the evolution of the engineering manager? Hear more from Michelle at the 7:00 mark in the video above.]
It sounds like the context is really important and having that understanding of the context when you're trying to enact solutions to some of these challenges, right?
Yeah, absolutely. Context matters. A key skill for any engineering leader is to have the awareness of yourself and of others and the environment that you're in. And how do you structure or design your organization in a way that allows for efficiencies and effectiveness from an engineering point of view?
One of the things we hear a lot at Uplevel is that allocating time effectively around what devs are working on what is a consistent challenge for engineering leaders. Why that is so difficult, particularly at a larger scale?
It's difficult even at some smaller scales too, but especially at larger scales, because at the end of the day, there's a push and pull.
You want to push decisions down as far as possible in the organization to where the work is being done, but there is a bigger business being run. There are bigger financial and strategy pieces that the lower levels might not have the visibility to see or understand. And so some decisions are made at that higher level, but when you make those decisions at that higher level, you're lacking the information you need from the lower levels.
The key in both of these cases is visibility. Can you get visibility either to that lower tier and push that decision as far as possible that you can, and they have enough information to make those kinds of decisions? Can you get that information to the upper level so that when they are making those strategy level decisions, they're taking in the context?
Where do bad decisions in engineering leadership come from?
Some of the bad decisions come from that lack of data, that lack of visibility and understanding. I've seen organizations that needed to chase a big customer requirement that came in really hot because, hey, they're not going to renew.
And so you pivot an entire team to go after that. But the implications are long-lasting. There's an impact of pivoting and doing something for a specific customer and then missing deadlines for other things that might impact other customers.
So I think it really does come down to understanding that when you make these decisions, what are the impacts in engineering? What are you giving up? At the end of the day, the business does have to make trade-offs. But they need to understand what the cost of those trade-offs are, and I don't think they always do.
Let's say engineering leaders have access to more data about how time is being spent or how many works in progress they have going. What does that enable them to do to make better decisions?
I think it really empowers them to be able to go to the business and say, look, I understand you have an urgent need. Here are the solutions that I can provide. And with each of those options, here are the impacts, the positives or the negatives. It really enables that engineering leader to be a part of the solution versus just an order taker, an equal part in the conversation at a leadership level.
I see a lot of engineering leaders, who haven't been around for a while, who are still kind of like order taking, right? It's like, well, they said to do this. Well, okay, what did you do to put yourself in a position where you had data or you had the information and potential solutions and options so that they could weigh those risks?
I think that's really key because a lot of engineering leaders don't realize that part of their role is understanding the implications of some of these decisions, and then giving their executives the potential options so that they can make decisions based on that information.
Watch the full video to hear more from Michelle Salvado on:
The four types of engineering data that drive her decision making
How processes for collecting this data have changed over time
How having engineering data can allow leaders to empower their managers to lead effective teams
Why engineering leaders are good storytellers — and why that matters