Performance Management at Indeed

Speaker A: Welcome to Geeks who lead the global learning community for senior data and engineering leaders operating at scale. My name is Peter Bale. I'm founder and CTO at Geeks who Lead and previously taught at Columbia Business School and ran engineering at General Assembly. The future of engineering leadership is here. It's just not evenly distributed. Every week we share interviews from senior data and engineering leaders sharing their hard won wisdom. And occasionally we mix it up with interviews with domain experts who can help us all to more effectively deliver business values from the engineering or data logs that we oversee.

Speaker B: Today I'm speaking with R.C. johnson, the former senior director of engineering at Indeed. RC, thanks so much for taking the time to talk.

Speaker C: Peter. It's such a pleasure to be on again.

Speaker B: So I'd love to do a, uh, kind of deep dive here. I know that one thing that's been on everyone's mind this year has been performance management. Right. It's the year of efficiency. It's the time when we're trying to genuinely do more with less. And we're even rethinking should managers code what should the right span of control be? How do we now that money isn't free? How do we use it a little more carefully within our engineering orgs?

Speaker C: Yeah, absolutely.

Speaker B: So I'd love to ask you some questions. I mean, firstly, uh, how long were you at Indeed and um, what kind of size was the engineering and the product and Engineering Org throughout your tenure?

Speaker C: Yeah, so I had seven years at Indeed and it was a ton of fun. It was a great organization. An organization that really focused on growth of engineers. And um, a lot of the HR fundamentals were really rock solid. Uh, so when I joined there, the company was still growing at an incredible pace. And the engineering team I think was around 400. I think product engineering might have been around 700. And over the course of the seven years that I was there, that grew to over 2000 or 2500 engineering and over 4000 people across product, technology and engineering, uh, by the time I left.

Speaker B: And that can make it really hard too because when you're thinking about performance management, there's this kind of, on the one hand, we want to make sure that we've got great performance. On the other hand, I've got 17 open recs. Like maybe we should just take this person. So when you first started at Indeed, what did performance management look like within the engineering Org?

Speaker C: Yeah, so even when I started, performance management had a pretty good foundation. They had great rubrics that defined the different roles and the levels within Those roles, they had a process for, for calibration and 360 feedback. And it was done quarterly. So it was really responsive to what was going on in the organization. But one of the things that was already obvious from the get go was that the process was designed around being able to get about 80, uh, people, uh, reviewed in a go. And so the room would kind of fill up with the managers to review about 80 people. The problem was we were already significant multiple of that, three to four times that in engineering alone. And so the process kind of was like, okay, well, we have two or three, four rooms running simultaneously. You know, maybe one in Japan, one in Seattle, and one or two in Austin. And again, that worked because the geographic disparity of the team. And of course this was all Pre Covid back 2017, 2018 kind of timeframe. But the problem was with the growth and as you go from, you know, 400 to 2500, you can't just keep adding rooms of 80 people without getting a lot of divergence, uh, across that. Even, even at two, three, four rooms, we were already seeing that. And so we would, we would move people around the country to try and kind of fix some of that. But ultimately, you know, that was, that was some of where it stood. It had good bones and good structure. What it wasn't, you know, ready to do was scale up. And so what we had to do was kind of work to bring it

Speaker B: together and fix that and just to understand. So what we're talking about is that the challenges, while they might have been a documented rubric, the understanding and implementation of that rubric on a given candidate would vary depending upon whether you were in conference room C or conference room D. Exactly. Got it. So, uh, what were some of the first moves to try to scale the process? What did you do or what happened first?

