OKRs, goals, and growth
In 1975, Andy Grove of Intel invented a system to measure performance. Fifty years later, we’re still trying to make the damn thing work right.
Let’s talk about why and how it works here at Atono.
Why Atono exists
We started Atono to help teams build software better, together – implying it ain’t great today. That’s our mission, it’s why we’re here.
But that statement is too vague. It doesn’t really spell out what Atono does.
To get more specific, we go a layer deeper into our vision, or what we aim to achieve someday. Our vision is to build a software application that supports all disciplines in the Software Development Life Cycle, reflecting and promoting agile best practices.
That’s helpful, but where is Atono heading? And how will we get there?
Well, in 25 years (arbitrary number to say a long time from now) our big, hairy, audacious goal (BHAG or “bee-hag”) is to become the most widely used platform to plan, build, run, and support software.
How will we do that?
-
Start small and scale.
-
Maintain an open, honest business model (no games, no tricks).
-
Involve our customers in the design and creation of our products.
-
Keep our code clean (no acquisitions or bolt-on code).
-
Incorporate AI as an inherent capability throughout our products.
-
Provide applications for each development function on a common platform.
-
Grow thoughtfully into the large enterprise market.
-
Give products away to those that we shouldn't be profiting from.
-
Be known as a great place to work so we can attract the best people.
Enter OKRs
The idea of an Objective is to declare what we are trying to achieve during a period of time. We need to measure the before and after to see if we are making progress (K=key, R=result).
Here are two examples of OKRs:
- Improve system availability from 99.95% to 99.99% within six months.
- Finish the new AI feature.
#1 is a body of work we can rally around. What ideas do we have? How are we time boxing the work? Can we rank them based on likelihood, risk, and effort? Low hanging fruit? Can we start experimenting and measuring success as we go? So – yes, we can do all those things.
#2 is not really an OKR. It’s a project. Is the AI feature valuable? Do customers like it? Does it work? Does it impact sales? Who knows, and I guess who cares, otherwise we’d write the objective more clearly.
Now, where do I go from here? If my team had OKR #1, we’d use this as our North Star to brainstorm, build epics or stories, design experiments, and more. This objective would shape our work within the allocated time box or investment level. Throughout the year, we’d perform the tasks, measure our results, and decide to keep going or stop.
As we start working on the project, suppose we find that improving system availability from 99.95% to 99.98% requires just 10% of our effort, but boosting 99.98% to 99.99% demands 90% more effort. In this case, we should challenge whether achieving 99.99% is necessary this year – perhaps 99.98% is good enough now.
Annual process
-
No more than three objectives, two is preferred.
-
If you can't state the objective in 10 words, keep editing.
-
Binary (done, not done) is ok, but not great.
-
Progress measurement is better (was 35% month 1, 40% month 2, now 64%).
-
When it's close enough, move on – don't be a victim to an OKR.
-
If you hit diminishing returns, find out if we can stop at “good enough”.
-
We get paid for providing an awesome service to our customers.
-
We create long-term value by hitting our OKRs because they help us get closer to our BHAG and you are a shareholder, so...
If you don’t know where you are going, it doesn’t matter which way you go.
All of this scaffolding is to help us stay on the right path. Our priorities will change over the years, but our ultimate destination remains the same.
Don’t be intimidated by the vernacular. We have a north star.
We will get there by staying focused on helping our customers solve real problems. Each year, quarter, month, and week, we’ll ensure what we do aligns with what will deliver success.