Luc Vincent was the founder of Google Street View and is the Founder of Lyft Level 5, the autonomous driving unit of Lyft. He hired 300 engineers in 18 months. In this live video AMA on Plato, moderated by Heather Rivers, CTO of Mode, and Brett Huff, Engineering Manager at Atlassian, Luc talks about how he sets goals for his team and ensures they stay on track.
In this live video AMA on Plato, moderated by Heather Rivers, CTO of Mode, and Brett Huff, Engineering Manager at Atlassian, Luc talks about how he sets goals for his team and ensures they stay on track.
The larger the company, the more crucial OKRs become — Luc Vincent, VP Engineering at Lyft
I run the autonomous sector at Lyft. We started this over 18 months ago; it started at nobody when I joined but now is at well over 300 engineers and growing.
For context on my background, I’ve been at Lyft for 2 years, and before that at Google for 12 years. My role now is the head of a team of engineers, product managers, program managers and a variety of other different functions.
One of my jobs is to hire people. How do you find the best people out there and convince them to join your organization? How do you organize so that you are not doing all the work yourself in terms of hiring?
The second thing one must do as a leader is set the vision. You must communicate it well to the other leaders and to the board.
Third, you must also set the culture. How do we communicate, collaborate, set goals, operate as a team?
Fourth, you must drive impact and execution. In my view, this is where you require having a well thought out set of goals. The process we use is the OKR (objective and key results). This was a process created at Intel and eventually used by Google. Now a lot of large companies have found success with it.
Absolutely. I’ll start by saying a bit more about OKRs, then talk about the differences between Google and Lyft.
The objectives can be recurring themes. And stay with you for the long term. Key results are different every quarter or every year.
At both Google and Lyft, you have a small number of top-level objectives (3–5). If you have too many, nothing is a priority. Under each objective, you have a series of key results. The differences between Google and Lyft are around expectations.
At Google, a good OKR must be an aggressive, stretch goal. The expectation was that you should meet 70% of your goal. The reason to do this is to maintain an aggressive goal setting.
You don’t want the incentive structure and the culture to be that if you miss your objective, it’s catastrophic. This culture, instead, is that it is reasonable not to meet goals since these goals should be a stretch.
At Lyft, goals were typically set to be met. This speaks to a company that is earlier in its life cycle than Google. The processes are still evolving.
In the early days of Lyft, they were very focused and needed a lot of clarity. They established goals that should be met. If it was not met, there was a big problem.
What we are doing now is a blend of the two approaches. We label some goals as critical. Ex: build a feature by a certain event. This needs to be done 100%.
Other goals are titled stretch goals. Not all of them will be achieved, and like previously mentioned at Google, this is expected.
You defined objectives to be goals that carry over year to year, and KRs to be scoped within that period and be more definite.
At Atlassian, we have what we call our big hairy goal. It looks more like the KR but it definitely takes more than one period. Ours is that we want 100M users.
This is way more than we have right now but it gives us something to shoot for. Have you done this before and has it been effective? — Brett Huff, Engineering Manager, Atlassian
Yes, at Lyft we have some goals as we describe as the North Star. This is defined as where you want to be in a few years. You don’t have the timing yet since it is so far away, but you are marching toward it.
Ex: for autonomous cars, our North Star is to scale these to be useable on the Lyft platform. That is what we are marching toward. The yearly goals you establish should take you closer and closer to that North Star.
And then since you talked about the time horizon of goals- that’s another difference between Google and Lyft.
Google used to be all quarterly and then they introduced yearly OKRs. What we found at Lyft is it takes quite a bit of work to establish credible OKRs. In the past year, we switched from quarterly to 6-month OKR planning. I think this is a good compromise for us.
In theory, yes. As a company leader, what I care most about are the OKRs that span the entire organization.
For example, one objective is to improve our timing and there could be various KRs below that. These can be a bit broad, so managers will typically go a little deeper and have teams establish their own KRs to contribute to this broader KR.
You would typically have two or three levels of OKRs in an organization. The top-level ones and then sub-KRs for each subpart of the project. This will show in greater detail what exactly we are doing to move toward this company goal.
However, I do not check on those specifically. It is up to the managers to choose how to run their team.
You would typically have two or three levels of OKRs in an organization. The top-level ones and then sub-KRs for each subpart of the project.
The top-level goal should be very broad. Ex: With self-driving cars, the brain of the system is the autonomy piece.
Our objective could be to improve autonomy. Then, the key result is to improve it by 100x. On a more detailed level, you will need to drill down and decide- what does the goal mean and how do you measure it.
In this example, there are many pieces going into this. Sensor, perception, understanding of objects, traffic lights, etc. There are many sub-goals around the main key result that are complex on their own.
The challenge is to make sure these all work together toward the broader goal. This process does take time.
That’s a great question. It should be de-coupled. If you explicitly link a bonus to an OKR being achieved, that results in bad behaviour and sandbagging. Nobody is going to be aggressive if their bonus depends on it.
Also, things change. Your goal could become obsolete because of something out of the employees' control. In some special cases at Google, very special goals were established as incentive goals but it is outside of the OKR process.
If you explicitly link a bonus to an OKR being achieved, that results in bad behaviour and sandbagging.
That speaks to the difficulty of establishing metrics that you believe in. It’s an art. I think once you have the goal, you may not have the metric fleshed out, but that comes next.
You’re right, the wrong metric can measure the wrong thing and you can make yourself believe you are making progress when, in fact, you are measuring the wrong thing.
For example, companies often have a goal to grow their business. If that is your only goal it can lead to growth at all cost or different ways of measuring usage that isn’t as useful.
There are many nuances on how to measure. To combat this, you should have multiple metrics. A small number as to avoid confusion; but not just one.
The main issue that I see is non-measurable OKRs. As an example, I often see OKRs about building a feature or one discrete event.
This is an incorrect use; you want things that are more measurable, objective, and consisting of more than one discrete task. Ideally, they are tracking a core business metric for an indicator that you care about.
It’s about tracking. Once you establish the goals, you establish the tracking metrics. I think one of the key value of OKRs is that they give everyone a sense of where they fit in the organization and this helps establish the culture as well.
Once you establish and track OKRs (via dashboards) the idea is that you can see at a glance when something is off.
For instance, at a staff meeting every week, we review the dashboards to see very quickly what is happening. If we see a trend, we dig deeper and focus on what is going on. If we see that there is a problem, we either bring in more resources or find the communication break, etc.
We try to understand what happened, then document it to try to avoid making the mistake in the future.
As you mentioned, there are some cases where you track and realize you made a mistake in goal setting. Ideally, this doesn’t happen very often.
However, you still have to be aligned for these situations. For example, if you tie objectives and KRs to compensation, you are not flexible and you are not in a position to throw out OKRs.
The things that matter in your organization: culture, methods, communication, etc. Within all of these buckets, OKRs must be top of mind all the time.
For me, I have one particular engineer manager who is really passionate about OKRs. I asked them to come to talk about it in an all-hands forum. This manager explained to everyone what they are, why we do them, why it is important, etc, then we sent this over email.
You want to make sure OKRs are top of mind and people and give employees a good way to learn about them. It is all about communication.
Additionally, we go through a yearly goal planning as a company and as individual teams. At this time, OKRs become top of mind for everybody. The process takes 2–4 weeks to come up with objectives and high-level KRs and then teams internalize these large themes and offer what they can contribute.
The vision is meant to be broader. It captures the overall mission of the organization.
OKRs at any levels are more specific. For example, “what do you want to do right now or over the next year?”
The vision is here to stay, right? It sticks with you. It’s why you started a company or department. So if that changes you are talking about something major.
Yes. OKRs are valuable because they are broadly communicated. You want them to be broadly discussed at all-hands meetings. You want them to be publicly published somewhere everybody knows to look.
This should be true for every level of OKR; even your own personal objectives. This helps to communicate the value you bring. It’s always a good thing to be open with OKRs.
In practice, it’s sometimes hard to have every single OKR align with the top goal. These are still good to capture in your own personal OKRs. This helps your peers and managers to know what you bring to the table.
For example, at Google, you end up running a bunch of live services. You have a bunch of pipelines. They require maintenance so you have to work on an underlying framework. The more services you have, the more you have a tax on being able to run all the services. A large percentage of your team is doing maintenance work.
It's ok to capture these in your OKRs. It’s not super important to capture these in high-level OKRs, but more as personal, lower level OKRs. My preference would be to capture them at the top as well, but I realize this is sometimes not possible.
Ideally yes, all tasks would roll up into OKRs but in practice that is not practical.
The larger the company, the more crucial OKRs become.
There are different types of people. Some that want to work on cutting edge stuff, some that are more junior and developing, and ones that are focused on working toward the company vision.
As a manager, you want to build your team with a good blend of people so you can best apply them to meet your OKRs. If you find there is a big mismatch between the goals you set for a team and the team composition, then you have probably built the wrong team.
It’s not unacceptable but it’s not ideal. Some OKRs early on such as “launching something” is too binary and for that reason is not a strong OKR. However, any OKRs are better than no OKRs.
Typically what happens is that the Product Manager group is most involved in establishing the goals. PMs along with the leadership of the organization.
They start the process and give overall themes. This is because they typically have more context and spend more time knowing the environment, competition, other team functions, etc.
They will then communicate high-level OKRs to teams, have teams work on their own OKRs, then go back and forth. Once you have an OKR established you want to track and measure progress. The two functions here are tracking and driving execution.
Technical Program Managers here will be in charge of tracking the progress of all teams involved in a broad goal. They will help to understand where the gaps are at any point in time.
For small companies it is simple, you are doing one thing. Establishing OKRs should just take a few hours. It is still good to document this to make sure you all agree and have communicated direction correctly.
In bigger organizations, you need to make sure that different divisions and groups work together in harmony. This is where OKRs become key for alignment and communication.
The larger the company, the more crucial OKRs become.
Like anything else, if you are a big believer you may start by buying a few books on OKRs and sharing them with your leads. Establish an OKR for yourself to start the OKR process.
I think it’s always good to have one person who is a champion. If you have that champion in your organization, you can task them with creating some docs and presentations for your organization.
As a leader, I like to do some things directly or find a champion to help.
Well, that is where OKRs should help. I think the OKRs should be much more in reach than a far out, end goal.
OKRs should still be challenging, but they should not be years away. The process of breaking that crazy goal into bite-size chunks is crucial. There should be no question for any engineer what they should be doing in the next 3–6 months.
Your job as a leader is to make sure all these bite-sized goals work in harmony and take you toward the North Star.
Let’s talk about tech debt. When you move fast you are inevitably creating tech debt. Code always needs to be rewritten eventually so code, by definition, is tech debt.
For example, one of our objectives is to increase velocity. Our sub goals are around looking at anything that gets in the way of productivity and moving fast. This is primarily tech debt.
And how do you measure this? You can look at a percentage of your code that has been refactored to mould to your new goals. Or you can look at the turn around time from a bug being logged to fixed.
Refactoring is one of these things that you can think of as a tax. It is important to capture tech debt in your OKRs.
Yes, you can. You can spend all of your time planning and no time working. To a certain extent, we were going this direction at Lyft.
At the time, the process there was that every team presented and discussed the goals with company leadership. That’s fine when you have 2–3 teams but when you have 50 teams, that is overboard.
Generally, OKR planning should be limited to 2–3 weeks, and even that is a lot.
Plato helps engineering managers and PMs get mentorship from top tech leaders at companies like Google, Lyft, Netflix, and more.
Get a taste of this mentorship by joining a group mentoring session for free.