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.
How do you run your team at Lyft and how do goals fit in?
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.
Can you tell us a bit more about the differences between OKRs at Google and at Lyft?
Absolutely. I’ll start by saying a bit more about OKRs, then talk about the differences between Google and Lyft.
Objectives are broad and directional. Ex: grow usage of a certain product.
Key results are much more measurable and trackable. Ex: get to 100M users.
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.
How many levels of OKRs do you have? Does it go all the way down to the individual level?
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.
At Google and Lyft, what is the relationship between OKRs and performance management?
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.
Are there any questions you ask yourself or any tactics you use when you’re creating KRs to say, “is this sufficiently difficult to sandbag?”
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.
Specific to engineering, what are the most common ways that you see OKRs being pathological?
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.
How do you make the judgement call between “we need to just bust this KR because it was set wrong” and “we are just not meeting this KR but it was set right”?
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.
How do you scale the knowledge of OKRs out? How do you train a whole organization to use these well?
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.
Should all OKRs be public?
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.
How strictly should lower level OKRs roll up to higher level 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.
How do you balance the challenge of reports wanting to work on interesting projects that are not in business interest with also keep keeping in line with company goals?
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.
How cross-functionally do you set OKRs and how are they tracked?
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.
What is the effect of company size on OKRs? Should you use them differently on different team sizes?
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.
How do you introduce OKRs to an organization that isn’t doing them?
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.
How do you keep people motivated and believing in your North Star rather than saying, “That’s impossible, I won’t even try”.
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.
Do you have any OKRs that are related to engineering innovation or tech debt? How do you craft the measurable KRs?
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.
Can you go overboard with OKRs and what does that look like?
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.
Want to attend an AMA like this?
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.
Top comments (0)