Hero culture won't save your quarter

Way too often, teams discover days before the end of the quarter that sh*t hit the fan.

Could they have known earlier? Absolutely.

But, it’s often a mix of hero culture and poor tooling that leads to situations where harsh realities are “delayed”. Let me explain.

When hero culture becomes harmful

Take 30 seconds to watch this video where Adam Grant explains why it’s dangerous for leaders to tell employees “don’t bring me problems, bring me solutions”.

It feels like the right way to challenge people to become problem-solvers rather than problem-complainers. But the issue with that approach is that you’re basically telling your teams that you don’t want to know about any negative signal until they have figured it out.

So what happens then?

Well, your teams will hide problems until they feel like they’ve figured things out. That’s not a big deal for trivial issues, but there will be many challenges requiring inputs from other teams and leadership. So now, you’ve got people desperately working through the quarter trying to solve a problem by themselves because you told them to. And the truth will only surface at the end of the quarter when people can no longer pretend to be confident.

Hero culture must go.

A better quote to use would be this one from Warren Buffet:

“It’s much easier to stay out of trouble now than to get out of trouble later”.

In other words, take care of problems while they’re small. For it’ll cost you a lot more to fix things once they become huge incidents. For teams this may mean:

• Patching code before vulnerabilities are exploited
• Seeking negative user feedback before they churn
• Testing your disaster recovery plan before an actual disaster happens
• Keeping an eye on your runway before it’s too late to go fundraise

And from a strategy perspective, it means knowing as early as possible when things are starting to veer off track. An early negative signal is productive. It means that there’s something that we can improve – or that we’ve established a strategy with incorrect assumptions. In both cases, we’ve got something to work on.

Detecting trouble early – start by identifying what matters

A requirement to stay out of trouble is to be able to identify early signs of complications. For instance, engineering teams usually have monitoring systems in place that alerts them when thresholds are crossed. But, while it’s fairly easy to instrument software and keep an eye on metrics, it’s not as straightforward to do for strategy.

First, you need a clear set of goals. There are many things that can go wrong at any given time, and you need a simple system that will help you judge whether or not the problem you’re looking at is important.

Ex: if your product is currently in a free beta with less than 100 users, it’s not going super critical to think about the scaling issues you’d have with 100,000 concurrent users. Your #1 priority should be to have product-market fit.

So, how do you set clear goals?

Keep it simple and adopt OKRs. It’s not a perfect framework, but it’s simple and widely used (if you want something else, check these alternatives). The advantage of using OKRs is that (1) you’ll have a common language for focus, and (2) there will be a clear list of goals to achieve by the end of the quarter.

Progress on these goals will become the signal to monitor. And this is perhaps what’s different about how I think about goal-setting frameworks. Some may think of it as a reporting-to-management activity. I prefer to see this as a hybrid health monitor / smoke alarm.

Having determined a set of goals isn’t nearly enough. You need a process in place to know how progress on achieving said goals is going.

Detecting trouble early – a simple system to monitor progress on strategy

It’s one thing to agree on your objectives and key results. It’s another to know if you’re on the right path to success. If you don’t have a weekly team catch up, I’d encourage you to adopt the following routine:

• Monday: meet as a team review progress on OKRs (updates should be written before the meeting). Adjust roadmap if necessary
• Monday-Friday: work on projects
• Friday: demos to show what’s been accomplished

Repeat this every week until the end of the quarter. You’ll quickly notice around the 3rd week that people will have a better sense of urgency and decisions will be made much faster.

But, where will you record the progress updates?

If you’re new to OKRs and goal-tracking, I’d recommend that you start with a simple spreadsheet or doc. The tool will feel familiar while you learn how to set good goals and put the rituals in place to track and discuss progress.

The downside of using a spreadsheet is that it’s fairly easy to obfuscate the truth. Without seeing progress trends you have to fully rely on the confidence status set by the team (red, yellow, green).

But what if your team is scared of telling you the truth?

Thing may look 🟢 when looking at a line in a table, but the progress chart might tell us a different story.

If you’re serious about putting goals at the centre, then Tability is for you. As you can see in the video below, it’s purposely built to track team goals and OKRs, and it will provide you with a complete set of dashboards and automations to understand the health of your business.

Put out fires while they’re small

If there’s one thing that you should take away from this post, it’s that it’s much cheaper to address issues while they’re small.

And, the best way to do that is to empower your team to signal problems early. Of course, they shouldn’t stop there, but the earlier knowledge is shared, the easier it is to fix things before it’s too late.

Tooling will help (and I’d be super happy if you pick Tability), but more importantly, you need to have the right culture. Talk to the folks around you, and make sure that they feel comfortable enough about telling the truth.

That’s the best way to avoid seeing everything turning red a week before the end of the quarter.

‍