TBM 15/52: Stop Hiring Things to Do Too Many Jobs
Here's an anti-pattern to watch for:
Hiring a process, tool, framework, or label to do too many jobs.
A team starts using OKRs. You ask them "why have you decided to use OKRs?" They explain.
Well, the OKRs will help us set goals. Oh, and they will help us track our progress! Accountability, right? And alignment of course, and keeping score. Objective grading is part of it. And autonomy when a team sets good ones.
The way they work also lets you set stretch goals. Be audacious! It is all about learning and reflection, of course. Failure should be an option. Finally, if you get them right, they let you convey a clear vision to the rest of the organization.
That is lots of jobs. "Lots of bang for our buck!" you might say. I'm not so sure.
The problem with something that does lots of jobs is that it is very easy to send the wrong message. Say someone joins your company. Do they pick up on all the nuance? Do they know they can fail? Pivot? That it is about "keeping score" but in a healthy way? What exactly does "stretch" mean? "Wait, why are we using OKRs again? Does anyone even remember?"
This principle also goes for artifacts you might use at your company. I was in a meeting recently, and I watched as the team discussed a label given to a certain segment of customer.
I wrote down the various "jobs" for the label:
Targeting criteria for sales (e.g. target X companies)
A distinction for goal setting (e.g. "activate X orgs")
Segmentation to apply internal CSM/Support playbooks
A way to "size" our addressable market
Tool for prioritizing enhancements (e.g. "will this help X?")
A target firm-persona when thinking about design decisions
Strategy shorthand ("the X strategy")
That is 7 jobs. And I stopped counting. The problem? It is unlikely that the label will be effective at all those jobs. And very easy to attach even more meanings as newcomers get introduced to the shorthand. Communication is hard enough for even more narrowly defined concepts!
So here's the lesson. Always ask "are we overburdening this?" Think about running this test: if you asked "why are we doing this?" to ten people, how convergent would the responses be? Too much divergence? Narrow.
Having a tool that can help support certain jobs—or declaring that it ought to be used for them—is so easily conflated for being equipped to make real progress there. Hiring that tool without a shared baseline on its and purpose and our practices is a great recipe for divergence. And it seems that OKRs are an especially pernicious shape-shifter without rigor-in-use and clear boundaries on their purposes.
Great post again John. The fear though is that simply more tools will be created to distribute these jobs. So instead of a few clear OKRs where teams focus on, we might see more OKRs for teams to be committed towards org's desires to get more "bang for buck".