Cheat codes

Autonomy is an important element of highly effective teams. As a leader, there’s a difficult balance to be struck between helping your teams get things done and providing the space and freedom that they need to solve problems themselves and own their solutions. Concepts like go slow to move fast can be used to help with this, but even still the core problem remains: how can a leader help teams solve difficult problems without reducing their ability to function autonomously?

Leaders are often in an interesting situation when it comes to solving problems directly. The fantastic book Turn the Ship Around! explores this idea in some depth. Marquet calls this idea “resisting the urge to provide solutions”:

When you follow the leader-leader model, you must take time to let others react to the situation as well. You have to create a space for open decision by the entire team, even if that space is only a few minutes, or a few seconds, long. This is harder than in the leader-follower approach because it requires you to anticipate decisions and alert your team to the need for an upcoming one. In a top-down hierarchy, subordinates don’t need to be thinking ahead because the boss will make a decision when needed.

Providing a solution directly is the easy way out. It’s fast and effective in the short term, but over time it runs the risk of turning the team into blind followers. If you are a leader and have not read this book, I highly recommend it!

Unfortunately, while this may all make sense in theory, it can be difficult to put into practice. Sometimes even expert teams can get stuck - what then? This puts the leader into a conundrum: you want to help the team solve the problem, but you also want them to feel ownership of the solution. You also don’t want them building a reliance on your solutions over time; after all, they must be able to function effectively without you. Partially because it’s the best thing to do for the organization, but also because sometimes you like to go on vacation.

Within the past year I’ve started using a system that I call “cheat codes” to help with this. The core idea is simple: when you’re working with a team to solve a problem, and think that you have a solution, don’t provide the solution directly. Instead, let them know that you believe you have a solution to the problem. It’s then entirely up to the team whether they would like to pursue the solution proposed by the leader or if they would like to spend more time ideating amongst themselves.

Two important highlights:

• The team must fully understand what cheat codes are and why you’re using them. I recommend introducing the concept in a quick huddle, ideally synchronously. Ending a stand-up meeting by introducing the idea could work well too. If you’re someone who tends towards asynchrony, so am I, but a quick live Q&A session can go a long way for something like this
• When you give the team a cheat code, you must be prepared for them not to use it. If it’s important to you that the team uses a specific solution, do not call it a cheat code. Presenting an idea as a cheat code that you really want to be used undermines the entire purpose!

Using the name “cheat codes” isn’t crucial to the idea, but there are a few reasons that led me to prefer it:

• It does a good job of conveying the intent. While cheat codes can be fun (and they certainly speed things up), using them is a short cut. Just as you won’t improve at a video game by using Gameshark, a team should be aware that they won’t be improving their own problem solving skills by using the lead’s cheat codes
• It’s fun. Even in a team with high psychological safety and transparency, it can be challenging for members to choose to forego their leader’s potential solution. Calling the solutions “cheat codes” adds some levity to what could otherwise be construed as “I’m not going to tell you to use this solution - but really I want you to use it”
• It’s easy to convey without ambiguity. Simply say “there’s a cheat code for this problem” and then step away to give the team space to make their decision

I’ve received a lot of positive feedback from my teams using this approach. I estimate that at current, teams decide to use a cheat code a little less than 50% of the time. Ideally, over time that percentage will decrease, as will the total number of times that I’m providing cheat codes.

So, the next time that you’re thinking about dropping a solution onto your team, think about letting them know that you have a cheat code instead. Let me know how it goes - I’d love to know if it’s effective for others.