Checkr’s VP of Engineering Krista Moroder found inspiration for leading an eng org at a late-stage startup from an unlikely place: the teachers’ lounge. Before she became an engineering exec, she was an educator — first a teacher, and later a program director at an education nonprofit.
“There’s this one activity that always stuck with me,” says Moroder. “School leaders would put up this big chart in the teacher’s lounge with the name of every student in the school on it. Then over the next few weeks, they’d ask teachers to add a sticker next to the kids who they knew were engaged. Maybe the kid’s in an after-school activity, or they speak up a lot in class, or they hang out in the classroom too long after the school day until a teacher has to kick them out — those kinds of things.”
The exercise helped school leaders spot the kids who needed some extra attention. “They would go through the chart and see who didn’t have any stickers. Those are the ‘at-risk’ kids,” she explains. “It's not always the kids who have bad grades, either. A kid could have great grades, but if they didn’t have a teacher champion, they’d end up slipping through the cracks. The shared goal of the school was to eventually get every kid a sticker.”
After nearly 10 years in education, Moroder left her post in the nonprofit world, learned to code and landed a gig as a software engineer, eventually joining Checkr as an engineering manager and rising the ranks to VP. Now, she’s recreated that same sticker board to oversee the engineers in her org — in a spreadsheet. “I religiously track every single engineer on my team and what they're working on,” she says.
It’s a system that’s proved useful as Moroder has navigated one of the toughest problems for eng leaders: the threat of regrettable attrition. Moroder arrived at Checkr during a hiring surge back in 2019, which meant many of the engineers on her team would hit the dreaded vesting cliff around the same time.
Worried about an impending mass exodus in her 80-person org, Moroder and her fellow eng leaders started tossing around ideas to shore up retention. She found herself asking that same question from the teachers lounge: How can we get every engineer a metaphorical sticker?
So she looked to a practice that her org had already been informally supporting for incident management: rotations. The idea was to give engineers who’d already been at Checkr for some time the opportunity to get exposure to different problems, work on cross-functional projects and train up on new skills, like AI or data engineering. This, in turn, has allowed Checkr to rotate around its sharpest tech talent to tackle the company’s most pressing projects.
Over the past several years, Moroder has helped formalize the rotation program at Checkr, and she’s scored some pretty brag-worthy retention stats as a result. “Two years ago, non-regrettable attrition was zero, and the year after that, it was 2% — because one person left. Across the board, my team is extremely tenured right now,” says Moroder. “For staff engineers and above, about 60% of them have been here six years or longer.”
Folks now point to this rotation program as the main reason they’re still here. They’ll tell us, ‘I've had three careers here.’
Rotation programs are often a standard practice at large, established companies, offering a test drive for new grads before they take on a full-time position. But there are considerably few resources out there on how to actually pull them off, especially for scaling startups with eng headcounts in the dozens or hundreds, not thousands — which is why Checkr’s program piqued our interest. Moroder has generously opened up her playbook for executing rotations for more tenured folks at such a thorny stage of growth.
In this exclusive interview, Moroder starts by unpacking her theory on what really drives engineers to put in their two weeks. She then details Checkr’s rotation program, walking through the steps engineering leaders can take to implement a similar system in their orgs and what’s made hers so successful. She also offers up advice for getting buy-in from managers — even when it means rotating out their star players.
Moroder may have honed her strategy in the engineering domain, but her tactics are well worth a read for any org leaders looking for a fresh approach to keeping their best talent.
THE REAL REASONS BEHIND THE ENGINEER’S 3-YEAR ITCH (HINT: IT’S NOT JUST THE EQUITY REFRESH)
Stalled learning at scaling startups
Moroder acknowledges that flight risk isn’t as much of a concern for engineers at early-stage startups because a rotation system is practically built in. “Rotations happen automatically at a lot of smaller startups because everybody has to wear a lot of different hats,” says Moroder.
The threat of turnover looms larger when startups grow and eng teams become more specialized. “Once startups start to scale, it becomes accepted that people will leave after two to three years. But they don’t have to. No one digs into why,” she says.
Moroder doesn’t want to accept the inevitability of constant engineer departures — especially when so much critical knowledge is floating around in their heads. “It’s also a question of who’s leaving. I don’t want my subject matter experts and people with deep knowledge to leave. So those are the people I need to really pay attention to,” she says.
In her view, comp isn’t always the culprit. “Most people assume it’s just about an equity refresh,” she says. “But that’s not always why people leave. It’s also about a career path. Engineers want to be constantly learning.”
So instead of making peace with the revolving door, she resolved to take action. “If you know that engineers might start thinking about leaving around year two or three, you need to design interventions before then.”
The one thing I've seen across the board is that engineers leave because they get bored. Engineers are allergic to monotony — the job itself is literally automating repetitive tasks. If engineers aren’t constantly learning, they’ll leave.
Technical FOMO
An especially timely reason for engineers to jump ship is the fear of falling behind as AI and ML tech advances at a breakneck pace.
Continuous education has always been a reality for this line of work. “No one becomes a software engineer and their job is the same 10 years from now,” says Moroder. “So they can either go somewhere else to learn it, or we can train them up internally. I’d rather keep the knowledge and context they have, even if it means they’re in a different role.”
Moroder says the robust rotation program gives Checkr an edge in this current market — and an opportunity for engineers to brush up on new tech without leaving the company.
“Over the past year, I sponsored an AI taskforce and opened up rotations to some engineers who were already self-motivated to learn,” she says. “That rotation quickly evolved into a full-fledged, permanent team, which has now upleveled the AI skills of the whole engineering org. This team even hosted an org-wide AI Hack Week and brought multiple GenAI solutions to production.”
Rotations are just about giving people the opportunity to have an even greater impact.
Rotations have been equally impactful for training up engineers who came from non-technical backgrounds, just as Moroder herself did. “I've had a lot of junior engineers who did something completely different before they became software engineers. Those people often end up on accelerated career paths — because they’ve already developed senior problem-solving abilities and just need the technical skills to catch up,” she says.
Moroder points to two folks on her team who’ve been able to apply skillsets honed outside the realm of software development. “I had one engineer who was a sales account manager before engineering. I put her in front of every single customer — she became my most customer-facing engineering manager,” says Moroder. “And I have another person who used to be a structural engineer for the Moscone Center. She spent an entire career as a systems thinker, and that skill translates. Now she’s leading the systematic effort to modularize our monolith.”
Above all, rotations have allowed folks from all kinds of backgrounds, technical or otherwise, to tackle problems with fresh eyes. “With anybody internally who's transitioning into another role, they instantly see a problem in a different lens. So the value that they can add is much higher because they know how to speak the other language,” she says. “It requires a little bit more investment from the company, but the payoff is way, way, way better.”
STRUCTURING THE ROTATION PROGRAM
Most eng orgs have some version of an informal rotation program to put out fires and staff up big projects. That’s how Checkr’s program started out. “We’d already been doing rotations reactively, even if they weren’t called ‘rotations,’” says Moroder. “So we wondered, can we use rotations proactively, as risk mitigation for retention?”
Once Moroder saw the potential, she got to work designing the program. Here, she lays out her order of operations for transforming rotations from ad hoc incident clean-up into an org-wide system.
Step 1: Create a “sticker board” spreadsheet to track your org
The first and most essential prerequisite before setting up a rotation program is to get in the habit of tracking metaphorical stickers.
“Every manager should have that spreadsheet, full stop. You should know every year what everyone is working on at a higher level,” says Moroder. “Even if you're managing a 100-person org, you need it.”
There are three columns that Moroder monitors in her spreadsheet:
- Participation in a rotation or cross-functional task force. “Some rotations involve joining a neighbor team for one or two quarters to derisk a project, while others involve joining a cross-functional taskforce to solve a hairy problem, like when we created our “Monolith Enablement” team to jumpstart our modularity work,” she says.
- Work on multiple teams. “Rotations have made internal mobility a lot easier and makes engineers feel safe trying something new,” she says. “I’d say about half of rotations end in a permanent placement to the team they rotated into, while the other half go back to their home team. And that’s okay, too! They come back with fresh context and new practices, which is good for everyone,” she says.
- Training for a new role. “About 20% of the team has changed roles entirely during their tenure. We built out an internal manager training program in 2022, and we’ve also had training surges when needs have changed,” she says. “For example, we recently supported a cohort of quality engineers learning about data engineering.”
Eventually, her goal was to get every engineer a checked box. “As long as everyone had at least one checked box by the time they hit three years, I felt good,” says Moroder.
As a school teacher I managed 120 kids. You can keep track of 120 people in an org along with one thing they’re focused on each year. It's not hard, it just requires a little bit of organization.
This three-pronged approach to tracking engineers’ engagement opportunities is helpful because manager openings are often in shorter supply than demand. “People think the only growth opportunities they have are to climb the ladder, but that’s far from true,” she says. “Not everybody can be a senior manager because they want to be a senior manager. There has to be scope for it. So an opportunity to learn something new is often what people are looking for, but they think moving to the manager track is the only way to do that.”
Step 2: Map the sticker board against quarterly priorities and projects
The next step is to look for high-priority business problems that you’ll need your most seasoned tech talent to solve — and are currently under-resourced.
At Checkr, Moroder’s leadership team sizes up the most urgent needs on a quarterly basis. “At the beginning of the quarter, we’ll say, we need six people over here, two people over here. How are we going to staff this project?” she says.
As a result, Checkr’s engineering org chart ends up being quite fluid. “We ended up in a matrix management situation for many of my teams over the last year,” she says. “Together, my managers read Team Topologies and Dynamic Reteaming — and we started supporting pods where managers could end up working with engineers who didn’t report directly to them. It allowed us to be more nimble to meet the needs of the business.”
Moroder then tracks all of these inter-team movements in a secondary spreadsheet. “We have the spreadsheet of who manages whom, and then in the second tab, I track who's working on those 10 major initiatives, and you get a mix from every single team,” she says.
Engineering managers take point on overseeing individual projects. “There’s an engineering manager who acts as the project manager,” says Moroder. “But then the actual team working on it might be a mix and match from all the teams under it. So it’s very flexible.”
While the bulk of this planning work happens quarterly, Moroder keeps tabs on priorities constantly. “We do more formal planning for rotations at the quarterly mark. But then within the quarter, I'm having these conversations at least once every two weeks around certain projects — because things are constantly in flux.”
Rotations make room for organic reshuffling as project needs ebb and flow. “Right now, one part of my org is growing and the other part is reducing as they automate things. This means I have about six people on rotation from one org to the other, and at some point, we may shift more permanently,” says Moroder. “It makes for a more graceful transition.”
In some cases, rotations happen between two separate orgs and the remits of different VPs to put company-wide priorities first. “I recently discussed a rotation from another VP’s org into my org because we needed to stack-rank at the company level,” she says. “So there are always a few projects across the entire company where we’ll need rotations to get them done if we don’t want to deal with a reorg.”
Priorities are constantly shifting. Unless you want to reorg every single quarter or year, rotations are a smooth way to tackle those shifts.
Step 3: Check in before making permanent switches
“A rotation isn’t a transfer,” Moroder clarifies. “An engineer can’t just move teams if they want to. We do have an internal transfer process — so when it comes to actually moving teams, that requires a bigger conversation around capacity planning.”
Checkr’s rotation program functions as the middle layer of a three-tiered system of working across different teams:
- Matrix management: Regular work across multiple products, managers and teams.
- Rotations: Temporarily working on the org’s highest stack-ranked priorities.
- Transfer: A role opening and permanent transfer to another team.
Rotations do occasionally result in a permanent transfer. “Once an engineer hits the six-month mark on a rotation, and if the capacity is there for the long term, we'll ask if they want to stay with that team,” she says.
One recent example of a rotation-turned-transfer is an engineer who joined Checkr as part of an acquisition. “We hadn’t fully integrated the new systems yet, so he was working in a completely different tech stack,” she says. “He raised his hand anyway when we needed more support in one of the core product teams. He quickly ramped up in Ruby on Rails, started picking up support tickets, and then three months turned into six months. Now, he’s a permanent member of the team, ramping up other engineers rotating in.”
With engineers in perpetual rotation and even occasionally changing teams for good, though, Moroder admits that things can start to feel transient. “One of the risks of this system is not feeling a sense of stability on the team because people are constantly moving,” she says.
To guard against that, Moroder recommends keeping some folks fixed in their spots on the org chart — which often happens organically. “You do need some ‘anchor’ people who don’t move between teams,” she says. “People will often self-select into those anchor spots. There are some engineers who love to drill down as far as they can into a focused area, and the fun for them is seeing how deep they can go.”
Still, only a fraction of the engineers within the org are on rotation at any given time — because it all ties back to project needs. “The checks and balances are the higher level company business needs. We don’t approve every rotation. You can't just rotate or move teams because you want to. We have to agree that there's space for it and it makes sense,” she says.
HAVE THESE TOUGH CONVERSATIONS TO GET BUY-IN FROM MANAGERS
So you’re game to start implementing rotations in your org. How do you convince other managers to give up their best engineers?
When Moroder proposed turning rotations into a formal system, managers bristled at the idea. “Managers will say, ‘Oh, I don't know if I can support rotations.’ But any time there's an incident, any time you need to de-risk, you end up doing rotations anyway,” says Moroder.
This was Moroder’s first hurdle in setting up an org-wide system. “If I say, ‘Hey, can you rotate out one of your best engineers?’ The immediate reaction from any manager would likely be, ‘Absolutely not. I need to meet my goals,’” she says.
Here are the two conversations Moroder had with managers to change their minds.
Conversation #1: If you can’t give away your best people, that’s a succession problem
First, Moroder encouraged managers to give away their people.
The first big project that Moroder staffed up through rotations was for a massive technical undertaking: modularizing the monolith. So she needed the company’s sharpest engineers on the case.
“We weren’t going to be able to solve this problem without our most tenured and experienced people,” she says. “So I went to my managers and said, ‘All right, who’s the one person on your team who you can’t afford to lose?’ And they all named someone. So I said, ‘Great, give them to me.’”
If managers were reluctant to rotate out their domain experts, Moroder made the case that no one on the team should be irreplaceable. “If you can't afford to lose someone on your team, that's a succession issue. You need to figure that out,” she says. “The monolith is like the city center. If you’re not sending your domain experts in to make our primary codebase better, you’re just making it harder for yourselves.”
In turn, she reminded managers that the give-and-take nature of the rotation system meant that their teams would eventually get great talent in return. “This was the first step to building trust with other managers. If you give someone away, you’ll get good people back. We have to hold each other accountable to that,” she says.
Moroder understood she’d need to set a good example of that accountability herself. “It’s important that I model this behavior to my managers,” she says. “As we’ve grown, I’ve given away many of the teams I started — the Monolith Enablement team became part of our Platform org, and the AI Enablement team just recently became part of our Data org.”
And when former reports go on to work for other teams, Moroder already has rapport with them when it comes time to collaborate again. “What I didn't expect is that there’s actually a self-serving benefit to giving your people away. When those people shift from your management chain into your collaborators, it’s so much easier to get stuff done because you’ve already built that trust with them.”
If you want to be a really good leader, you need to uplevel the whole org, even if it means sending your best people away.
Conversation #2: This is a group project, and we need to get an A
The other manager hangup Moroder confronted was a question of loyalty: Most managers feel a stronger sense of duty to their direct teams, which can make them hesitant about cross-org collaboration.
“I told managers this: ‘Your primary team isn’t the engineers you manage. Your primary team is each other,” she says. “That’s the level you need to operate on. Your scope just happens to be the team you manage today, but that doesn’t mean that will be your scope in the long term. So you need to work with all the other managers.”
That wasn’t always an easy pill to swallow. So Moroder leaned on a classroom analogy to plead with managers. “I’d always tell managers that we’re working on one big group project. And I want an A,” she says. “It’s just like school. You're sitting with this team of four people at any point in time. Who those four people are doesn't matter.”
Our org needs to get an A, even if that means one manager taking on more for certain projects — because eventually we'll uplevel the whole org.
Vet for team players in the hiring process
Moroder notes that some managers will be tougher to convince, but that reluctance often reveals something larger: a tendency toward factions and playing politics. So getting managers on board with a rotation program ultimately starts during the hiring process.
“One of our core values at Checkr is humility. So some of our interview questions are designed to find people who aren’t going to fight to protect their Legos,” she says. “I look specifically for people who care more about walking straight into the mess and cleaning it up. That’s the type of leader I want.”
That’s in part because of the nature of the product work Moroder is tasked with overseeing. “I'm managing the core screenings and their supply chain. We're not building new things all the time — we're usually trying to fix what exists. So I need people who care about cleaning up the mess, whatever that takes” she says.
To screen for managers with low egos and a bent toward collaboration, she asks these questions to manager candidates during interviews:
- What are you cleaning up right now?
- How do you handle quality?
- How do you handle technical debt?
- Give me an example of a time when you had to help someone else out.
WRAPPING UP: DON’T STOP ASKING, “WHAT’S YOUR NEXT CAREER HERE?”
Moroder isn’t naive in thinking the engineers in her org will stay forever. “It’s a pretty tenured team at this point. So I know one day, people are going to leave,” she says.
But in the meantime, she’s resolved to help folks chart new paths within the company. “We’re continually asking our engineers, ‘What’s your next career here?’”