Debugging engineering teams: Groundhog Day

Have you ever been on a team that seemed to work very hard but never move forward? Where you look back quarter after quarter, or perhaps year after year, and you did a lot, but nothing actually seemed to happen?

Congratulations, you’re in the middle of Groundhog Day.

Groundhog Day (or perhaps Russian Doll, if you want a more modern reference) is the experience of doing plenty of work to move forward, and yet never quite seeing lasting change from that work. You feel busy but stuck in place. When you look back at the quarter, the past six months, or (most commonly) the year, and realize that you set a lot of goals, and even reached many of them, yet nothing feels different, you’re stuck in Groundhog Day.

The symptoms of Groundhog Day

The team is busy. The problem is not that the team isn’t engaged. They’re engaged. They are showing up and doing things every day. They may even be shipping features and completing projects. But somehow that work never seems to result in meaningful forward progress for the product or company.

No one agrees on what the strategy is. Sure, the work the team is doing doesn’t seem to change the business, but one thing does keep changing: the strategy. Depending on who you ask, when you ask, you will get a different answer. You don’t really know where you’re going, and you keep changing your mind.

The solution is always just around the corner. Once we finish project X, things will be better. Once we sell to client Y, we’ll be set. Once we hire key hire Z, things will really take off. It’s no wonder things feel like Groundhog Day because no one has bothered to figure out what is wrong enough to dig in and fix it, and they are always betting the change will come from the next silver bullet.

Groundhog Day is a common symptom, but one that can have several different causes, such as:

A lack of long-term strategy. I guess you could see this one coming. If you really don’t know where you’re going, it’s easy to end up in an extremely reactive situation where the goalposts keep moving. And without a clear and concrete strategy, no one feels comfortable building something big and meaningful.

A strategy that changes constantly. Sometimes you see teams launch every quarter with a big new strategy. That big idea everyone was grinding away at last quarter is no longer important because leadership has decided that there’s a new ‘Most Important Thing’ that we must drop everything to pursue. Without a clear and concrete strategy, no one feels comfortable building something big and meaningful.

Too many different strategies at once. Sometimes this happens because there is a disagreement among leadership as to what should be done, and rather than resolving this conflict, each leader goes off in their own direction. Each product manager makes their own choices, engineers build features they think will be cool, and no one wants to have hard conversations and create strong alignment across the different parties. You don’t lack a strategy, but you lack a single, agreed-upon strategy.

Addicted to ‘snacking’. I recently came across the concept of ‘snacking’ in an old blog post by Intercom, which defines it as ‘low-effort, low-impact work’. Teams stuck in Groundhog Day mode often find themselves snacking, working on easy projects that seem like they should deliver quick wins but never actually make a difference. This can happen even when you do have a clear strategy, but it is most common when no one feels safe working on long-running projects because they fear that the work will be wasted after the next strategic change.

A lack of strategic execution. I almost hate to separate execution from strategy, because far too many people think they can be strategic while lacking a plan for achieving their goals. Still, I’ve seen many teams that have a big vision, but struggle to make a plan that will achieve their vision. There is always a reason why the vision hasn’t been realized, but usually, it boils down to a lack of planning. The team may have a great end-goal, but they have no idea which steps will get them to achieve that end-goal, so they meander from project to project without making significant forward progress.

A lack of metrics and accountability. Rarely, this happens because no one is actually measuring the work to see if any of the projects are actually making a difference against your goals. You don’t learn anything project after project, so it’s almost as if each project doesn’t matter at all once it is completed. Without any metrics, you don’t know what is working and what isn’t working, and no one is held accountable for making sure that the work produced is actually meaningful.

Failure to deal with the underlying circumstances surrounding the team. Maybe you have a great strategy, and a decent plan, but your team is constantly getting hung up on the unexpected. Too many outages from the old systems, and too many one-off customer requests. Or, your company is in turmoil, your team has incredible personnel turnover, and you just don’t have enough people who even understand the team’s context working to solve the problems. Again, the team is working hard, and they are shipping what they can with the bandwidth they have, but they don’t have the ability to tackle the big stuff because they’re just too distracted with other concerns.

What to do?

All of these situations have different detailed approaches that you will need to apply to get out of them, but they all start with the same action: slow down.

You need to slow down, and maybe even stop if you want to fix this. Stop keeping yourself, and your team, too busy to think about what’s important. The team needs to sit together and figure out a strategy that they actually believe in. Hold an off-site, and talk about where you want to be in a year or more. Take the time to write down your strategy and use it to set some longer-term goals.

You may decide that you need to stop working on ‘features’ to invest in underlying foundational improvements that will let you do bigger things. Maybe those foundational improvements are stability-related, so you can actually focus on a feature for a period of time without firefighting. Maybe they are a rethinking of the architecture. Maybe the team needs to be restructured to work more effectively. But the only way to get out of a rut of sameness is to do something drastically different, and since your rut involves grinding out work, the way to get out of it is first to stop grinding.

Slow down by asking why you’re implementing a feature, and how you’re going to know if it’s successful, before you ship something. Slow down by looking at the results of that feature and seeing if they matched what you were hoping to accomplish. Thinking of good metrics is hard, and the instrumentation you need to capture them can be a lot of work – but in the case of this team, you need to put these speed bumps in because the team needs to think about why they are building things and what is important. These questions and analyses force the team to do that work.

It’s hard to feel good about pumping the brakes when you’re stressed out about a lack of forward progress, but getting out of this cycle requires you to strategize, plan, and decide – all of which are hard to do if you’re too busy to even think.