Speaker C: Yeah, so a couple of things we did just to kind of, I would say band aid, but I mean, honestly, they were both to heal, to kind of heal the process, kind of keep it, you know, uh, kind of keep our arms around it and to give us, uh, some better data around what was working, what wasn't working, what we needed to hang on to, what we had to let go of. Um, so a couple of things we changed. First we, um, we moved to lot smaller rooms. So one of the things about having lots of smaller rooms was it forced us to make sure that we could, could drive that consistency. So we worked on training, uh, training of managers, training of the people who would lead those calibrations to make sure. That there was a significant number of, uh, significant amount of consistency across those rooms. By moving to smaller rooms, um, it meant that we had to train more leaders to do that and that was in preparation for having lots more of those of those groups running simultaneously. Um, and it also opened up the possibility that when there were edge cases we had lots of other rooms so we could almost kind of redundantly process a particular performance review through a whole nother room of people who didn't have maybe as much context and, and double check the results. Now you can't do that a lot or else you're kind of doubling up all the work. But you could do it for, for those edge cases or for the ones where maybe the manager violently disagrees with the room, uh, and you know, wants to stick to, stick to their guns and doesn't want to disagree and commit. They want to, they want to advocate for the person and they're doing the right thing. They're trying to make sure the person's getting the appropriate review and the appropriate feedback. And um, there were a number of other things we did, but like I said, they were all kind of band aids. And the other thing that happened as part of this, which leads to the bigger restructuring that we did several years in, is, uh, groups started to kind of run variants of this. So engineering had a variation, product had a variation, our technical services and business operations groups had other variations and ended up becoming 13 or maybe even 20 different variations of kind of the same core process, um, across all these different business functions. And it became unwieldy and also it became something that, that HR was ready to kind of help to facilitate and take it off of the hands of all these business groups. And in doing so we needed to kind of bring it back to a simpler version that our, that our HR partners could help us to facilitate.

Speaker B: So when you decided, when it was decided to make those changes, what was the, and I believe what was your involvement? Because you're a part of basically the steering group that was uh, from an engineering perspective that was working on this.

Speaker C: Yeah, yeah. So HR approached uh, the kind of, most senior leaders, you know, VPs, senior directors, folks very involved in the performance management process. And uh, at the time I had been leading a small working group that focused on engineering performance management. And so I was a natural tag to come and look at what HR was proposing. And HR came from a kind of like, here's our core values, this is what we want the performance management system to measure. And we very quickly gave them feedback, said, hey, that doesn't align with what we have accomplished in designing a performance management system for. Indeed. Um, and so we gave them some feedback on that. We actually kind of went through some revisions with them and we built out a steering committee representing cross functionally product, engineering, technical services, which is kind of like our IT and other folks that were running the hardware, uh, for our data centers, uh, as well as business and strategy and basically everything under the kind of product and engineering or R and D umbrella. Um, all the major functions had leaders in there who were kind of delegates of the VP or the, or the Chief Product Officer to speak on their behalf and to stay connected to them to make sure that we were designing a system that worked for all of these different functions. It allowed specialization, but while still maintaining the same overall structure so that HR was able to drive that ball forward. And we stayed, you know, our respective groups stayed focused on the performance management, the coaching and the growth of the people in our respective areas.

Speaker B: So when you saw that you had a certain system or set of systems and you were tagged to kind of join this working committee to figure out, okay, what's next? What happened then? What were some of the changes made and what was the thinking process behind that?

Speaker C: Yeah, I mean the first thing we did was we sat down and we looked at, uh, what engineering had been doing and shared some of the things that we felt like were really important and needed to hang on to. We looked at what product was doing and said, oh, we really like some of what they're doing. They had had, um, some success at creating, um, almost a predictive promotion coming out of those performance reviews. And so we were able to look at that. Okay, that's really interesting too in some regards. They were more analytical about the performance review process than even the engineers were. Which, uh, is something to be said for the great product team that we had at. Indeed. And so we first and foremost, we started looking at what each team was doing and kind of where were the good parts that we wanted to kind of cherry pick out of their processes? Um, and also where were the broken parts? You know, what was hard about the engineering process? Maybe keeping that alignment right, um, or uh, just the amount of time, uh, spent in both in writing, um, but also in, in all of the backend processes. And so we began to look for the commonalities. And pretty quickly we settled on something that looked a lot like kind of just taking the product and the engineering processes and bolting them together and dropping all the bad parts. And in doing so we dramatically simplified, obviously the back end for this so that HR could take it over. But we also really got it down to something that we could explain kind of in, in three major buckets of work really. I even described them as flywheels because they, each one kind of had this virtuous cycle to it that kind of made the process a little bit more self sustaining. And ideally, you know, the goal was that it would always be self reinforcing to, to keep getting better.

