How do you incorporate OKR in a organization structure where all teams constantly work in customers projects? How and when can they find the time for OKR?
For service companies, you usually have two sets of OKRs. One internal and one for the client. Internal OKRs may measure success factors like profitability, employee satisfaction, and retention. Client focused OKRs can measure the value the client is expecting with that engagement. In IT service companies these can be based on engineering metrics like lead time, code test coverage or number of bugs. While client focused OKRs begin and end with a project, internal OKRs are focused on the service company itself, so they can be quarterly.
How can we adapt OKR framework in a machinery business? I understand that OKRs work well for startups and internet businesses. But our products have 2-3 year development cycles and we are in B2B. So per definition, we are a little less agile than other types of industries.
You can use leading indicators of future product success. No company should go 2-3 years without feedback. You can for example measure the results of simulations, customer interest and feedback or usability testing.
You may also work with process improvement techniques to reduce product development cycles and Lean Startup to test hypotheses faster. OKR is about measurement. It doesn’t need to happen after the product launch.
What are the most important communication formats throughout the OKR cycle? What are the conversations we need to have and are there any best practices?
The most important ceremony is the weekly Check-in. In my experience it is an absolute must have, even if it only lasts 15 minutes.
How can we ensure the buy-in of engineering teams that are already working agile. They have concerns agile goal management with OKRs might collide with their processes.
If Agile teams do not see value in OKR, it is usually because they are using tasks as OKRs. This is redundant with the Agile backlog, so the teams complain. And they are correct.
How do you ensure “Business as Usual”- KPIs are maintained when typically you raise a lot of focus on the “project” OKRs. Do you ever have an OKR “maintain BAU KPIs”? In other words, do you typically build that in somewhere in the OKR system, or just assume the business will continue to keep its BAU KPIs at the right level?
In general, there is no such thing as a KR that lists a series of KPIs and any mature service company understands it has to measure its business metrics. The distinction between OKRs and business as usual metrics is artificial and ads no value, in my experience. In the end, everything a company does is to improve its business fundamentals. The core set of metrics for that business model.
How can we engage colleagues with a high ratio of daily business like in accounting or sales? We find it difficult to set goals with them while acknowledging that they are focused on their operations and don’t see value in checking in the OKR process weekly.”
The key is the last sentence: they do not see the value. Good sales teams already have clear goals and tracking cadences. They measure the sales funnel regularly. For them, a lot of the value will come from the alignment step, to ensure that theother teams are working together. Check out the Set-Align-Achieve cycle: felipecastro.com/en/set-align-achieve
As for accounting and finance, they usually include lots of SLAs (Service Level Agreements) in their OKRs. An example of that might be “Reduce time to process expense reports from X to Y days”. Finance OKRs tend to be focused on efficiency.
In case our sales teams then recognize their benefits with OKRs, do you recommend to include operational, non-strategic goals in their OKRs?
They could create a shared OKR with marketing for example, that included several steps of the sales funnel, ensuring alignment. There is an article of a former Googler about this: felipecastro.com/en/blog/tips-ex-googler-shared-okrs
We are usually insisting that an OKR has a clear owner. Even if goals are shared, there needs to be someone who feels responsible. Do you agree with this or are you happy with fully equally shared OKRs?
The concept of a shared OKR is that it creates a virtual team that shares responsibility for a goal. If they don’t share responsibility, they will not share engagement as well. But we have to be careful to avoid diffusion of responsibility. If there are too many people involved, no one will care. That is why shared OKRs should be about small teams. Break the OKRs until you have smaller teams.
Are there any proven approaches that help an organization to move from the annual performance and review process to a more agile system with OKRs? What advice do you have for enterprises that are worried about the extra effort and about letting go their old processes. Can the processes maybe be merged?”
You should always first run a pilot with OKR and after you have learned the fundamentals, you should customize it to your context. Your company is not Google, you don’t have to copy them in everything.
If you would like to participate in future OKR Office Hours with leading experts, feel free to join the OKR Online Community: workpath.com/community