Benchmarking Strategy and Best Practices for Total Rewards Leaders

‍

Welcome to Aeqium’s Compensation Playbook Series! 🎙️ Today’s episode features a conversation with Michael Downey, Director of Total Rewards at DataRobot. With over 15 years of experience, Michael shares his journey navigating the complexities of compensation benchmarking in a fast-changing market.

This episode covers:

• Building benchmarks from scratch when starting with no structure
• Using employee-submitted data effectively without losing trust in your foundation
• Approaching compensation for emerging, high-priority roles like AI engineers
• Simplifying job architecture development for growing teams
• Creating flexible frameworks that adapt as your organization evolves

If you’re a Total Rewards leader tackling ongoing benchmarking challenges, this episode is packed with insights to make the process smoother.

‍

Transcript:

Peter McKee: Hey everyone, welcome back to Aeqium's Compensation Playbook series. We are meeting with Total Rewards experts to have conversations about best practices, trends they're seeing, and generally ways to stay ahead in this space.

Today, I'm really excited for us to have Michael Downey, Director of Total Rewards at DataRobot, someone I've had the opportunity to speak with a number of times in the past and always love getting his perspective. We're going to be focusing specifically on how leaders in the tech space can take a more in-depth approach to benchmarking and really stay on top of their craft.

So first off, just wanted to say thanks so much, Michael, for joining us today.

Michael Downey: Yeah, I know. I appreciate it. Thanks for having me on.

Peter McKee: Yeah, really excited for the conversation. I know we had a relatively long list of topics here. So just wanted to dive in. A good kind of introductory one, given the topic for us, I think, is I know you've been in this space, looks like around fifteen years, been at it for a while. Would love to hear your perspective on how the practice of compensation benchmarking has evolved over time since you've been in this space and what trends you've seen recently as well.

Michael Downey: Yeah, I mean, I think one thing that you always see just forever is this constant shifting around. At a macro level, it's looking at who's in your peer group, industry cuts, company size, that kind of thing. At a micro level, it’s about getting that scrutiny on how many senior engineers versus principal engineers are paid below the twenty-fifth percentile or above the seventy-fifth percentile.

What you see is when companies are thriving or struggling, you see that kind of shift come and go. And in tech, because you see lots of these thriving and struggling phases, you see lots of scrutiny. When times are good, I think those purse strings get loosened a bit. It’s maybe a bit easier to have some of that level creep come in. Then, when companies are getting tighter on their dollars, often you see much more scrutiny, and they want to see more data around headcount and that kind of breakdown.

But the biggest shift by far that we've seen in the last fifteen years is the rise in employee-submitted data. I remember ten years ago, there were some websites that were popping up where you could see what’s the expected salary for this job, but the data was so unreliable. You couldn’t filter by level, industry, or other factors. It was essentially Googling “What does an accountant in Denver make?” and ignoring things like bonus targets or long-term incentives.

Now, there are multiple sources of actually pretty reliable data. Some even show the sources of where this data is coming from. So you can see head counts, expected title ranges, total comp versus base salary, and you can compare across different sites. You've got Salary.com, Indeed, Pave, ZipRecruiter, Glassdoor, and then next-level companies like Levels.fyi that actually show you the internal leveling structure of these companies.

Even if your company doesn’t trust employee-submitted data, which there are reasons to take it with a grain of salt, as a comp professional, you have to be aware of it because employees and potential candidates know about it. That’s by far the biggest shift.

Peter McKee: Yeah, that is a really interesting point and definitely one we've heard from folks. Like, “Hey, we’re fielding questions of ‘I saw this online’ a lot more recently.” Any more to share on that? Like, how do you handle that? Or how have you taken that approach? Are you actually using it in benchmarking, or is it more just a calibration point for you all?

