Cutting Your Losses

There are many ways you can find yourself solving the wrong problem. One of the more insidious is if you come up with a good plan which hinges on reassessing when you have more information. So, you start work… only to fail at everything you try. Eventually the cost of all those failures adds up, but you still don’t have the information you wanted before deciding what to do next.

Because of unknowns, avoiding solving the wrong problem is often less about the initial decision, and more about deciding when to cut your losses and move on to the next thing.

The insidious part of many of these situations is recognizing when what seems like “no new information” actually does add up to new information. It is notoriously hard to estimate how long R&D will take for example. If you start with 10 viable ideas and have only worked through 4 of them, it seems reasonable to try the other 6. But at some point, the fact that you’ve had 4 failures makes it less likely any of the 10 will ultimately work. In a fundamentally limited world, it often makes sense to pivot to some other project instead.

On the other hand, we often make promises to stakeholders based on our initial plans. It can be hard to know when a change of focus will be seen as being a good steward of the organization’s resources instead of an admission of failure. Ideally, we would share at the outset that something is R&D – with all the implications of risk that carries. But people often forget even if we do a good job up front stating the caveats.

Similar to lack of success, there are other subtle kinds of information that may crop up over time. In working with a client recently, they brought up that they are frequently trying to get to market quickly with new products. At some point the original business case for that new product starts to erode if their competition gets to market first. But unless you have a system to update the business case over time, it’s easy to miss.

One technique that works fairly well is having regularly scheduled check-ins. Having a demo every two weeks is typical for Agile projects. As a consultant I also often have recurring meetings which give everyone a chance to discuss priorities on a regular basis. Those touchpoints can help, but when things aren’t moving from in-progress to complete (again, common for months at a time in R&D type work), it may not be clear what needs to change except “something.”

Lastly, as leaders, there is often also an element of personal responsibility. If my team isn’t delivering, did we have the wrong goals, or are the wrong people working on them? Delegation is key to leadership, but it is both frustrating and leaves you feeling a bit helpless when you try to figure out how to turn around a team that’s underperforming. This can also be a big area of opportunity – if you like the team you’ve got, find the projects they can knock out of the park.

At the end of the day, we all want to cut the losses if it makes sense to do so. Whether we went into a project well aware it might not work out, or just realize our mistake along the way, it is vital to recognize if the time has come for a change.