Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Does Autopilot team churn affect progress plus or minus?

This site may earn commission on affiliate links.
I'm not a software engineer or computer scientist. My sole coding experience was a year of highschool Pascal a long time ago.

So - to the developers here - what can you tell us about how departures/new hires affect or do not affect a large group project such as increasing the capabilities of autopilot?

When a person leaves do they take institutional knowledge with them and reduce the knowledge of the remaining team? Is progress meticulously documented so that new researchers can pick up where others left off? Do new team members perhaps bring new ideas and k crease the rate of progress? Does efficiency take a hit while the team newbie integrates with the rest?
 
Obviously, keeping people is better than losing people, but considering that Tesla is always hiring new people for the Autopilot team and needs to be prepared to quickly and easily insert them into the workflow, detailed documentation is all but guaranteed.

Churn is a fact of life in Silicon Valley.
 
  • Like
  • Informative
Reactions: calisnow and Tam
Minus. Unless the developer is Bighetti.

upload_2017-4-28_23-18-43.png
 
Employee churn is a fact of life in any business. The goal is to make sure employees are net productive during their time at the company. The longer it takes to bring them up to speed and the sooner they leave, the harder that is. Unfortunately Tesla's reputation for work-life balance is below average for software companies, and I understand that the churn rate is high. However Amazon also has both of these problems, and Amazon seems to manage.

The cost of churn varies a lot. I don't think it can ever be zero. I've seen cases where an employee's last weeks were spent entirely on knowledge transfer: documenting processes and code, and meeting with colleagues to review and answer questions. There can still be quite a bit of confusion in the weeks or months after that employee leaves. At the other end of the spectrum I've seen code modules that turn into black boxes: no one on the team understands it, or wants to touch it. That situation might go on for years.

You can hedge against churn in various ways. You might try to make sure at least two different engineers have worked on each module. Requiring code docs and in-house presentations also helps. Even requiring code reviews is some help. I've read that Amazon has an internal policy of not letting any code into production unless it has a stable, documented API that any other team in the company can use. That seems like a powerful technique to reduce the cost of churn. Even if you lose the whole team that wrote that code, you can work from the API and docs. Amazon may also have test case and code coverage requirements, which can be helpful.

I hope Tesla is managing their churn at least as well as Amazon does. But it's easy to cut corners, especially when deadlines loom.
 
  • Informative
Reactions: croman
Software is all about crafting a new york metropolis described in thoughts and words down to the accuracy of a milimeter.
There is no way you can document it all out, even if you could, nobody could read it, even if they did, they wouldn't understand it, and if they did understand it, by the time they understood it, technology would have moved on.

This is what 99% of corporate America gets wrong! They think one developer is the same as another. In reality, a good developer is as rare as it gets.

A good developer is worth their weight in antimatter.
When a developer leaves, it hurts the company. No two ways about it.
 
  • Informative
Reactions: GSP
The greatest impact on a development team of a single departure comes from "intangibles" such as leadership and inspiration. If the
person who is departing is a significant part of why the others on the team like being there and making an extra effort the whole team
may "sag" in the lee of such a departure. On the other end of the spectrum, sometimes getting a poorly fitting person out is the best
thing that can happen to a team. You'd have to know a lot of specifics about the team and the departing employee to really estimate.

As for the AP team at Tesla in particular, I'd guess the direction from above is more important than what any individual team member
is doing. Particularly for us Model S owners, if the focus is squarely on M3 and future (HW2 and beyond) MSs then there's not much
hope for significant advances in AP1 no matter who is on the team. There may be some "trickle down", but it will probably be just about
as effective as other well-known trickle down theories. :(
 
  • Like
Reactions: OBX John