Speaker B: So I want to get back to the flywheels in just a moment because that's fascinating what, what I want to ask just to get an idea. So presumably most of the lifting would have been done by what engineering managers on, on the engine, made the changes to the system.

Speaker C: Yeah, there's definitely a huge component of engineering management involvement. So you know, engineers, uh, and managers would often, you know, engineers would typically write a performance or uh, self evaluation, uh, and share that with their, their manager. The manager would go off and write a performance review, might be loosely or sometimes a little more heavily than it should have been based off of that, uh, self evaluation. Then that would go into a calibration. So then the manager is sitting there, you know, advocating for their reports, but also, you know, presenting, you know, what work the reports had done. Um, and it was analytical, it was, it was an analytical process in the sense that we were sharing specific metrics around how much this person's contributions had moved, you know, company or team goals. And so it was, it was measured. Which I think is, is an important part of doing a performance review system is that you want to get it away from just anything that's just, this is the way I feel about your work or anything that you really want to help people understand why they did what they did, why it was important to the business, why it was, why it was important to the team. Um, and so yeah, so the managers owned all that process. And then once it was calibrated, which is just to say that the room agreed with the manager or convinced the manager to move that rating to a different value, then the manager brings it back to the individual, shares it with them and that's the kind of totality of the process. There was, there was some 360 feedback that would be gathered, uh, excuse me, gathered along the way and sprinkled in. But it was really, um, you could almost argue that it was kind of color commentary. Um, I don't think we did the greatest job of driving real constructive 360 feedback. I think we got a lot more like positive attaboys. And a little less constructive feedback than we probably should have. But it was still, it was still helpful.

Speaker B: Got it. And then back then were you, what was the frequency that you were running those evaluations?

Speaker C: Yeah. So again, to the point of the, of the, the distribution and things changing, uh, we, most groups had moved to six months, um, so kind of every two quarters. Um, but it hadn't been a, a like top down mandate. Everybody moved to six months. And so it had been, uh, there were a couple groups like mine that were actually still fairly regularly using quarterly, even if we did it kind of informally at the midpoint, uh, just because we didn't have, you know, all the overhead and the structure to help us guide it. Uh, but all of the rest of the systems around it really still thought in quarters. So all of the, the bonus and promotion and a lot of those other pieces were still kind of linked to quarters. And so we hadn't fully made the move to six months. Um, but yeah, it was roughly, uh, most teams I think were roughly doing six months.

Speaker B: And I mean how long would the process take if you were doing that, whether it was quarterly or every six months from the ems, the directors like starting to go through this to like the final delivery back to the engineers. What was the cycle time on that?

Speaker C: Yeah, um, so we would typically, you know, we had different, different cycles in different years. But generally speaking, kind of overall timeline was about two to three weeks. You were never as an individual contributor, you weren't fully contributing or fully, you know, dedicated to that. Right. You wrote your own review. We typically tried to give people some, some rough time guidelines of like spend an hour or two, maybe a little longer if you were trying to cover six months, but really, you know, ideally coaching them to keep notes as they went through the period so that they could, they could get their, you know, get that review done efficiently. Um, and then the managers, you know, we, I knew of managers who would spend eight hours per person kind of trying to write that summary. And we would always coach that to be, be significantly less. And that required them, you know, being involved, uh, throughout the process that involved them taking good notes and having a good system for kind of repetition because especially if you're doing this every three months, you know, to spend that long, especially if you've got, you know, for a, you know, or more direct reports, it gets really, really timely. But no matter how many people you had as a manager, you usually needed a solid week's worth of work, um, to get it done. And so the hard part then of course for managers was their work continues during that period of time. And so. But the product managers would often be off busy at that time doing their own reviews. Uh, if they were, you know, product directors, they were doing, you know, groups of reviews as well. But everybody was also kind of doing quarterbacks planning. And so we would often also give the engineers a little bit of kind of fix it time in the sense that, like, we have a little less on the roadmap for that particular week or two weeks. So the engineers could go and they could push technology forward or they could go and do some of those refactors that, you know, sometimes stay on the back burner a little too long. That gave them a little bit of slack to go and tackle some of that, um, in that, in that same time frame. So it was, you know, it was relatively well used. But I will tell you that managers and directors definitely felt that tension of like, how do I keep planning for the quarter to come? How do I finish reviewing the quarter that just wrapped up? And so, you know, it is, it is a busy time. But, you know, for those who kind of took the. Took to heart, that concept of preparing, you could usually get through it pretty smoothly.

