I regularly cover the tactical techniques teams need to practice in order to work successfully with OKRs. This week, I am going to start a series of posts that take a look at what it means to lead organizations that use OKRs. While getting your objectives and key results written correctly and in a way that could positively impact your customers and your business is no simple process, that is only the beginning of your journey. The way you lead also needs to change. This first post is going to cover trust.
We’re used to prescribing solutions
The overwhelming majority of leaders I work with believe it’s their responsibility to tell teams what to do. For decades this has manifested as prescribed features with fixed deadlines that often come with at least some, if not a lot, of detailed design direction as well. If we’re writing our OKRs correctly the goals we’re setting don’t have explicit features mentioned in them. In essence, we’ve removed the prescription.
While prescribing work for our teams provides leaders with the confidence of knowing what the team is working on, it also makes it explicitly clear that these same leaders don’t trust their teams to decide on their own. When that prescription contains explicit details that cover the work of product managers, designers and even software engineers, that trust is further eroded.
We hired smart people, now it’s time to trust them
As leaders, one of our core responsibilities is to hire well. I’m going to assume you’ve done that. So why would we then make technical, discipline-specific decisions for the smart people we hired? OKRs help us get past that but not without an explicit recognition that detailed prescription is no longer part of your job. It’s the team’s job now to create hypotheses they believe will help them drive the behavior change in their key results. It’s their job to test those hypotheses and decide if further investment is warranted or if a pivot is in order. It’s your job to trust them to do that.
Your job as a leader remains to provide clear strategic direction for the team, guidelines, constraints and to help them make decisions and course corrections when the data is unclear. You may have a background in design, product or coding but you left the tactical portion of that work behind when you went into management. Give your teams the trust they deserve to do the work you hired them to do. The passion and energy of coming up with and then implementing your own ideas cannot be replicated for ideas prescribed by the boss
Your teams don’t get this trust for free
One of the benefits of prescribing work for your teams is that you always know what the team is working on. After all, you told them what to do. If your boss asks you what your teams are up to, you always have a clear answer. When you hand over trust to your team to decide what to work on you may find yourself in a panic when the boss comes around asking what your teams are doing and your only answer is ¯\_(ツ)_/¯ . Clearly that’s not an acceptable answer. And it’s right at this moment where the urge to micromanage stings the hardest.
Instead of micromanaging, put the onus on the team. Make it clear that you are trusting them to make these decisions but that you want to be kept in the loop. Demand radical transparency. This means your teams should communicate (or even over communicate) regularly and frequently to you about:
- What they’re working on
- The progress they’re making towards their OKRs
- What they’re learning
- What they plan on changing based on that learning
This doesn’t have to be a heavy piece of work. Instead, this could literally be an email with the four bullet points above in the body. This way you always have a clear assessment of what the team is doing, the urge to prescribe and micromanage is diminished and, if you do find something worth discussing with the team, you can get involved before the idea gets too far downstream.
Making OKRs work as a leader is a two-way street but it starts with trust. It’ll take time to find the right level of communication detail that ensures you get the information you need and the team gets the bandwidth it needs to do its best work. Regardless of how you solve for it, without this trust OKRs stand very little of succeeding. The slide back to fixed time, fixed scope output production is all but assured.
Comments are closed.