Michael Downey: Yeah, it’s more of a calibration. So what we do is stay grounded in our data—whether it’s our salary structure or however you’re basing your compensation—but you take that information the same way you would take information from exit interviews or candidate feedback on salary expectations. Sometimes that employee-submitted data is super helpful for filling gaps, especially in regions or roles where traditional data is sparse.‍

Peter McKee: That’s a great point. Both emerging roles as well as regions—I can see that being a really good supplement. I guess maybe on that point, I know today you're at DataRobot, looks like roughly a thousand employees. We've heard from you, maybe fifteen countries. I imagine there are a number of challenges that are unique relative to past roles that you've had, both because of the industry, which we're talking about today, but then also just the size and complexity of the organization there. Would love to hear if, you know, in your current role, any particular challenges that you've had with benchmarking relative to things you've seen in the past?

Michael Downey: Yeah. So, I mean, I would say the biggest surprise is, again, coming to a company with basically no structure and no benchmarks, no initial benchmarks to build off. And just knowing that one, you're not, you're never going to get a hundred percent right. And also that you're kind of building it as you fly.

What we found though, is I can kind of go into specifics on how we kind of really got that benchmarking off the ground. So when we started, we had no internal structure other than business titles. So what we wanted to do is we wanted to group employees. The specialization was really secondary for us. So if you're looking at software engineers, you're not so fussed in the first pass anyways about front-end versus back-end versus full-stack DevOps, that kind of thing. That’s secondary. You can have someone in the business kind of weigh in after the fact and say, no, this person's focused on this and that, things like that.

But what you want to know is who is a principal engineer versus a senior engineer versus a director versus a senior manager, that kind of thing. And knowing that a lot of times, especially early stage companies use titles as currency. So you have to really start to take that with a grain of salt. And so what we found is we actually used—we created level descriptions to say, well, this is the—and you can just use the Radford descriptions if you're starting—to say, these are the descriptions of each of these levels.

And, you know, ideally everyone has a perfectly written job description. You can just take that job description compared against the level, but it just doesn't happen. Those job descriptions are often an afterthought. So we try to group these people and you start by title because that's the only thing that you have. But what we did is we actually worked with the highest levels of executives of each of these teams and said, tell us about your direct reports or tell us about the people that you have a line of sight on.

And when we group these people, these people are titled VP, these people are titled director, looking at the people that are in this VP group, are they peers? If they were to sit around the table and look at each other, would they say, yeah, this person has the same role, the scope, complexity, the depth, all that kind of stuff as me? Or are they going to look and say, that person has a VP title, but they're not a VP or they might have a director title, but they're not at the same level as the five of us.

And so what you do is you actually have—we started with these, again, Radford-level descriptors and say, if this is the Radford description of a VP, tell us one of these people in this group that you think really meets this. Not the highest and not the lowest, but who—let's pick—let's find an anchor job. Let's find one that's really—yeah, definitely kind of is a clear role, meets this description, which, again, can be difficult in a startup because you might have a group of four that are just kind of their own little thing, as opposed to at a large organization where it's so clean and, you know, head count is easy to count and all that kind of stuff.

So we would go through that and say, okay, here's your anchor role. Now looking at the rest of the people in this group. Are they operating at the same level as this person? And if they're not, you might say, now this person's a little bit higher, this person's a little bit lower. Then let's just park those people later in the conversation. And then you can start to work next level down and next level down. Then you can circle back to the outliers and say, now that we have these anchor roles in each of these levels and we've grouped these people and we're pretty comfortable with the grouping, now looking at these outliers, is this person really a high four or a low five? Where do you think they better fit?

Because at the end of the day, you do need to pick a group and map these people in. And then once we had the highest levels of executives weigh in, then we'd go to their direct reports and do the exact same thing again. And we'd drill down into those teams and say, again, grouping these people, does this make sense? Are these people in the right group?

