Building a Team at Scoot

When I joined Scoot in the summer of 2018, they were ready to invest in a dedicated team for internal tools. The main focus was improving tools to locate, charge, and repair it's fleet of shared electric motor scooters, eBikes, and electric kick scooters. Since then I've helped hired a product manager, another designer, and grew the engineering team from 1 to 6. We're continually improving our desktop and mobile tools for maintaining our fleet. Here's how we got started.

First Step: Discovery

We audited the system and did some qualitative research to understand the problem space. My first team member was an engineering manager with a ton of context in Scoot's systems. Together we conducted 45 minute sessions with 19 different users, across customer service, fleet and city managers, and field service supervisors. We also shadowed fleet technicians and customer service reps while they performed their daily tasks.

We mapped out all the major workflows.

Through hours and hours of shadowing we learned that a lot of field technicians were struggling to use a poorly formatted desktop tool on their mobile devices. They were mainly looking to determine what work needed to be accomplished, and find the vehicles in the field to fix them.

There were some clear patterns.

1. We don’t have enough information on the state of our inventory.
2. GPS location of vehicles is often inaccurate.
3. Many open tickets are inaccurate or have already been resolved.
4. A fleet tech has to look at multiple places to get the information they need. - opportunity
5. Route planning is complicated and time consuming. - opportunity
6. Mechanics take clerical shortcuts to improve efficiency. - opportunity

We learned that although some of the tools were difficult to use, there were no major pain points for customer service reps. They were able to look for riders, help them with payment issues, and occasionally turn on a scooter for them.

Step 2: Define priorities with key stakeholders.

We held a team kickoff and invited all our key internal users and stakeholders. We explained what we had learned, what the state of our current tools are, and our short and long term roadmap. Through prioritizing our roadmap with our stakeholders everyone had visibility into the timeline and value of our work.

Working closely with my PM and engineering lead, we built out a roadmap and planned major releases.

Step 3: Develop Team Process

We further matured our process by developing design principles and project scoping templates to better focus the work we prioritized. We also took turns doing weekly shadowing of our field technicians to build empathy throughout our team.

I created process for our broader engineering, product and design teams.

Each week our immediate team we had sprint planning and design reviews. To maintain team health and to refine our team process we had bi-weekly retros. For all teams I led both monthly demo's to inspire each other, and monthly org wide retro's to isolate issues our leadership needed visibility on.

In a few months we built a react-native app that automated route planning for low charge vehicles, and made it easier to locate vehicles that needed maintenance.

After that, we started planning out our roadmap to support city expansion, create new automated tasks like picking up and dropping off vehicles, and simplified the process of performing actions on a vehicle. In roughly 6 months we had built a brand new team and processes, and were continually providing value to our direct users.

What didn't go so well?

While trying to be lean and iterative, we had difficulty filling out features to a higher standard. The team is still new, and has limited resources and bandwidth. We would often build the first few pieces of a feature and then have to move on to higher priority projects. This resulted in some great ideas being deprioritized.

What went well?

We built some solid processes for design and implementation. Some of our processes even spread over to other teams.

← Back
to all work