On OKR: Managing challenges and successes
SGEM is a small group of Engineering management professionals who meet up on a regular cadence. to learn from one another. On the 3rd of July ’18, the SGEM people met up to discuss about the challenges and successes of OKR adoption in Engineering team (and beyond).
This entry captures some dialogues we had and provides some afterthoughts from the author (Yuen-Chi Lian, YC) after more than a quarter since the meeting. The attendees were Chew Chee Ming (CM), Ping (CP), Sunny (SS), Swayam Narain (SN).
These topics were proposed for a deep dive: Getting buy-ins (CP), trickling down OKR to individuals (SS, CM).
On getting buy-ins
Perhaps, during early implementation, OKR could stop at engineering managers’ level, shielding engineers from unclear implementation, esp. for a fatigued team that is demotivated by firefighting and performance issues.
This view is only supported by half of the group, esp. from SS: “the whole ship needs to follow a single direction”. Managers should work on improving the clarity of objectives and use that to create alignment, rather than avoiding the responsibility. Other tools such as creation of dashboard to visualize numbers (e.g. revenue), or to use personas to build empathy for customers, will help engineers to understand their role and impacts to the business.
After thoughts: The purpose of OKR is to create focus and be very committed to it, as a team. Shielding the engineers from OKR doesn’t protect but actually jeopardize the business. It will take many iterations to sharpen your implementation, so starting small (by being selective on the smaller teams to engage with) and scale adoption incrementally with results (e.g. with Kotter’s 8-step process) may be a good way to go about it.
On trickling down to individuals
An objective could be a creation with the higher objective (from the top) in mind, or simply a copy of the higher objective with set of key results specifically supported by the function (Engineering in this case).
An EM could approach individuals with an objective, and leave the formation of key results to them. These objectives could be improvement or roadmap items, which will eventually be placed in the backlog, but they have to be aspiring and not to be confused with key results.
There was a conflicting view on whether it is valuable to have individuals owning OKR vs. the team. Some thought the XP value of collective ownership conflicts with individually-owned OKR.
After thoughts: One main job of EM is to build tooling (SS). So, testing and figuring out the right tools to make the communication and tracking (one of the 5 superpowers John mentioned) easy will help to cut it for the engineers. As mentioned earlier, it takes iterations to improve your implementation, So, turning a top-down framework with strong bottom-up participation (which John said, a 60% of bottom-up is a success) is a matter of time by sticking to and refining it.