Because it's really abstract to map against. If you've ever looked at these Radford level descriptions, they're incredibly complex, first of all, and they're extremely abstract. So it's difficult for a leader, especially someone who doesn't have that comp background to say, you know, are they an expert in their field? Do they, you know, often use in-depth professional knowledge of wide range experience? It’s so vague. It’s hard for them to say because the answer is probably yes or no, where it should be. Well, where in the spectrum?

So often I find that using those descriptions to say, just give me one person. Give me one person that you say, yeah, I'm comfortable with that. Then you go, okay, great. Now you can compare against an individual rather than comparing against this abstract idea of what a senior engineer looks like.

Anyway, so we do that drill all the way down and then you roll it right back up because a lot of times you'll see. First of all, executives get to kind of validate their first impressions and say, oh, maybe this person isn't a director. Maybe this person is actually a senior director because now that I see the different layers have built up, that makes sense that this role sits here. Not to mention some lower-level leaders often don't have that same full view and you can see level creep and things like that. So they might see their person as my person's a principal engineer and you say, yeah, but once you actually step back, maybe they're not that high.

So anyways, that's kind of that high-level benchmarking to go from no benchmarking to some benchmarking, I think is just—I found a very efficient way to get it. And again, knowing that it's like, you're not going to get anything a hundred percent right.

The one other thing I'll add just about that, I think that something that we did and I think it’s just critical to get out ahead of is setting the ground rules for the executives if you're going through a benchmarking exercise like this, because a lot of times people will be very protective of their teams and the titles that they've given and the salaries that they've given and things like that.

So to come out and get out ahead of it and say, look, are there going to be any expected changes of this? Salary changes, headcount changes, title changes? Are we going to have to communicate to the employee that they're actually at a lower level than they think they are?

So what I would suggest and what I've found is effective is just to say that there are no changes coming out of this. This is step one. And step one is just we need to have a look at our org and say, where are we? Where are these people leveled? And then you can take a look back and say, how broken is it? What's it going to take to change it? What's it going to take to get that structure in place?

And you want that structure in place if and when you're saying, well, we want to communicate our levels and we want to communicate this and our ranges and things like that. It's like, yeah, you can't communicate any of that until you have a solid foundation that it's all built on.

Peter McKee: That makes so much sense. And I think, you know, just speaking to the challenges we hear from actually organizations across the spectrum of sizes, starting with either no job architecture or one that they don't trust seems to be a lot more common than you might have thought.

Did you, if you don't mind me asking, did you all work with consultants in doing that process or was the process you described just your team?

Michael Downey: Yeah, so I actually joined as they had just brought a consultant on as a first pass. And it went okay. And then I think it was—there was concern—I was concerned anyway that it was just going to be done once and then kind of shoved in a drawer.

And so what—then after that, so I went back and I probably did three more reviews kind of every six months to say, here's where your team is today. And we aligned it with a salary review so that it kind of made sense of like, hey, as you're going through the salary review, did this person get promoted or did they not? Or are you kind of—is this a real promotion or is this a cleaning-up-a-title exercise or something like that?

And I found that often leaders wanted to see it and they wanted to see—because they’re often looking back and they're saying, well, how did we ever have these two people at the same level? And we would often say, we're not asking for an apology. We're not asking for an explanation. Let's just fix it. Let's fix it now.

And it's one thing to say, well, does this have to be a promotion? Is this a formal thing? And it's like, if this person is already titled there and paid there, and this is truly just a correction, let's just correct it. Just to get all that kind of pressure and all that, well, I'm only allowed so many promotions in a year or something like that. This isn't a promotion. This is because you need that data to be accurate before you make any decisions on anything.

Peter McKee: Right. Yeah. I mean, I asked about the consultant a bit because I know that a lot of folks sort of look at this leveling exercise as almost an insurmountable task. But I love the way you broke it down there, just kind of going level by level. It makes it feel a lot more approachable, although I'm sure it was still quite a bit of work.

