Last year I had read John Doerr’s book “Measure What Matters.” For those who are hearing about it for the first time, the book is about Objectives and Key Results (OKRs), a data-driven objective tracking approach that he introduced to Google. OKRs were invented by Andy Grove at Intel and documented in his seminal work “High Throughput Management”, but received the most hype due to Google.

Update: A lot has changed since 2019. Among other things - it also changed how we track OKRs with Phabricator. We stopped using the complex project / milestone approach described below and stuck with a bunch of subtasks.

I will not be explaining OKRs, there is a guide from Google and a very good talk by Google Ventures that I always recommend to everyone who’s interested:

What I really want to write about is a setup for tracking company and team level OKRs. I have recently tried it and it worked with a relatively small team that was looking for a process to establish focused sprints of work.

One of the problems I had in the past with OKR tracking was the fact that they were not directly linked to my day to day work. I would establish my objectives and define key results, but they would be stored in one system, whereas the day to day tasks which lead to the key results would sit in another system. This, in my mind lead to some issues.

OKRs, by definition, are a tree structure where information flows top-down and bottom-up. So any bottom level task should be traceable up to the exact team objective or company key result. Likewise, any company level objective should provide visibility as to who is working on the nitty gritty of it and the amount of work that is happening.

Being able to trace tasks from the volume of work to the OKR itself is not critical, but it helps with engagement by providing visibility into how day to day work plays into the bigger picture.

Enter Phabricator - my favourite swiss army knife suite of tools for, but not only for, engineering teams. Having recently set up OKR processes for a small team, I opted for this setup:

1. A top level project named OKRS - this is not used for much, except as a container for OKR sessions.

2. A sub-project for individual OKR sessions, say 6 weeks, with an incremental counter. For example: OKRS1 for session one between Feb 1st and March 14th, OKRS2 - for session two between March 15th and May 1st.

3. Each session uses milestones to establish objectives. Keeping the name down to one or two words and expanding in the description increases clarity.

   

4. Key results for each objective are put in the respective milestone column as tasks.

   

5. Team takes and breaks these down into nitty gritty tree of subtasks required to get the key result. This can go as deep or as wide as needed.

   

This does not follow OKR prescription to the dot and on its own it is nothing particularly remarkable, but with other applications in the Phabricator suite it integrates with and a small team size it works sufficiently well without requiring to pay for some dedicated product.