Speaker B: I also feel like, you know, the ICs would be like, yes, Christmas game, My manager's way too busy to tell me what to do. I can actually do the stuff that needs working on.

Speaker C: Definitely.

Speaker B: That's great. So then, uh, I know you talked about the three flywheels, and I'd love to kind of hit those one at a time. So, uh, what was the first flywheel that kind of underlayed the philosophy behind the new performance management system?

Speaker C: Yeah, so the first one really was focused on impact. It was focused on what was delivered. And I talked about it briefly just in terms of measuring. And this is not just vanity metrics of like, oh, I delivered X number of tickets. But really trying to dial it into this is the amount of revenue that I was able to generate.

Speaker B: Lines of code.

Speaker C: Not lines of code. Lines of code. You know, lines of code was there in the measurement system. But we would always, we would always let ICs know that, like, that's just it. That's just a number. It doesn't tell any story. Look, if you made the two lines of code change, but it drove $20 million of business, like you had a lot of impact. Now we're going to ask, what did you do with the rest of your time? Because changing two lines of code is probably pretty fast. But, but it, it's the, it's the start of a story. It's the invitation for a story and a conversation, not the end of the story. Um, and you know, two lines of code would, or a number of lines of code would never show up in a performance room. They worked on this change and this drove this amount of revenue or it drove this amount of traffic and clicks or this amount of new users, whatever, whatever that team's, you know, okrs or key, you know, key goals and performance metrics were. That's what we're trying to drive everything back towards for most people. Now there were a number of other groups where they might have key metrics, but the key metrics were maintained by them doing something that prevented a negative thing from happening. And so you had to do some extrapolation, you had to do a little bit of more guesswork on the security side on the folks that are maintaining uptime and things like that, where they're taking care of the patching and things like that that keep us safe, they've kept us up. And you had to just kind of go, if this hadn't happened, here's what would have cost us and use some portion of that to help you understand kind of the overall value of that picture. Or if we hadn't patched this security breach and we'd had it, it was a remote code exploit, if it'd been executed on, that would have cost us X amount of time, X amount of dollars, X amount of reputation. Not that you can really put dollars on reputation very easily, but you do your best to help quantify that so that, you know, the team recognizes both intrinsically, uh, the value of what they've done. And then also they're seeing that, you know, the actual extrinsic value that, that's appearing there for the company. So that, that first flywheel is, is all around the impact that they're generating getting that captured in the review. And then as you, as you go through and you calibrate that, then taking that as a feedback back to them and possibly even, you know, using that to say, hey, you drove X amount of additional revenue. Here's you know, the short term bump that comes from that. And so that, that impact score, uh, for us was generated for, for what bonus they were going to get, whether it was going to be, you know, 10% all the way up through like 30%. And so it could drive a real significant bump in a very short period of time. But that creates this beautiful feedback loop where, wait, I just got more cash because I found, you know, uh, a call to action on a page that was the same color as all the other calls to action. But this is the primary, this is, this is the money maker. So like, let me, let me talk to ux, let me make it the right color so that it stands out. And then all of a sudden, you know, more people will click it. And you know, that's a test that we ran. And you know, a fairly junior engineer was able to drive several million dollars more in revenue just by finding that, you know, a call to action was blue instead of orange. And in fixing those literally six characters of CSS to fix that for that particular button, they were able to generate a really nice little bonus for themselves. And it was like we taught people, you know, to hunt, to hunt for luck, to hunt for opportunities, to hunt for impact. And that's something you, when you can teach your engineers that. And obviously like that's core to the product role. But when you can teach your engineers that you've just created a great partnership between product and engineers who are just trying to say, hey, how can we continue to make this business better?