Michael Downey: It was. It was, it was a ton of work and it was honestly, it was work every six months for a couple of years. But if you, if you give yourself the break of let's step back and let's not worry about the specialization, because you might come in and say these, these pre-sales data scientists versus post-sales data scientists versus pre-and-post-sales. Like, do I need to know the nuances of the differences of these roles?

Like, no, because we're talking about leveling. So we're talking about the scope and the depth and the expertise that these bring. And that you can compare across an organization, whether you're looking at engineers or accountants or sales or whatever you're looking at.

And so once you kind of cut yourself that slack, then you're just saying, who would it make sense to sit around a table? Are these people peers or are they not? And then you're able to take it broader and say, so then looking at this, does that make sense that this is our VP group and this is our director group?

And maybe you start to look across teams and say, that's a bit funny that you'd have this person here. And again, those conversations are going to be interesting too, but if you kind of give yourself the grace of this isn’t going to be perfect, but let’s get the beginnings of a structure, I think it just takes the pressure off.

Peter McKee: Definitely. You got us onto the topic just a bit of benchmark data in talking about, hey, maybe we base our job architecture off of the Radford job descriptions. I’m sure anybody who is thinking about benchmarking in the tech space has heard of Radford, but how would you think about the number of different benchmark data sources or just data sources in general that you need as a tech company? And whether or not that changes over time? Because you mentioned Radford and also we talked about kind of the employee-driven sources earlier. Curious about how many is how you think about whether or not you need multiple sources?

Michael Downey: Yeah. And so, I mean, the answer is it depends. The short answer is it depends. I think starting out, if you're able to get two trusted data sources, so you've got, again, whether it's Willis Towers Watson, the Mercers, the Radfords, Hayes, you know what I mean? There's a bunch of those different ones.

But what I would say, if you're able to get two trusted data sources and by trusted, I would say employer-submitted data sources—not again, there's a, there's an incredible wealth of employee data. And honestly, at this point, maybe you'd be okay with one trusted data and three employee-submitted that you can kind of validate against.

But again, I would suggest two trusted data sources just starting out. And if you can buy previous year's data as well, which often you can if you're buying some of these data. The reason is because any one code in isolation, there's so much chance for inconsistency, unreliable data. It’s one data point at one point in time. You could have low survey submission for that particular role or level.

Companies, some of them submit every other year. So you have big data sets coming in and out of the data. Or it could just be an unusual data sample. Especially if you're using something like P75, which a lot of companies for their technical talent will say, well, we're targeting higher in the range. That's even more unreliable because you're not getting now the midpoint of a data set. You're getting onto the extremes of a data set. You can get really inconsistent data. You can see really skewed results.

So if you're able to get two data sets to start—and there's things about like, well, what about blending data and things like that? I think that all of that's fine. Honestly, I think if you can find one reliable data set and then you just use another one to validate against it or another one to fill in gaps that you might have in certain regions or in certain roles and things like that, it’s harder to find data. You can kind of use that.

Or if you say, I've got some real weird outliers here, like the senior level is the same as a principal and then it shoots up. Then you just bring in that other data set. I mean, data is never, never perfect and should never be used as a science to say the data said, you know, one hundred and twenty-two thousand and four hundred seventy dollars. So that's what we have to pay this person to say that that’s your starting point.

That's, you know, that’s, it’s a reference point like anything else. You can bring in other reference points to say that number probably should go a little bit up or a little bit down. But what I also like to do is to say, you know, okay, we want to find the data for a senior engineer or senior machine learning engineer in the Bay Area. Okay, fine. Pull that in.

But then you want to look, well, what is the next level up and the next level up and the next level down, the next level down? Versus, you know, what about senior managers and managers and directors and things like that? Because then you can start to build those job families and say, well, it makes sense that we would pay this level, you know, fifteen percent more than this level or fifteen percent more than the next level.

And that's also how you can start to smooth out some of that inconsistent data and really start to have ranges that you say, we know this isn't perfect, but this should give us a really solid shot at hiring these people, retaining these people, that type of thing without just kind of blowing your budget.

