Running your Data Products Team as a F1 team

Formula 1: Where Speed Meets Tech and Charisma 🏎️

FIA Formula 1 is an electrifying blend of fast cars, cutting-edge tech, and charismatic personalities. It’s not unlike the dynamic atmosphere of a tech startup or scale-up.

Many, myself included, became avid F1 fans after watching ‘Formula 1: Drive to Survive’ on Netflix.

In the midst of the 2023 season, 10 teams compete, with Redbull Racing leading the constructors championship 👑. They owe much of their success to superstar Max Verstappen, but is it all due to him?

In this blog post, we delve into F1 and data product teams, uncovering intriguing parallels. Our goal: extract valuable insights for data product teams from the high-speed world of Formula 1.

Get ready for a thrilling ride!

How is a F1 team organized?

Typical roles in a F1 team

See the table above for the 9 most common roles in a Formula 1 team and depending on the size of the team normally ~170-600¹ people are involved in the daily operations of the team.

Overview of what each person is in charge of:

• Team Principal: The directors of the team, some may come from car manufacturers or other are from private companies e.g. the team owners.

• F1 Drivers: The stars of the team driving the F1 cars. Normally there are 2 main drivers, 1 reserve driver and 1 simulation driver. The two main drivers tend to be bitter foes.

• Assistants: They are in charge of helping and organizing events, calendars and procedures.

• Managers: In charge of different groups and areas, leading teams, supervising and guiding.

• Engineers: Many different rules such as race engineers, aerodynamics engineers and R&D engineers. They make shit work.

• Designers: Handle everything covering the design of the cars.

• Mechanics: What we normally see during the races, they change and repair components when the F1 drivers fucks up.

• Production: Responsible for producing and developing car parts.

• Other: Chefs, personal trainers, web and media relations etc.

Activities during a “normal” race week

The timeline above illustrates how a “regular” race week looks like for a Formula 1 team.

Day 1-4: Race Preparation

• Teams travel to the new race location, transporting and setting up cars, pits, and more.
• Thursday morning is dedicated to strategizing the teardown plan for Sunday.

Day 5: Race Practice

• Friday’s race practice includes two sessions to collect live data, fine-tune simulations, and test new parts.
• Drivers familiarize themselves with the track, and engineers adjust cars based on data and feedback.
• In-depth tire compound degradation analysis is conducted.

Day 6: Race Qualifying

• Saturdays feature final practice (if not a sprint weekend) and qualifying sessions.
• Teams compete for grid positions, and cars enter parc fermé, limiting adjustments.
• Post-qualifying, the strategy team has precise data for simulations.
• Pre and post-shows add excitement.

Day 7: Race & Pack-Up

• Sunday is race day 🏎️:
• Teams work on cars for 5 hours before the formation lap.
• The race begins, and teams vie for points.
• Post-race, teams start pack-up following the Thursday plan.
• A debrief session helps iron out issues for the next race.

How is a Data Products Team (DPT) organized?

Digression Data Products?

To understand what a data products team is doing, it might be helpful to discuss what a data product is. We will not detail to any larger extent what a data product is in this article, but perhaps in future articles.

However, as any sane person would do I did ask for help from chatGPT:

Or in even more simple terms:

Typical roles in a Data Products Team

NB: the roles and number of peoples above are in my experience more common in more product oriented companies, whilst at other companies some of these roles may have different names, or be more centralized.

Overview of what each person is in charge of:

• Area Leads / Engineering Directors: These folks are the true visionaries of the team, setting the high-level agenda based on the company’s grand objectives. Depending on the company’s mood, they might share the limelight with the CTO or VP of Engineering / Product.

• Engineering Managers: Ah, the coaches, the mentors, the team’s cheerleaders, if you will. They’re all about optimizing the execution of things and have a bizarre fascination with reducing the infamous “technical debt.” Some more Data Science-focused companies might even sport a peculiar variant known as the “Data Science Manager.”

• Product Managers: The gatekeepers of vision and roadmap. They hold no formal power but are expected to herd cats (read: teams and people) to get things done. Getting folks aligned and doing what they want? Just another day in the sweet spot.

