Open menuChaptersChapter 11

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?

Over the next two and a half decades, we know we'll need some operating principles. At times some of these will be critical, and other times not important at all. So, we'll have to pick two or three each year to prioritize and work on. They include, subject to change, the following: 
  • 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.
Now, we have some more clues. We know why Atono came to be. We know what Atono is building, and we know that the people at Atono are daringly ambitious!
This is all helpful, but it doesn't tell me what we're working on this year, or even what I should focus on tomorrow. I'm not sure which tasks are a priority and which are 'nice to haves'. So, how do we tackle this?

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:

  1. Improve system availability from 99.95% to 99.99% within six months.
  2. 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

Each year we'll set two or three goals for Atono. Each team reviews the goals, roadmaps, and inputs, to set team or individual OKRs. Now, there are many ways for this to go wrong, so we have some hard and fast rules of the road:

Less is best
  • No more than three objectives, two is preferred.
  • If you can't state the objective in 10 words, keep editing.
Must be measurable 
  • Binary (done, not done) is ok, but not great. 
  • Progress measurement is better (was 35% month 1, 40% month 2, now 64%).
Always use your judgment
  • 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”.
You don't get paid for OKRs
  • 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.