OKR - Objectives and Key Results
Plenty of companies have chosen to use OKRs as their planning tool. Each team publishes a set of OKRs at the beginning of a quarter to signal to the rest of the company what work they intend to do. This is written in the form of an Objective (Eg: Make Builds Faster). Then comes the Key Result which is usually expressed as a measurable metric (eg: Reduce build time by 25%).
As an engineer in the devtools team, I know a set of ways to make this happen and I am all set to execute on them.
There are a few low hanging fruits that will take me an afternoon to implement which will speed up builds for 50% of our users. But before I can work on them I need to establish the baseline build time so we can measure the before and after effect of the change.
Unfortunately measuring build time across the fleet is not an easy task since there are about 75 teams that maintain approximately 600 build jobs across 4 different languages. So instead of shipping a fix that could benefit half the company I’m building a foundational service to measure the build times. This takes me anywhere between 1 to 2 weeks to complete.
One could argue that building the foundational service will help accelerate future development and I’m short sighted for not seeing those benefits. I would argue that this service will be used exactly once when the manager writes the end of quarter accomplishment to show that we indeed saved 200 hours of developer time and compute time. In fact, maintaining and updating that service now falls on the shoulders of the engineer who built it to measure that vanity metric.
Data driven decisions only make sense when the results are ambiguous. They become a hurdle when the decision is clear and obvious.