Krishna Esteva

You’re the PM on a big new feature, everyone is excited about it and you know it’s going to be great. You’ve rallied the team and they’re pumped to be working on this cool new project. Your boss asks you when you think it will ship. You hate giving a firm commitment this early, but it’s a high profile feature so its unavoidable. You talk to the eng lead and he thinks it will take 2 months.

This is not your first rodeo, you know how this goes, especially with something big and new. You go back to your boss and tell him three months — it will be live by the end of next quarter — that gives you lots of cushion and don’t they always say “underpromise and overdeliver”?

Week 5, you run into your first sign of trouble, the API you’re working with turns out to be more complicated than the documentation made it seem. You wish you had known earlier, but that’s part of the product development process. Isn’t this what Agile is all about? You’re 2 weeks behind schedule, but not too bad. You’ve baked in a month of cushion so you’re actually 2 weeks ahead. Damn you’re smart.

Week 9, feature looks like its almost done but not quite, just a little bit of polish left. QA starts end-to-end testing. It. Is. Buggy. First time all the pieces are working together and you’ve got problems. Stress levels are starting to go up, the team feels the pressure. Everyone is staying late. You’re getting slacks on Sunday morning. You start managing your boss’s expectations. Might be running late, but what’s a 2 week delay on a 3 month project?

Week 12 — your original deadline. Most of the bugs are gone but one of them isn’t. It’s an issue caused by the API, a workaround is going to take another 2 weeks. Do you ship or do you wait? Bug is a dealbreaker, you wait. You missed your quarterly deadline, you’re stressed. You boss says it’s fine but you can tell he’s disappointed. It means you’re both missing your OKRs.

Week 14, your workaround is taking longer than expected. It doesn’t help that one of your engineers is out on PTO. He’s still working, leaving his wife on the beach in Hawaii while he codes in the hotel room. You can feel the stress continuing to ratchet up. Your boss feels the heat too, asks you to schedule a retro to find out what went wrong.

Week 16, almost done but new bugs keep popping up. You triage. Aggressively. You’ll fix a bunch after launch. Didn’t Reid Hoffman say “If you’re not embarrassed by the first version of your product, you’ve launched too late?”.

18 weeks in, you finally launch. Thank. God.

Lots of bugs in the backlog, but hey, you checked the launched box. You burned through a bunch of goodwill in the process and the team is feeling tired, but it was worth it, right?

Wrong. You’ve lost the team’s trust. Next time you ask them to estimate, they’re going to sandbag. You’ve also lost some of your social capital, it’s going to take time to rebuild. Next time you need a favor, you’re a little less likely to get it.

And all for what? Working extra hard might have bought a few extra weeks. If that. You’ll probably lose those two weeks on the next project which will now take longer.

Photo by chuttersnap on Unsplash

What went wrong?

So how did you end up here? What went wrong?

Was it bad planning? Not in this case, the main delay was getting burned working with a new API and running into a few more bugs than expected. Some of it could have been anticipated but mostly, these were just issues that come with a new feature launch. Software development is unpredictable, it’s hard to forecast big new uncertain things.

Was it not breaking down the feature into smaller pieces? Not in this case, sometimes there are features that need to be launched as a cohesive whole. Having smaller shippable increments is great, but not always feasible.

Was it setting a date? Not in this case, dates are helpful for planning. There was even a month of cushion. Some organizations avoid dates altogether, but in most cases that’s not the right answer. Especially if there’s cross-functional dependencies like marketing or sales.

Was it setting OKRs? Not really, it’s helpful to set goals. Done right, they can drive accountability and alignment and make sure teams are working on things with the right level of urgency.

The problem was incentives. The organization focused too much on product outcomes and not enough on people outcomes. While the team was accountable, they were only accountable to one thing — whether they shipped. They were accountable for what they did, but not how they did it. If instead this organization measured success using both product outcomes and people outcomes, then the PM might have recognized he was pushing the team harder than he needed to and taken his foot off the accelerator. Launching a little later, but with team trust intact. Instead of feeling like a failure, it might have felt like a success.

Balance business outcomes with human ones

One common challenge with the way goals are often done is that they focus only on what’s easy to measure. You end up focusing on tangible objectives like revenue or whether something shipped. As a consequence, the old adage of “what gets measured gets managed” comes true. The downside to this is that the things that are easy to measure are only half the picture. It’s possible to miss your revenue targets but still be on the right track. It’s possible to hit them but do it in a way that hurts you long term.

More problematically, some of the most important things for a team’s success — things like psychological safety, trust, and motivation — will take a long time to show up in a quantifiable way. It’s not until people are quitting or you’ve missed your targets for several quarters in a row that you notice you’ve lost those things. At that point, it may be too late. If you focus too much on the measurable, the soft side of management gets deprioritized in favor of more tangible and quantifiable organizational objectives. It’s natural to give up something abstract to gain something concrete, even if it ends up being more expensive in the long-term.

The best way to counteract this is to gauge success using both easy to measure business outcomes and harder to measure organizational ones. Pay attention to how people feel not just what they deliver.

This doesn’t mean sitting around singing kumbaya all day and giving everyone a participation medal. It’s not about just focusing on the human outcomes at the cost of business ones. It’s about finding the balance between the two. Sometimes, it might even make sense to push the team harder than is sustainable to achieve a short-term goal. You’re running out of runway and need to hit your numbers so you can raise your next round. You want to make sure a feature makes it out in time for DreamForce. You’re going to lose an important partner if you can’t make a deadline. In those cases, pushing hard might make organizational sense, but those tradeoffs should be made intentionally and not implicitly because you gauged success solely using the things that are easy to measure.

The right middle ground is to measure teams both on what teams accomplish and how they accomplish it. Hold them accountable not just to business outcomes, but organizational ones too. You need to counterbalance the natural gravitational pull of measurable outcomes by consciously paying attention the hard to measure ones too. Even if you can’t quantify it, if you spend some time becoming employee obsessed you can still get a handle on how teams are doing. If you pay attention to these important intangibles, then you’ll see huge benefits to your organization. Ignore them, and you’ll get a short-term boost but likely pay a much steeper long-term cost.