.png)
For this week’s company talk, we’ve chatted with Ben Lubkin, a Principal Engineering Program Manager at Peloton. Since its founding in 2012, Peloton has charmed millions of fitness enthusiasts with its online classes and stationary bike. The company now also offers treadmills, accessories, and apparel.
During our conversation, we talked with Ben about his journey to Peloton, the company’s success, and his role as a Program Manager. There’s a lot to learn from his years of experience in hardware!
---
I studied mechanical engineering and mechatronics at Stanford. My first job was in med devices, because I was pre-med at school before going into engineering. I was still focused on working with life-changing technologies for people. One of the interesting things that I learned in the med device industry is that I wanted a certain speed of product development—where things moved fast, and I got product cycles under my belt.
I shifted into consumer electronics by taking a job at Apple, doing iPhone system program management where I learned a lot about circuit board development and, overall, how to make products that are very complex at scale. It taught me a lot of lessons on how to work at a big company, how to make things at scale, and how to work on really hard problems. It was an amazing mental framework that I developed for a couple of years there.
I took a job at L'Oreal tech incubator after that for a couple of years where I was effectively a technical lead, a combination of a hardware lead and program manager role, on some exciting projects in personalized skincare and consumer devices for skin. One of the projects I worked on was the Custom D.O.S.E systems by SkinCeutical, which is in dermatology clinics around the country.
I got a job offer at Peloton about six months ago where I've had the opportunity now to run some really exciting projects at the future of fitness tech.
I think that Peloton’s key advantage is how vertical they are as a company. They own the hardware, software, content, logistics—and really, every part of the experience is controlled by them. As a result, they have such high NPS as a result. You can't do that if you don't control the experience. I'm an engineer not a strategist, but that's my personal opinion on what makes it so special.
As a program EPM, I'd say my primary goal is to guide the team. The team is comprised of all the subject matter experts, the people who understand the product, people who understand the engineering, the marketing, the software, the hardware, and making sure that they're all working as a cohesive group and communicating properly.
I also track the KPIs as a PM—the schedule, the product costs, the overall program budget, the resources that we have in the program—to make sure that we're on track.
I'm also responsible for reporting to management and understanding where we need to ask management for guidance.
And then, I’d say the last role of a program manager is that you really own the manufacturing partnership during the new product introduction stage. You work with a CM or a JDM on the overall relationship and the transfer of technology or co-development.
Yeah! I have the exciting opportunity to oversee the execution of hardware, the integration of the full stack software-firmware, and all the operational transfer. The operations teams typically have their own program manager and manufacturing quality expertise, so the transition happens from design into manufacturing. That's really key to keeping a tight product schedule as you're learning lessons about engineering—those need to be transferred to the operation side as soon as they happen.
Yeah, I can speak about that a bit. I'm operating kind of at an engineering abstraction layer where I'm not involved in the engineering tools. So there's a phase life management system and a product design management system that the teams use. But from my perspective, I run a core team, and I ensure that the interfaces are working at a Microsoft Word Doc or Excel Doc type of level where risks are getting tracked and updates are being given. Of course, people need to be operating on common data sets. That really reduces misalignments.
Yeah, absolutely. We actually use Google suite—so Google docs, sheets, slides. I think the one big advantage of that over Office, which is hard drive based, is that it's all in the cloud. It's designed as the bridge between a traditional word suite and a pure SaaS tool. So we are able to comment in real time, make notes, and collaborate easily. That's halfway there.
I think the big issue with risk tracking or status updates is: how do you have a tool that's not invasive to people's workloads, but lets you get the updates? For example, I could comment on the page every day and say, “please remember to update the status,” but that may just go to their inbox.
And you know, some days I may have 15 requests for information while some days I may have one, and if the engineer is busy, it's not on their priority list. So how as a PM, do you manage the escalations on what you need without distracting them from their key work?
I think one of the things for a busy engineer is always a balance between working on your project work and working on the program status, especially for a lead like a mechanical lead or an electrical lead who bridges between the actual engineering work and the status and program updates. And so where a SaaS tool can be helpful is really distilling a workflow into engineers’ and leads’ times. So they know what they're doing, and there's better reminders that are not intrusive but still useful.
So I think that with the pandemic, overall, people are working longer hours. Even though they’re home, the commute time gets replaced by extra time in front of the screen. I think that's because a lot of impromptu communications and quick syncs between teams, especially on visual things like models, become pre-scheduled meetings that often fill the time that's allotted to them. So, even if it's like a two minute conversation, people talk for 30 minutes. Being virtual requires asynchronous things in the office to become synchronous scheduled meetings, which may not make sense as a PM.
When I was at Apple, it was all too easy to go up to someone's desk, have the conversation, and get the answer you want. This made things really efficient and introduced that social factor that makes work fun.
Being virtual really makes a lot of things that are project-based and mundane, even more mundane. You have to be able to do design reviews in front of a screen when everyone already has Zoom fatigue.
I think the efficiency of collaboration is critical, even more so than before. A PM has to find the balance between the project work (the interactions of the functions and alignments) and then the actual product work (the engineer going heads down and doing hardware development).
From my perspective, I always think: “how do I get the most engineering work out of someone without sacrificing the project?” In the office, you can tell them to keep their head down, don’t go to all the meetings, and that you’ll come to them when it's important. Well now with the pandemic, it's all the engineers all the time. A lot of engineers sit in so many meetings that it slows down the amount of time they can spend on design work, which is really upsetting.
For an external vendor, the most efficient thing you can do is to treat them as an extension of your core team. They provide subject matter expertise, and theoretically, information should be flowing transparently between parties. But in reality, there's confidentiality and there's need-to-know when you're talking to vendors. So how do you share without worrying all the time about what you can and can't? I think that's a big pain point externally.
Internally, it’s about ensuring people's priorities are aligned. For example you have an electrical engineer who is so focused on, let's say, performance of high speed rails and the other aspects of the PCV performance, while the mechanical engineer is focused on size. Then, there’s the RF engineer who needs to get the metals away from the antennas. They get so lost in their own world, sometimes, that it's hard to see the bigger picture, which is to make the best project possible.
So, taking conversations away from an “us versus them” viewpoint to “these are the trade-offs,” is really what an EPM does. We help frame the problem at an overall product level rather than at a sectarian disciplines level, which is what I see as the biggest communication problem internally.
So I think there's certain problems that are people-based. They need the right group of people together to frame them properly.
But I think that the opportunity for software tools is about giving people the right information without overflooding them with information. I think that there are things that a software can do, and then there's things that you still need to have the right system-level people in organizations to do.
Like I had previously said, the biggest problem for communication centers around making sure people's priorities are aligned. The biggest thing for improving and speeding up hardware development is making sure people have the right information. You could give someone access to a thousand drawings and 50 comments, or you could give someone access to the three drawings that matter to them and the two or three comments that they actually need.
That goes back to the balance of actual engineering work versus project work. When you can find the right balance of what people need to know to get their work done efficiently, productively, and interdisciplinarily, you free them up to do a lot more engineering work and can get more out of each engineer.
For a startup to be really successful, especially in hardware, you need to hire people who can hit the ground running and start executing. There aren't really deep, technical engineering teams. There's a lead and maybe one or two engineers on each function. You don't have to worry about the overhead, because just a few people work on such a big chunk of the system.
When it's a really big company, there are really carefully thought out processes in place. There are schedules for design reviews or schedules for exec reviews. There are software tools that you set up with.
You can think of being at a really big company as kind of coming into a system. You learn the system kind of like learning a software language. Once you master it, you can then expertly develop products. At Apple, we learned one system that works really well when you have the resources and expertise to do it.
From a program manager’s perspective, I'd say the growing, medium-sized companies are actually the more challenging ones but also one of the more rewarding ones. That’s because you have a company that's used to doing things in big chunks without a lot of processes, but suddenly there are new expectations on complexity, speed, and quality. They can't do things the old way but haven't figured out how to do things the new way.
This really requires everyone to be aligned and motivated on figuring out what's going to work for a unique company culture. The company has to get to an organized place quickly to achieve its overall vision.
When you're early stage, you need to focus more on getting stuff done. You can only afford a certain number of engineers, so everything needs to be very lean. I think one of the mistakes that early stage companies make is thinking that because they're early stage, it's okay to move fast. In software it's “move fast and break things.” But in hardware, if you move fast and break things, at best, you have a product that’s going to get returned, and at worst, you have a product that hurts someone.
It's really important to find the right speed and to avoid getting stuck in politics between hardware disciplines. If you get to that point, then you're not actually working productively towards your initial product market fit.