Speaker B: So I got to ask and uh, double click on that. So I want to get to the other two elements, the other two flywheels. One of the challenges with that is it can potentially when you tie comps so directly to performance and when you're looking for that kind of impact, it's like, but dude, I just run the kubernetes clusters or do you know, as you said, some of the ones that are harder? What happens when somebody's doing a rewrite that you genuinely need because you got to move off of one relational data store to a document db and they're like, how can I win? Should it, should I, should I? I'm not going to work on that team. I'm only going to work on the team that I can do six character changes to make seven figure bonuses.

Speaker C: Yeah, it's a, it's a very real struggle. So the first is, is the first thing against it is that there are people who just really much prefer those large scale, you know, let me, let me move us from mesos to kubernetes or whatever is right. Um, so, so first of all there's just general preferences that some of those people just don't want to go, you know, muck around in CSS at all. Um, and sometimes I'm one of those. I really don't. That's hard css but, but you know, but we did struggle with it because um, you do want to reward something that doesn't fit neatly within the time horizon. You know, maybe it's a year long project because we're, we're going from private cloud to public cloud and that's a massive move and we've got to do it carefully and maintain cost. Um, and so it took us a few years to figure this out. Um, but one of the things that we brought in, um, was we adjusted the definition of impact where it did not just have to be revenue or clicks, but that it could be documented successful progress towards an overarching yearly or multi yearly long term goal. Um, and so those projects like that, where it was like, hey, if we move from this technology to this technology, here's the scalability we get, here's the resilience or reliability we get, those are quantifiable and then we can say, okay, yes, we know that it's going to take 3/4, 4/4, but you're going to be able to show us significant progress towards that throughout that whole time, not have to wait all the way until the end to recognize it. And again, we're quantifying it and being able to, to recognize even things like that where it is, you know, it is kind of behind the scenes. Um, now the one that I still don't know that we ever completely solved is in a team of eight, one or two people, maybe three or four people are working on these great features that drive a lot of value and three, you know, three or four, maybe even a couple more are working on the rest of the features that just kind of keep the project humming. Um, we were working on, and I don't think we ever completely locked in on some sort of picture where it said, look, great team player. And there's a ton of impact in that. You kept the baseline, the floor of how bad things could get from going anywhere down and you raised up everyone around you. You can get impact from that. And so we were toying with some ideas in that we never locked in on something that was a complete like, uh, you know, 100% win in that, in that space.

Speaker B: I feel like that's sometimes the hard one. Whether it's the person who's just, you know, there's that one person on your team that doesn't seem super productive but, but when they go, everyone else is like, wait. I always used to tap them on the shoulder when I had a SQL query or a question about Kafka or something and they just knew it all.

Speaker C: I think there's a great post out there on glue work that it's just really, really hard to recognize. You see it, you know, when it doesn't happen for sure. Um, but, but actually like being able to quantify it and capture it all is, is incredibly, incredibly challenging. And I think, think something that I still take away as an opportunity for us in performance management to figure out how to do better.

Speaker B: Got it. So if the first imp. The first flywheel was impact, what's the second flywheel you were focusing on?

