Guest Column | January 17, 2019

How An Engineering Team At A 125+ Person SaaS Company Transformed With OKRs

A conversation with Nick Faulkner, Influitive

SaaS: Built To Last Or Built To Lose? The Growing Opportunity For On-Premise Vendors

The Objectives and Key Results (OKR) framework is generating a lot of buzz in the tech industry. For marketing software company Influitive, the process of implementing OKRs has been transformative across every team and department. Influitive’s Director of Software Engineering Nick Faulkner shared his perspective on why he was skeptical OKRs would work, why he’s now a believer, and how this framework has given the company’s engineering team a new sense of purpose when developing software.

Q: Why was the engineering team initially most skeptical about OKRs?

Faulkner: In my time at Influitive we have tried to implement OKRs three times, always with a different way to track them, and no one really seemed sold on how they could really work. There wasn't no real buy-in at the top level of engineering, which is super important for them to be successful. Because of this there wasn't a push to learn more about them. They were seen as a checkbox we checked because we were told to. I personally didn’t understand how you could make a single engineer responsible for such big goals. Even at the team level it seemed really hard to align them with company goals.

Q: What about the new system made you a believer?

Faulkner: It really came down to educating myself and taking the time to understand how they work and apply to product, design, and engineering. I always have been a big believer in agile and how big its impact is on how we deliver software. OKRs are its equivalent in what we build and why. When having a KR for not just if a feature is delivered, but having KRs for its impact on our product, UX, performance, technical debt, etc. is really empowering for a team.

Q: OKRs can help realigned teams in a way that makes life easier for all teams, especially the engineering team. What are some examples of this?

Faulkner: Often the different departments have conflicting objectives. The biggest concerns we have had on engineering for the last year are scaling and technical debt. Engineering has benefited greatly from working closer with product. Aligning out objectives to balance features versus technical debt so that we can repay some debt and increase our velocity has been beneficial.

Similar things happen with other departments. For example, sales where there might be a key result to bring in a new enterprise customer of X size this quarter. This aligns well with our objective about enterprise clients, but also causes concern for engineering because of the scale of X size. The engineering team has in turn added an OKR about our scalability and stability to match this goal. Response times can't be more than X milliseconds. This matching a qualitative KR (land a new enterprise customer of X size) with a qualitative KR (response times can't be more than X milliseconds) has allowed us to align between departments to accomplish the company goals.

Q: Can you give a few concrete examples of how things have changed on the engineering team since this process started?

Faulkner: We really made the big push this quarter (starting in November 2018) so we are pretty early into our OKR journey, but there have been some big changes even in that time:

  1. The sheer amount of conversation about them. People are questioning KRs to see if they are measurable, if we are measuring the right thing, and if we are stretching enough.
  2. Alignment between the teams and what they are doing that helps the company objectives. Engineering always felt like the work we were doing won't have a real impact until the next quarter or longer. We have a diagram hanging in the engineering area that shows all Product, Design and Engineering OKRs and how they align to each squad. Anyone can go and look at it and see how the work they are doing impacts the company’s goals.
  3. We’re setting better OKRs. Without a real understanding of OKRs we were making bad ones. We had the wrong objectives and poor KRs. There was a lot of focus on making them better and making sure we were measuring the right thing. Also, we started taking the time to reflect and change them if they are wrong. Seeing them as set in stone was directly against being agile, and this realization helped a lot.

Q: What other advice do you have for engineering leaders who want to implement OKRs?


OKRs are a way out of "feature factories" where teams just "deliver" software. They focus on the important part of our jobs: how the work we do makes a quantifiable impact on our customers. This is big for getting buy-in. It gives meaning to the work an engineer does, aligns them around goals that matter, and gives teams the autonomy to figure out how to achieve their goal.

  • Support. OKRs are a TON of work and something that is almost impossible to do on your own. I got a ton of help from my colleague Herman Chan (Director of Software Engineering Architecture). Having someone to talk to about what made OKRs great, how they could help us, how we implement them, etc. is also important. They are hard to implement correctly. So, find your “Herman” in this.
  • Alignment with Product and Design. At Influitive, we had always worked well together, but having those three teams create OKRs together was a big win. In this way the objectives were shared and the KRs reflected the different values of each of them. From design, we have KRs about UX and user delight. From product, we have KRs about engagement and impact on our north star fly wheel. From engineering, we have KRs about on-time delivery, number of bugs, performance, and quality.
  • Education. It is huge to have the team learn about OKRs. I created cheat sheets from John Doerrs, a well-known VS at Kleiner Perkins. Measure what matters for the engineers to read. Make it easy to understand the important things. Have engineers expense the purchase of books about OKRs. Show them that it's part of their education and something they should learn.