• Data Scientists: The wizards, the data wranglers, the folks who make magic happen with data. They casually throw around terms like ML, LLMs, and AI, but deploying? Well, that’s not always their cup of tea. Many of them prefer cozying up to Jupyter notebooks. Some companies even call them “AI Engineers,” “ML Engineers,” or the trendy “Generative AI Engineers.” And hey, have you heard of the mystical “Decision Scientist”? No one’s quite sure what makes them different from regular Data Scientists, but it’s a mystery we’re not solving today.

• Backend / Frontend Engineers: These are the swiss knives of engineering, skilled in crafting backend or frontend systems, APIs, and sculpting infrastructure with terraform. Oh, and they’re best buds with the Engineering Managers because they share a common love for reducing “technical debt.” If you’re lucky, you might spot a rare species known as “full-stack” engineers. They’re not exactly wizards, but they’re more like those handy Swiss Army knives.

• Designers: The true artists of the digital realm, they’re all about Figma and crafting user journeys. Sometimes, they’re the mysterious outsiders, dwelling beyond the borders of the product team. Whatever you do, don’t let them leave – you’d be lost without them.

• Other: These are the unsung heroes, often students in desperate need of cash 💰. But also QA, Delivery, Marketing etc. Some companies go all out and hire data annotation firms, known for their interesting practices.

Activities during a “normal” business week

The timeline above illustrates a “regular” week a typical “product” team using some agile framework such as kanban or scrum², working in weekly sprints in my experience.

Day 1: Weekly Preparations

• Teams kick off the week with a review meeting, setting priorities, and potentially launching new initiatives. Some companies rely on Directly Responsible Individuals (DRIs) to lead initiatives, while others delegate to Product Managers or Engineering Managers.
• Feature work resumes, gaining momentum.

Day 2-4: Feature Work

• Teams focus on feature development, diving into initiatives with cross-functional collaboration.
• Daily standups or check-ins track progress and address blockers.
• Team retrospectives provide opportunities to evaluate work methods and discuss topics on a weekly or bi-weekly basis.

Day 5: Demos & Planning

• Feature work wraps up, with some brave souls merging changes into production on Fridays. Others take a more relaxed approach. 🍺
• Demo sessions are held, either internally or company-wide.
• Grooming and planning for the upcoming week ensure a smooth transition.

What are some similarities between F1 and DPT?

Now that we know how both types of teams work, let’s look at some simularities:

Learnings from F1 that can be applied to DPT?

When looking at how a F1 team is operating, there are mainly 3 key areas where a data product team can draw inspiration and learnings from:

• Strategies for High-Performance Product Development
• Data-Driven Insights and User-Centricity
• Post-Launch Evaluation

Strategies for High-Performance Product Development

1. Simulated Testing: F1 teams extensively use simulations for various aspects. Data Product teams can benefit from more simulated testing alongside A/B or bandit testing.

2. Real-Time Decision-Making Under Pressure: F1 teams make quick decisions under race-day pressure. Data Product Teams face similar challenges, like deciding to implement chatGPT in response to a competitor.

3. Pit-Stop Mentality (Rapid Change Execution): In F1, pit stops take less than 3 seconds³, emphasizing rapid execution. Data Product teams might not have such urgency, but they can practice rapid execution through continuous planning.

4. Precision and Attention to Detail: A F1 team pay meticulous attention to detail in product development, as very small changes can mean winning or losing a race. Similar can be said about a Data Product Team, where your clients will notice if you pay attention to details and their needs.

Data-Driven Insights and User-Centricity

1. Driver Feedback (User Feedback): Data Product Teams collect user feedback through interviews or surveys. In F1, drivers are crucial customers, product “experts”⁴, and “evangelists”⁵. They have daily access to drivers, frequently incorporating their input into the “product.” The cadence of this information sets F1 apart. In short, treat your customers like F1 drivers for your product.

2. Telemetry (User Analytics): F1 teams, like data product teams, monitor and gather real-time data on their cars, using a plethora of sensors for comprehensive insights. This informs their strategies and complements driver feedback. Data Product Teams excel in this area but can learn to measure even more user behavior.

Post-Launch Evaluation

1. Post-Race Analysis (Post-Launch Evaluation): After each race, F1 teams conduct post-race analyses to find improvements and insights for the next race. This is a weekly practice for them. Data Product Teams might do something similar after retrospectives or the completion of significant initiatives. The difference is F1’s consistent weekly process, which Data Product Teams can learn from. In short, consider post-evaluation after each release if possible.