Peter McKee: I love that. Yeah. A good reliable one, and then filling in the gaps with maybe some of the less reliable or kind of employee-submitted ones, as well as your own job architecture and just what’s going to be consistent with your internal leveling.

Michael Downey: Sorry, I was just going to say, the other thing about supplementing that data, I think that, again, that employee-submitted data, which is way more available, it's oftentimes free or much less expensive. That’s the other thing, is these data sets are expensive, which is a huge drawback.

And a lot of times you get resistance to say, well, I don't want to spend tens of thousands of dollars on this data when we can get free employee-submitted data. And I'd say, especially starting out, it’s just so critical to have a foundation that you can say, no, we're using this as our foundation. Supplement as much as you want with this, you know, free or lower-cost employee-submitted data.

And also where the employee-submitted data really comes in handy is seeing some of those trends. And so if you can see, wow, you know what, like a deep learning engineer or research engineers, there’s a real uptick in the market that maybe these larger, more reliable data sets are a little bit slower to respond to. You can maybe get, again, it's all supplemental. It’s in some cases maybe even kind of anecdotal, but that can really start to give you an idea of, hey, we're seeing these trends or you know what, we’re seeing this premium over and over and over being applied to these roles.

So we might want to think about shifting maybe our ranges or shifting the high end of our ranges and things like that.

Peter McKee: As you're evaluating some of, I guess in particular, those supplemental data sets, how do you think about whether or not it's one that you want to use or factor in? Are you mostly going off reputation or is there anything you're doing with the data to evaluate it?

Michael Downey: Yeah, so reputation for sure is kind of a first step. But absolutely, I think that there's a lot of, you know, call them maybe general data validation things of saying, what's the headcount? What are these companies coming from? Are they showing you the sources?

Again, because if a company just says an average engineer is paid seventy-two thousand dollars in this country, or even if we say, oh, it's a senior engineer or principal engineer, you still need to say based on what, because, you know, what industry, how many companies, how many employees, what kind of data are we looking at?

Is this just all employees? We asked employees, what are they currently being paid? Because you might miss out on little nuances like, well, is that your target or is that your actual? Because those could be wildly different, especially when it comes to things like equity. How an employee values their equity might be very, very—and in fact, almost certainly is very—different than how a company is valuing that equity.

So you need to take all of that with a big grain of salt. But some of those larger companies, again, they're very transparent about their methodologies. And they say, this is how we calculate it. This is what we use. This is our headcount. This is the incumbent. This is where it's from. These are the titles that were used. These are the most common titles and things like that. Or years of experience, all those different things that you can get.

So there’s kind of just some basic data methodology that you can really look through and say, this seems pretty reliable. Again, it's a challenge to say, I'm going to use this as standalone data, but it's an excellent way to supplement data and say, look, I'm confident enough that this is telling me we're seeing a premium in the market on this role or we had a hard time finding data, this number is kind of validating the number that we thought we were seeing, and so we can go ahead with that.

Peter McKee: Yeah, and I love what I also heard you say there, which is that maybe we have a few data sources we’re less confident in, but if they’re all kind of saying the same thing, like we’re starting to see an uptick in one of the roles, that can be a signal in and of itself, which makes a lot of sense.

Michael Downey: Yeah, it's nice just as a validation, right? Because a lot of times you have data, it's one data point, and you say, I don't know, I've never hired a principal engineer, machine learning engineer in Germany before. And so how confident am I that this is the thing? And it's like, you can have a look at all those employee-submitted ones and it'll at least give you some confidence in where you're at.

Peter McKee: Yeah, I know in one of our previous conversations, we talked a bit about something you've touched on a few times here, which is, hey, if we have this new role, we're trying to hire a machine learning engineer or an AI engineer. We’re trying to hire them in a new region. How do we approach that? What's the challenge? I would love to hear maybe your latest thoughts on that. Any additional ones that you have on top of some of the supplemental data on how do you approach benchmarking for some of these emerging roles? The AI engineers may be a top of mind for everyone in the tech space.