Speaker C: Yeah, so if that one was focused on what, then the second one was focused on growth. And it was really a little bit looking more at how that work was done. And indeed we had a culture that, you know, you really couldn't do work and leave a bunch of bodies in the wake. And I know that can be a little grim, but it's just the concept of like, it really, you know, that we expected you to kind of bring the everyone along and get to a level of consensus. And yes, there was some disagreeing commit, uh, brought into the organization. And I think that's helpful. But what you couldn't have is just people who were absolutely burnt or crispy because of you forcing something through kind of against their will. And so, you know, in this flywheel, you know, we're focusing on demonstrating how they grew in their skills. This was a little bit more focused on the soft skills, also a little harder to on focus, quantify, but fundamentally talking about the softer side of their performance rubric. Again, you're coming off, you're doing the review on that and you're saying, okay, you know, in terms of your reach or in terms of your impact or in terms of your leadership beyond this team or beyond, you know, your work. Here's where you're at. Um, and so in doing so, you're going to be able to show them the growth that they're having in their role. That can hit on some level of intrinsic reward of just like, I'm getting better at my job, I'm getting better at these, at these skills. Um, but then that's also, uh, one of the other fundamental pieces of them actually moving towards that next level. And so then there's the promotion, which is the extrinsic reward. So again, it creates this loop where if you do good things and you do them well, uh, and you, you, you learn to do them repeatedly and efficiently, uh, we're going to recognize it, reward it, and keep doing that. And so it created this loop of kind of showing people where their growth opportunities were in a very constructive and very positive, focused way. Obviously there were times when we had people who were culturally misaligned or struggling outside of work and it was bubbling over into work. Um, that this was used to coach people. But it was always done in a place of like, we know you can do this, we want to support you. How can we find that? Um, and so it didn't ever become punitive we or you know, just downright nasty. It really focused on how can we help you to grow. And then there were other times when people were, you know what, I'm actually kind of good here right now. Maybe they just had a new kiddo. Uh, and they're good to just like stay at this current level. And by having both the what and the how as a manager, you could, you could kind of talk to them about, hey, this is where you're at. It's, it's a we call. I often called it like a safety meets. You know, you're like safely within the meets expectations category and we're good to go. Like, you're, you're not, you're not looking for any more bonus, you're not looking for that promotion, but that's okay. Like, take some breath, like enjoy the new one.

Speaker B: And there are times like that life. I've got, uh, a friend who went from chief operating officer at a tech company to senior engineering manager. He had the financial flexibility and he wanted to have a little more time for other elements in life.

Speaker C: Yeah, absolutely. Yeah. So, you know, so this, you know, so, you know, I'm painting the picture as these, as different flywheels because they have slightly different outcomes in terms of like, you know, hard skill growth and short term compensation and like career growth and actual like skill development and long term compensation. Realistically, we didn't completely separate them. Uh, the what and how were kind of sprinkled throughout the actual write down or write up that we were doing in the performance review. But you know, when we coached people, people it was, remember, we're just focused on capturing the high level. The what and the high level of the how of what they've done in order to kind of share a quick synopsis of their story in a given time period.

Speaker B: So if you had the two flag wheels, then what and how. What was the third?

Speaker C: The third one is a sneaky one. And it's one that I have not seen done this well anywhere else. And what it came down to was a real partnership flag wheel, which is to say that, you know, as a manager, your job, if you ask me, your job is to grow your individuals. That's, grow them in their skills Grow them in their abilities, both hard skills and soft skills, so they can take on more and bigger work. In doing so, that expands the, the surface area of your team, which means your skills level up. You begin to, to run a larger and larger team, whether it's larger in headcount or larger in impact and scope. Um, and, and both of those are valuable. When we did this, what we pushed for was a real partnership between the manager and the individual contributor. And so what we actually got out of the business of doing was expecting the self evaluation to be completely written by the individual contributor. And instead we said we're going to collaboratively write that self evaluation. And in my case and in many other managers in my organization and other organizations, we would do that. I would start that day one, the moment I delivered them their new performance review. I would write a, a skeleton of what their next performance review is going to look like and say, here's the projects I think are going to come on your plate. Here's the opportunities that I think are going to come in front of you. I could be wrong. I'm, I'm fortune teller here. I've got a crystal ball and I'm not great. But put your guesses in too, what projects you want to be attached to, what things do you want to drive forward in the next three, six months and in doing so, help me to look at it because then we'll see on the first day of the brand new review cycle. You're short in this particular dimension. Maybe it's, maybe it's influencing other teams and kind of, you know, as a staff engineer, I want to see you influencing beyond just your particular engineering team and I don't know what opportunities are going to present themselves for that. So then we both are laser focused on that for the first couple of months because if we wait until month two or month four, too late, uh, the chances of finding that and then executing and being able to demonstrate the impact of that, it's too late. So we started out really partnered in that and, and you know, the, the benefit is the engineer or the individual contributor, you know, if it's a product manager, whoever feels like they've got somebody who's in their corner, they're going, the manager's going in to represent them, they're going in to advocate for them, but they're also going to come back with real crystal feet, crystal clear feedback. If the room didn't understand the work that was done, then we got to work on being able to document it or being able to measure it and show how it, how it, um, how it fits into the organization better. Um, and so the manager will come back with better perspective that they can share with that individual contributor. And so it creates this partnership between the two of them so that um, you know, the manager gets better at growing individual contributors because they have a better context, they have a better perspective. Um, the manager's scope and responsibility grows as the individual contributor grows. Um, you know, and the manager is also then, you know, the one who's bringing in that 360 perspective that we talked about before. They're going out and finding with some help from the individual contributor, those, those people who could say, yes, this is why this was impactful to our other team, or this is why this project is, was impactful that they worked on and bringing together that whole holistic perspective. But the best part about it was just knowing, you know, uh, the feeling as a manager knowing that you knew you were putting the best foot forward for an individual because you had worked really, really closely with them. And if you both forgot something, it was probably low enough in priority that it was okay that we didn't mention it in the review cycle this particular time. So you never had any feelings like what if I missed something or what if I, you know, didn't do enough work on this particular person's review because I was so focused over here. Um, and it just created this great bond between managers and their reports to, you know, to really focus again, the growth, the compensation, the promotion, but also, you know, uh, just the overall impact for the organization.

