How to Prevent Burnout by Delegating Tasks

Engineering Manager

Transitioning an IC to Manager

Packaging Information to Effectively Manage Up

Lyft

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 Plato panel, 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 Luc Vincent Sets Goals For His Autonomous Driving Team At Lyft?

Plato Event #3 - Part 2/6 - Joeseph Perla, Engineering Manager at Lyft

Plato event #2 (Paris) - Part 5/7 - Luc Vincent, VP Engineering at Lyft

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.

> _The larger the company, the more crucial OKRs become — Luc Vincent, VP Engineering at Lyft_

[AMA with Luc Vincent, VP Engineering at Lyft, on goal setting for teams.](https://youtu.be/UIYmltTsgX4)

## 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.

![Luc Vincent, from Lyft](https://assets-global.website-files.com/5ba170a39dd35e64ce65494a/5ccb73cd7872cb28cf3dea8d_1*5BJOtb3uEL1I7RqL8gOeZA.jpeg)
*Luc was the founder of Google Street View and now runs Lyft Level 5, the autonomous driving division of Lyft.*

## 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.

> _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_**

## Have you done this before and has it been effective?

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.

![North Star for Lyft’s Autonomous Driving Unit](https://assets-global.website-files.com/5ba170a39dd35e64ce65494a/5ccb73cd2b13205be5f5cd09_1*767h72tahtbmmjVJ9Z0wSQ.jpeg)
*The North Star for Lyft’s Autonomous Driving Unit is to scale self-driving cars to be usable on the Lyft platform.*

## 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._

## With these different levels of KRs, you typically want them to roll them up into the top level KRs. How do you make the teams and individuals feel like they are contributing enough where they are not reiterating the larger goal?

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.

## 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.

> _If you explicitly link a bonus to an OKR being achieved, that results in bad behaviour and sandbagging._

## 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.

![Lead to growth at all costs](https://assets-global.website-files.com/5ba170a39dd35e64ce65494a/5ccb73cd2b1320f557f5cd07_1*7uhZU7M3AKrfUe8wNxvzGQ.jpeg)
*If the only goal is to grow the business, it can lead to growth at all costs.*

## 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.

![Lyft office](https://assets-global.website-files.com/5ba170a39dd35e64ce65494a/5ccb73cd76cae525e5392448_1*HM-tUvnPdc75opmPGtBM_A.jpeg)
*Lyft reviews their dashboards at the weekly staff meeting every week to see if they’re on track for their 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.

## Do you keep vision separate from OKRs, then OKRs build off of that vision? Or is your vision largely encompassed by your objectives?

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?”

## You are reviewing OKRs fairly frequently. Do you review your vision at any point?

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.

![Lyft vision](https://assets-global.website-files.com/5ba170a39dd35e64ce65494a/5ccb73cd9f46967ceba7c99a_1*TtT-cdhFOj9fWoCLksGfUQ.jpeg)
*Your vision stays with you. If it changes, something major needs to be happening.*

## 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.

## Should we infer, from your last answer, that all actions should be captured by OKRs in some way? Or is there some type of work that just doesn’t make sense to put in there?

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._

‍
## On the premise of people leaving managers not companies. 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.

## Is it acceptable to set an OKR that is not measurable when it is announced?

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.

## 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.

![Lyft car dashboard](https://assets-global.website-files.com/5ba170a39dd35e64ce65494a/5ccb73cd2b1320368af5cd08_1*Br7_NH1TT2lTY3JzWeIQ1g.jpeg)
*PMs start the OKR process and set the overall themes because they have more context.*

## 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.

![Lyft North Star](https://assets-global.website-files.com/5ba170a39dd35e64ce65494a/5ccb73cd9f46961ad4a7c99b_1*3GfNA8F6_-VQSg4kxXnZ7g.jpeg)
*Your job as a leader is to make sure 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.

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 Luc Vincent Sets Goals For His Autonomous Driving Team At Lyft

When I joined Level 5 eighteen months ago to lead the core software efforts, the team had five software engineers, five hardware engineers, and one challenge: build a self-driving car. Now when I go to work, I enter an office with 300 engineers and a small but growing fleet of test vehicles. While I’m proud of the velocity of our team’s accomplishment, it took a lot more than just speed. We had to be extremely thoughtful about how we built and nurtured our team.

Going from Zero to Sixty: Building Lyft’s Self-Driving Software Team

Scaling a company isn’t just about growing the team. As an engineering leader, when you bring on more engineers, you’ll be faced with a host of challenges - from aligning the team, maintaining the culture, increasing productivity, dealing with inter-personal issues, and more. 

Yet, the best companies tackled the challenge of scaling (almost) smoothly. How?

For our third talk of the day at Plato Elevate, our recurring event for engineering and product leaders, Loïc Houssier moderated a panel with Dana Lawson, Luc Vincent, and Prashant Pandey, on how to survive rapid scaling.

- **Loïc Houssier** is the VP of Engineering at **DocuSign** and a mentor at Plato. Prior to that, he worked at Orange (French Telecom company), Thalès, and OpenTrust. He moderated the panel.
- **Dana Lawson** is the VP of Engineering at **GitHub** and used to work at InVisionApp and New Relic.
- **Luc Vincent** is the EVP of Product and Engineering at **Lyft Level 5,** their autonomous driving unit. He was at Google for 12 years before that, and one of his biggest achievements there is starting Google Street View from scratch and scaling it to the iconic product we know.
- **Prashant Pandey** leads the engineering team at **Asana**. He previously worked at companies like Amazon or IBM.

While ‘scale’ may have different definitions, from scaling a product in terms of usage, userbase, or geographic coverage, we will focus on the issues arising from **scaling a team**. Be it from 0 to 10, 10 to 100, or doubling in size for bigger teams, how did Dana, Prashant, Luc, and Loïc scale?

[Elevate Conference — "Surviving Fast Scaling" with leaders from Lyft, GitHub, Asana, and DocuSign](https://youtu.be/1hEQxzcJ49A)

## Scaling is a goal

If you don’t recruit enough engineers, it impedes the company’s growth. In order to avoid this at GitHub, Dana Lawson reminded us that **getting teams in place has to be a top objective**.

It’s crucial to make recruitment a **goal that is measurable** and use different **frameworks** to ensure you find top-notch candidates, decrease failure rate in new hires, and streamline the recruiting process.

Dana stressed the fact the recruitment process is inefficient without the right **culture**, quoting a colleague of hers: “like likes like”. This is why you need to ensure recruitment is **aligned with the mission statement** of the company, and that the culture is strong enough to attract top-notch candidates. 

Dana added that besides culture, a leader ensures team members have **interpersonal relationships** instead of transactional exchanges to create **intimacy** and get everyone on the same page.

![Elevate by Plato](https://uploads-ssl.webflow.com/5ba170a39dd35e64ce65494a/5d6966d12def16226a8caae4\_Elevate%202019%20by%20Plato%20-%2067.jpg)

## Onboarding is a tool

Prashant Pandey, VP of Engineering at Asana, believes the **onboarding process is key to make scaling a success**. The first question to ask yourself is: “Why are we growing fast?”

The answer is usually always the same: to ship faster and deliver a product, tackle a big roadmap, and meet the company’s goals. If the recruiting process is flawed, it will take too much time for managers to interview and onboard people. Thus, the company won’t progress on the global objective.

A good onboarding [**reduces the time to productivity**](https://community.platohq.com/stories/when-more-engineers-means-decreased-productivity-). At Asana, Prashant set a **goal** of making any newcomer productive in about 2 to 3 weeks. The company has extensive **documentation and an internal mentoring process** to help people quickly catch-up. When he has **lunch with new employees**, they usually feel completely integrated within the company.

Luc Vincent and Dana Lawson agree with Prashant’s vision and believe onboarding is important too. In order to decrease the time-to-productivity of newcomers, here are some pieces of advice:

- **Remind Engineering managers** or tech leads that their **team successes are their own too**, in order to motivate them to **decrease** the time between the employee arrival and her being efficient and actually shipping. Doing so will ensure the onboarding is smooth and quick. For instance, managers can make sure any newcomer has their laptop fully configured before they arrive, with email credentials, access to tools, etc.
- Build **tools and documentation** that will help people integrate more quickly.
- Write down your purpose, as well as the mission statement for individual teams and expectations for the newcomer’s contribution.

![Elevate by Plato](https://uploads-ssl.webflow.com/5ba170a39dd35e64ce65494a/5d6966f49fa6c200ac72fe51\_Elevate%202019%20by%20Plato%20-%2071.jpg)

## Surviving scaling in a remote world

In the last 10 years, the organization has changed a lot in startups, especially as **distributed teams and remote work** are considered as the future of work. People have ties to geographic areas, want a set up that maximizes their efficiency, or just can’t commute two hours every day to go to an office.

Dana believes scaling a [distributed team](https://community.platohq.com/stories/how-to-work-effectively-with-distributed-teams) takes a lot of effort in terms of work: **values** have to be shared between all employees, and a **bond** has to be created too. Getting people in the Headquarters for a week in order to give people a sense of **community** and create deep **interactions** is the way to go according to Dana. She believes **niceties** are why people wake up to go to work, and transactional relationships aren’t enough for people to give their best.

## Scale and skills

Luc Vincent gave the audience a warning: **as you grow as a company, every role changes**. The CEO of a 5-person company has a completely different day-to-day job as the one who works with 50, 500 or 5000 employees. In the very beginning, you would focus on velocity and getting to the curriculum as quickly as possible, but as you grow, you will start hiring the top people for your company, and build an organization around them. It usually **starts with people you trust** and who you’ve worked with previously.

Prashant Pandey added that as the company grows, it changes a lot and **managers may not feel in place anymore**. In such cases, it’s important to ask yourself if you still enjoy the job and if you still have the skills to do it correctly. To him, the right mix in an organization that scales is to have a **core set of employees** that have already worked at companies in a similar stage of development or find external **mentors** and **preserve context** in some way with long-time employees. People who have been at the company for a while **understand the decisions** that have been taken in the past and will help shape the decisions that will be taken in the future.

![Elevate by Plato](https://uploads-ssl.webflow.com/5ba170a39dd35e64ce65494a/5d69676cfaa2a09f2e40e0e9\_Elevate%202019%20by%20Plato%20-%2068.jpg)

## Miscellaneous advice

Loïc Houssier, who moderated the talk, asked for general advice guests could give to the audience:

- **Dana’s** piece of advice is to **be yourself**. While she acknowledged it may sound hogwash at first, this is the best advice she ever got. Especially as you continue your journey as a woman leader in a male-dominated industry, you feel like you have to meet a certain model. Truth is that you are here for a reason: you have the skills, and you know how to do the job. People want to see authenticity because this is the way trust will be built, and it also enables them to stay true to themselves too.
- **Prashant** cited a famous quote [attributed to Mark Twain](http://freakonomics.com/2011/04/25/quotes-uncovered-twain-or-not-twain/): “_We spend most of our lives worrying about things that never happened_”. His interpretation in a modern world would be the following: as a leader, your job is **to look out for problems** before they happen, think about them, **plan for them**, and prevent them. Thinking about the downsides of your decisions is crucial to becoming a good manager, but it’s even more important not to let these take you down. Instead of worrying about problems, it’s better to plan for them and be fully prepared in case they happen.
- **Luc** believes it’s essential to **surround yourself with people you trust**. As a leader, you cannot be everywhere at the same time, and in order to “sleep at night”, there’s nothing better than knowing that people who are in charge know what they are doing.
- When **Loïc** started his career, he didn’t know who he really was and what he liked. The best advice he got was to **be the “_yes man_”** early in his career, accepting opportunities to multiply experiences and try anything he could to understand his true self better. Cumulating different experiences is also a way to understand how to work and evolve as a leader. When he was younger, Loïc worked for a company building submarines. He was a project manager and had to convince people to do things, talking to engineers specialized in nuclear energy, torpedos, etc. After a failure, he learned to put his ego aside and start listening instead of talking.

_Thanks a bunch to Dana, Prashant, Luc and Loïc for their time and insights. If you want to read more stories from them,_ [try Plato for free](https://www.platohq.com/)_!_

For our third talk of the day at Plato Elevate, our recurring event for engineering and product leaders, Loïc Houssier moderated a panel with Dana Lawson, Luc Vincent, and Prashant Pandey, on how to survive rapid scaling.

Surviving Rapid Scaling - Loïc Houssier, Dana Lawson, Luc Vincent, and Prashant Pandey at Elevate 2019

Building an engineering structure to attract the best talents

AMA with Luc Vincent, VP Engineering at Lyft, on goal setting for teams.

Plato Event #5: Unknown Unknowns in Engineering Management

Panel on Building Magical Engineering & Product Teams

Plato ELEVATE Summit Fireside Chat with Luc Vincent, VP Engineering at Lyft.

Engineering Talks with Plato: Part 6/6 Building an Engineering Structure - 15th May 2017

Improving people's lives with the world's best transportation.

Blackboard

Developed various Learning Management System features using Java, JSP, javascript, JUnit, Spring, Struts, Oracle, and SQLServer. Mentored software engineers and enforced code reviews. Presented at developer's conference on creating plugins to the Blackboard platform.

Principal Software Engineer

Managed a team of 5 developers to build various features of the Blackboard Academic Suite learning management system.

Developed various Learning Management System features using Java, JSP, Swing, Struts, Oracle, and SQLServer.

Software Engineer

Inventa

Developed three subsequent versions of an online Finance Center for a business-to-business marketplace for small construction and manufacturing businesses using Java and JSP. Discussed requirements with the client's senior architect and CTO, led implementation of the new product, and reported status and risks to the project manager.

Technical Consultant

PricewaterhouseCoopers

Technical instructor for the MITIS training program. Lead 3 month training sessions of 60 students. Presented material on Java, SQL, C, and the software development lifecycle. Conducted code reviews, assessed student performance, provided 1-on-1 assistance.

No CS degree

Woman in Tech

Worked in startup

Coaching / Training / Mentorship

Conflict solving

Firing

Managing Up

New Manager

New Manager of Manager

Remote

Team processes

Agile / Scrum

Scaling Team

Project Management

Hi All, I’m an engineering manager at Lyft in San Francisco. I currently manage several teams across three locations surfacing public transit into the Lyft app. Previously I was a Director of Engineering at Capital One and spent most of my career at Blackboard, an edtech company, starting as a software engineer and then moving into eng management, managing managers, and technical program management. I have an economics degree but fell into software engineering and have been managing teams for 15 years. I love the coaching part of my job and hope I can be helpful as a sounding board here!

Heather Natour

Engineering Manager at Lyft

Seniority

Hierarchy

Management Experience

Stories

Experience

Engineering Manager

Lyft

Principal Software Engineer

Blackboard

Engineering Manager

Blackboard

Software Engineer

Blackboard

Technical Consultant

Inventa

Technical Consultant

PricewaterhouseCoopers