As startups tend to focus on scalability and profit, often employee goal setting is put on the back burner. But this move can be detrimental to a company, its culture and employee morale. So taking a page from search-engine giant Google, our startup has focused on a new milestone strategy.
Last year, Google Venture's Rick Klau lifted the veil on the internal goal-setting system the internet giant has used since 1999, a time when it was less than a year old and employees numbered in the dozens. The system is called Objectives and Key Results (OKRs) and remains an integral part of Google’s culture -- even as its workforce rises above 45,000.
For NerdWallet co-founder Tim Chen and myself, this process was an eye-opener -- and came at a time when our startup was struggling with growing pains. We had been setting goals on the fly. That’s not unusual for newbie companies, but as we went from two employees in 2011 to 50 last year, it became clear we needed to implement a company-wide goal setting process. That need becomes even more pronounced as we plan to grow to 150 employees this year. OKRs give us a blueprint to do that and have been in a revelation in shaping our goals from the bottom up.
What exactly are OKRs? Venture capitalist John Doerr brought OKRs to Google from Intel. The original slide presentation he gave the Google team in 1999 started with an example of the OKR he set for the talk itself:
- Doerr’s Objective. To develop a workable model for planning as measured by these key results: 1) Finishing the presentation on time; 2) Completing a sample set of three months objectives and key results 3) Having management agree to institute a trial system for a three-month period.
That’s the process in a nutshell. Define an objective and have measurable results toward reaching that goal. So making Gmail a success won't cut it. But utilizing terminology like "launching in September and have a million users by November” will do the trick.
What OKRs are NOT. They are not performance reviews. The traditional performance review process can stifle ambition, as employees set goals they know they can safely achieve.
Employees should not set OKRs they know they’ll meet. If they do, then they’ve set the bar too low (a 60 to 70 percent achievement rate is considered good). OKRs are a transparent guide to progress -- in line with company goals -- that encourages employees to stretch beyond their limits.
Related: Are You a Goal-Getter?
Here is what OKRs should be:
Centered on a few objectives. There should be no more than three to five objectives and between three to five key results to measure each. This is an important forcing function for startups, where the list of things to do can stretch the length of your arm. OKRs help you understand what you should prioritize -- and, equally importantly, what you shouldn’t.
Available for everyone to see. This is another way OKRs are distinct from performance reviews. All company, team and individual objectives and key results are published and open for all employees to see. Then everyone is literally on the same page and understands how their work fits with their colleagues’ goals.
Be omnipresent. If you want all the benefits and the clarity of the OKRs, then they have to be a regular part of your dialogue. This is one area where we fell down the first quarter we implemented OKRs. We rolled it out, everyone got excited about it – and then we just kind of went back to work. The meaningfulness dissipated as the quarter went on.
We’re being much more mindful now about keeping OKRs part of our weekly discussions, which has had an impact on teamwork and alignment.
Come from the bottom up. Managers can’t tell employees what OKRs should be. The employee should be telling us how their work best fits into the company and team’s OKRs. In that way, the employees help form the company’s goals.
We saw the benefit of this immediately when we had our first OKR off site with NerdWallet team leaders -- a lot of things not on our co-founder's radar (or mine) became company priorities.
For instance, we assumed the business unit leaders just wanted to push through their projects at all costs. But it became clear in talks with these folks that we missed a step: We needed to streamline our product-management processes and harden our code base before we could effectively ramp up. That meant for all of last quarter engineering was focused very little on new product development, a move that better positioned us for growth this quarter.
Related: Why Our Brains Like Short-Term Goals