Speaker B: That's amazing. By the, by the time you left. So this sounds like this. What was the frequency by the time you left? Was it it every six months or was it quarterly at that point?

Speaker C: Yeah. So we solidified everyone across the 4,000 person organization, 4,000 plus product engineering, technical services, engineering organizations, um, on a six month cadence. Um, and we did that in part because there was still quite a bit of overhead to running the process between the 360 reviews, the writing, the calibration and everything. And that was still an area of focus to reduce that toil. Um, but it was also. So, um, there were two of those quarters that were really hard to do, Q4, uh, and Q2 because of holidays and where holidays fell, um, were always notoriously hard to just juggle around the holidays. And so uh, we in part chose to go every six months because the Q1 and Q3, end of Q1 into Q3 were much more wide open in terms of not having a lot of holidays. And Other interference running in the middle of those.

Speaker B: Now that you've had a little bit of time to reflect, if you were building a similar system at another company of a similar scale, are there any other things that you would either double down on or focus on more?

Speaker C: I think that the thing I would want to fix is really driving home that you don't have to hit every single thing you did in the review period. I think people tend to believe, and I think there's probably even a little bit of evidence to indicate that more words equals more impact and more words equals more, uh, more work done. And what we needed to do was get out of that business. And, and, um, to be honest with you, years ago, was a decade ago at Bazaar Voice, we had a system where we, where we explicitly said you only get three major accomplishments, three areas you could have done better, and the one you want to work on. And by saying that, it was like, look, we know you probably did a hundred other things in both of those categories. That's okay. We just want it. We want to use this as a snapshot. And I think that something, uh, like that, that really limits people to three to five big items. And it's like, that's it. We know that there's a lot more we expected. Don't worry, we're not going to go and, and, and, and tear you down on your review because you didn't have, uh, 700 things in this doc or 1500 words or whatever in here. Um, we need to be able to do it, you know, efficiently, I think something like that or, or some other structure. And I'm definitely open to ideas that helps to reduce the toil such that, you know, you're really just focused on, you know, a few words that gives a synopsis of, of the time as opposed to really trying to tell, like, okay, in week one through week, you know, 12, that, that, that kind of problem does, you know, that kind of thing turns into a problem real quickly.

Speaker B: I, uh, see. Thank you so much. Unfortunately, we're out of time. Thank you so much for taking the time to share your wisdom and, and your experiences.

Speaker C: Oh, uh, it was a ton of fun, Peter. Always fun to catch up.

Speaker A: If you'd like to learn more about geeks who lead, go to geeksholead.com Sign up for our weekly newsletter to get regular access to other great interviews, and then see whether you might qualify to join one of, uh, our exclusive free executive communities.