Michael Downey: Yeah. And so it's actually fascinating because I was reading an article and it was in this—sorry, I can’t reference the article—but it was that, you know, they're expecting thirty thousand AI engineers to be hired, PhD-level AI engineers hired in the next year. And there are currently three thousand people in PhD engineering programs.

And so it's that there's going to be this huge thing where the rubber hits the road here. And some companies are going to have to either change their expectations or, you know, really, really make that bet. I'll answer kind of—I'll take it on a little tangent just for a second because I think what's super interesting is companies, again, they want to know, well, what does the market pay for this role?

And you might say the latest data that we have or the most reliable data that we have right now is that it pays, you know, here's the twenty-fifth, here's the fiftieth, and here's the seventy-fifth percentile. Now, some companies might say, we value this role so much, we want to pay at the ninetieth percentile, or we want to pay somewhere in that range for these specific roles, knowing that, yes, we might—it might be an investment or we might be overpaying now.

But if companies value a role more than the market, then they have to be willing to make that bet. So if you are an AI startup, it's one thing if you're a massive company and you go, it would be nice to have five AI engineers, whatever they think that that might mean.

But if you're a startup and you say, we have twenty-seven employees, and there’s three that are make or break for this entire organization, or we're a five-hundred-person company and we have twenty people that are literally going to make or break the future of this company, then those are roles where you might need to make an investment and say, here's the ninetieth percentile.

And even the ninetieth percentile might just be a reference point. And you're saying we’re willing to pay here. Like you read stories about, oh, this person negotiated for four hundred thousand, five hundred thousand. That's because that's a company making a bet and saying, it doesn't matter because the return is either going to be our company makes it and we’re off and running, or we don’t make it because we don’t have this specific skill set in-house.

I just think that that’s one that’s really critical. I know that wasn't exactly the question that you're asking. So to go back to the original question, though, thinking about finding this data, a lot of times you're going to find data that you won't find the data that you want. You're never going to find, hey, tell me exactly.

I’m going to ask ChatGPT. Tell me exactly what does this highest-level engineer make because we want to do something. That number doesn’t exist. The number doesn’t exist that you can find. Make a bet on it.

So it almost comes to the point where you say, here's all this other information that we do have on the highest levels of this existing level. Maybe we see some supplemented with some employee data that says, hey, we've seen even offers of three fifty and four hundred. And then at some point you just need to kind of pull the chute and say, we're going for it, and we know that this number might be too high, but this person is so critical at this stage right now, we’re willing to make that bet and then deal with the consequences after the fact.

Peter McKee: I love it. So look at the roles that you do that are similar, that you do have data on. Use some of those supplemental data points. And then especially on these types of emerging roles where we're hearing some pretty crazy numbers, be prepared to know which roles you want to make an investment on.

Michael Downey: And make a conscious decision. That’s the other thing, right, is that it’s not—it’s not a, oh, it’s a free for all in engineering and now all the high tide is going to rise all the boats. It has to be a conversation with finance early stages to say, look, this is why these roles are the future of our organization.

And there's a buy-in across that executive level and buy-in across the leadership in finance and leadership in sales and leadership in engineering and saying, we're all on board with, yes, we need—we know this means we need to sign fifteen more contracts to make this worthwhile. But bringing these three people on, these seven people on, these twenty people on is going to have a ten X return eventually.

Peter McKee: That makes so much sense. You want to have those strategic discussions up front, not at offer negotiation time.

Michael Downey: Yes.

Peter McKee: Probably set yourself up for failure then.

Michael Downey: Yeah.

Peter McKee: Michael, I really appreciate your time today. I think that’s all the time we have for questions. And thanks to everyone for joining us on this episode. Hope it was helpful for all. And again, really appreciate your comments, Michael.

Michael Downey: Yeah. Thank you so much. Thanks for having me.