Hello and welcome to another exciting episode of the Being an Engineer podcast. Today, we have the privilege of speaking with Devon Copeland, an accomplished engineer with extensive hardware and product design experience. He's currently the co-founder and CTO of Serial, a company that aims to streamline manufacturing data analysis, making it easier for engineers to swiftly identify and resolve production issues. Devon's background includes significant roles at Apple, Tesla and Arion Labs, where he contributed to high-profile projects like the Apple Watch Ultra and the Tesla Model 3. Devon, welcome to the show.
Devon Copeland: Thank you so much for having me. It’s great to be here.
Aaron: You've worked at impressive places and on cool, high-profile projects. I'm excited to explore your experiences but let's start with a simple question: What made you decide to become an engineer?
Devon: When I think back to my childhood, many engineering-related memories come to mind that paved the way for what was to come. But one of the most formative memories, probably my earliest, was of my grandfather. He was a civil engineer and one day, when I was seven years old, he brought me to the local library in Vancouver, Canada. They were holding a popsicle stick bridge-building competition. We weren't in the competition that year but we watched as these bridges were loaded with weight until they failed. I became enamored watching it all.
The following year, we entered the competition together. It was unfair to have a practicing civil engineer team up with an eight-year-old but we did it anyway and it was a lot of fun. Over the years, my grandfather greatly inspired me to become an engineer. I owe a lot to him both in my career and childhood.
Aaron: Your grandfather sounds like a special guy. What a great story about how you became an engineer from making popsicle bridges. We recently did something similar here at Pipeline. We had a team-building event with spaghetti, straws, marshmallows, a yard of scotch tape and a yard of string. The challenge was to build the tallest structure possible with the marshmallow on top. It was a lot of fun.
Devon: I love that. The best innovation often comes out of scarcity. Some interesting ideas can come from having a limited set of materials to work with.
Aaron: Totally. One of the teams hung their construction from the ceiling tiles, which sparked a debate on whether that was fair or cheating but technically, it wasn’t against the rules. So, we let it slide.
Devon: That’s out-of-the-box thinking.
You participated in the American Solar Challenge when you were in college. It sounds like a fun project. Can you give us some background about the challenge, some hurdles you ran into and how you overcame them?
Devon: Sure. I studied engineering at the University of Waterloo in Canada. Like many other engineering schools we had student design teams. I was most interested in the solar car team and their Midnight Sun solar car. The American Solar Challenge is the pinnacle of solar car competitions in North America. It’s held every two years in different parts of the U.S. In 2018, we raced from Nebraska to Oregon—a 1,500-mile course on real roads.
Aaron: I had no idea it was that long.
Devon: It's a fantastic competition. The cars are powered by the sun and teams undergo a two-year design-build process. One of the unique challenges at Waterloo is that students go on internships or co-ops every four months. At any given time, a different cohort of students is on campus. It's like running a company where half the employees leave every four months and you get a new team. So, communication and project management were enormous hurdles for us.
Aaron: Were there any special tools you used to facilitate communication?
Devon: At the time, we were using the Atlassian suite, with Jira, Confluence and Hipchat—which was the precursor to Slack. Productivity tools were great but honestly, it was just about over-communicating. There was lots of documentation, meetings and video calls when people were remote.
Aaron: How long did it take to complete the drive?
Devon: It took around ten days total.
Aaron: And do you build on previous designs every cycle or do you start from scratch?
Devon: We try to build on prior successes. Starting from scratch every two years would be a lot. It’s beneficial to iterate on previous designs, which is not unique to solar car teams. Formula SAE and Formula One do the same. All contests seem to do this.
Aaron: Speaking of products, let's discuss your time at Apple and Tesla. Tell us about some of the projects you worked on and what design principles or philosophies you took from those experiences.
Devon: Unfortunately, I can't go into too many details because of confidentiality agreements but I can share how those roles shaped my thinking around the engineering decision-making process. In school, I had this idealized version where you formulate a table with criteria and constraints, apply weights and out pops the perfect design. But the process is more of an art than a science in the real world. It's about using intuition and design thinking alongside complex data from experiments and simulations. You're also dealing with real people, company politics and trying to convince others that your design is the best option. That's something I learned to do at Apple and Tesla.
Aaron: I love that you're talking about the non-engineering aspects of engineering. Can you think of an example where you had an idea you believed in and had to convince others it was the right path?
Devon: Definitely. Many times, I had an idea that differed from someone else's. I've developed tools to articulate designs and have productive discussions over the years. One of the essential tools is storytelling. It's not just about presenting facts; it's about telling a story that brings people along with you. Using visuals and slides to communicate ideas was something I honed in those roles.
Aaron: I have a background in photography and I've always appreciated the importance of visual appeal. Did you use graphic design or video editing skills to enhance your storytelling?
Devon: Yes. One useful technique for me was using animations, often GIFs. I'd make a little macro that took a series of screenshots from the same perspective in CAD, stitched them together and turned them into animations. These would be used in presentations or emails. Having motion in your visuals can make a big difference.
Aaron: That's such great advice. A lot of people will be able to use that tip right away. For listeners who might be considering a career in product design, what advice would you give them?
Devon: My most extensive advice is to work on side projects in your spare time, especially projects that excite you. It doesn't matter if it's related to your career. What matters is that you're learning something new. For example, I picked up web development during the pandemic and while I was working as a mechanical engineer at the time, that skill came in handy when I co-founded Serial.
Aaron: That’s fantastic. Side projects are invaluable. Let’s talk about Serial. Can you explain what it is and why you started the company?
Devon: Serial is a traceability-first manufacturing software. Traceability is about tracking and documenting components' history, location and usage throughout the manufacturing process. We think of it as creating a digital twin for every product produced, where all manufacturing records are tied to this digital twin. My co-founder and I saw a gap in the market with no traceability tools especially for small to medium manufacturers. That's why we started Serial.
Aaron: That's fascinating. Traceability seems to be becoming more important in the manufacturing world. What are the most significant benefits to companies using a system like Serial?
Devon: We often get confused with the breakfast product but we are Serial as in "serial number."
Serial is a traceability-first manufacturing software. What do I mean by that? When we think about traceability, the typical definition you might find on the Internet is tracking and documenting the history, location and usage of all your components throughout the manufacturing lifecycle. But we think of traceability differently at Serial. We envision having a digital twin for every product you produce where all the manufacturing records are tied to this digital twin that exists in your traceability system.
Traceability—having this digital twin—is usually done for one of two reasons: either for quality purposes or for regulatory compliance. This is often the case in industries like medical devices, which you're familiar with. It can also be done to improve analytics and make it easier to run experiments on your production processes or parts.
When my co-founder and I looked back on the software we had used in our past roles at companies like Apple and Tesla—and especially at smaller companies that didn't have the same resources to build their tools or afford expensive software—we realized a significant gap in traceability. That's why we started Serial. We wanted to create the best traceability tool for small to medium-sized manufacturers that need a robust system for tracking all their manufacturing data and managing digital twins.
Aaron: So, when you say traceability tool, is Serial a PLM or should we think of it differently?
Devon: We can think of it as a lightweight MES, more on the manufacturing side. MES stands for Manufacturing Execution System and Serial is a MES that has a robust traceability component. That means we can track the genealogy and the as-built bill of materials (BOM) of your products and any data you want to capture. For example, if you know a dimension on a part, you can plug that into Serial. If you want to know the final quality inspection report produced by an automated test fixture, that can also be plugged into Serial. Operators, station IDs, dates and lot codes can all be recorded in Serial.
Aaron: You talked about having an automated fixture feed data into an MES. We just delivered a piece of automated machinery that we developed and this machine has some vision systems in it and glue dispensing. Two side covers receive glue and then the vision system inspects that glue to ensure that sufficient volume of glue has been deposited and in the correct locations on the side cover. Then, the two side covers are glued together. Every time an inspection is performed with this vision system, it takes some pictures and there's a pass/fail criterion. So, this is the sort of data that you are thinking would be fed into Serial?
Devon: Absolutely. There are at least three or four different data points you just mentioned that somebody could be logged in Serial and could be of great use if there was ever a quality issue, a recall or some concern down the line when you're manufacturing these parts. As you mentioned, the picture, the pass/fail result, the volume of glue applied and so on could be uploaded. If you had multiple stations or glue dispensing fixtures, you might also log the fixture ID. Later, you might find a trend associated with the fixture itself—maybe one fixture dispenses glue sub-optimally. All that would show up in the data if you tracked and traced it correctly in your system.
Aaron: Let’s say something does go wrong in the field, like a device fails. What’s an example of how data from Serial could be pulled to help identify the root cause?
Devon: Absolutely. One thing that comes to mind is a failure analysis strategy called commonality analysis. When doing failure analysis as engineers, it's often easy to figure out what went wrong but not why. Getting deep to the root cause can be challenging and that's where commonality analysis can be compelling. It allows you to aggregate a few or all of the failures of the same mode together. Let's say there was a glue failure on four or five parts. You could take that sample of parts and ask, "What's similar between all of these?" You play a game called Spot the Difference. What might shake out is that all of these parts went through the same glue fixture or had a low range of glue volume dispensed. You could also look at the pictures qualitatively and identify if there's a specific pattern. Running these commonality analyses becomes easy in Serial when you have good traceability on your components.
Aaron: Does Serial include the tools for running these analyses or do you export the data and use external tools?
Devon: We do include those tools. We're an analytics package, database and data collection package.
Aaron: Very cool. Talk about MES systems. There are MES systems out there, so what did you see as lacking in the market and what hole are you trying to fill with Serial?
Devon: Absolutely. A lot of this comes down to the challenges that manufacturing engineers face when analyzing and running experiments on their production lines. Getting high-quality analytics and running experiments on manufacturing lines can take much work. Why is this? It comes down to two things. One is a tendency for engineers or manufacturing processes to ignore the product's genealogy when considering data collection. The second is having very disparate methodologies for collecting data.
What do I mean by this? From a genealogy perspective, engineers—especially mechanical engineers—understand the idea of having a hierarchy or genealogy in their CAD software. You have sub-assemblies, top-level assemblies and individual parts. But when you get to the manufacturing line and start thinking about data collection, that takes a back seat. We often collect data wherever we can without structuring it the same way the product is built. This makes it challenging to run high-quality analyses later on.
The second aspect is disparate methodologies for data collection. You might have data in a spreadsheet, another set of data in a notebook and even more data on a network drive. Having these different locations to collect data can be a challenge. What Serial does is solve these problems. We structure the data like your product is built, respecting the genealogy and hierarchy. We also give the data one home, allowing you to collect from various sources on your production line—even from different production lines or factories in other countries.
Aaron: Very cool. If you could summarize the environments for which Serial is the best fit—where it’s a slam dunk—and conversely, where Serial might not be the right tool, what would you say?
Devon: We specialize in complex electromechanical assemblies with many serialized or lot-controlled parts that go into the final assembly. So, if you're injection molding plastic forks, Serial isn't a great fit because each plastic fork has its unique identifier. But in industries like aerospace, medical devices, personal electronics or industrial equipment, many sub-assemblies and piece parts have lot IDs, material IDs or serial numbers that need to be tracked. Serial is designed for those industries where you want an as-built genealogy or BOM for every product you produce.
Aaron: Great example. If I have a manufacturing line right now and don't have an MES but I know I need one, what preparation should I make to make the integration process seamless?
Devon: The best thing to do is get familiar with the MES space before diving in. Any manufacturer thinking about bringing on an MES should first explore the space. Schedule meetings with companies and demo calls—you'll learn much from seeing available options. Making changes internally is costly, so don't touch a process that's already working. First, go and learn. Once you've done that and picked out a solution, it's essential to have clear documentation of your process flow. Different MES software can help with this by providing built-in flowcharts and ways to visualize the process. Having everyone on the same page and knowing what happens at each step is helpful. Additionally, documenting SOPs (standard operating procedures) or work instructions helps communicate how your process runs to whoever is implementing the MES.
Aaron: What about the details of how your production equipment communicates with an MES? Are there foundational elements, like specific types of hardware, that need to be in place for the communication to happen?
Devon: The most significant requirement is some network connection. People often want cloud-connected or internal server-connected machines on the factory floor. So, you first need an on-premise network or Internet access for these devices to communicate with. There are also options for cellular connectivity, so Internet access on the factory floor isn't always a hard requirement. The first thing to figure out is how you will upload the data. At Serial, we have a public RESTful API, which means any device connecting to the Internet or a local network can request to upload data. But with specific instances like PLCs or other hardware, it’s on a case-by-case basis and it's best to reach out to the MES provider to figure it out.
Aaron: Serial is a startup. How long has your team been working on this now?
Devon: Nearly two years.
Aaron: Congratulations on approaching two years—that'll be a significant milestone.
Devon: Thank you.
Aaron: What have been some of the biggest challenges you've faced as a startup? Are there any surprises, good or bad?
Devon: One of the significant challenges for us has been getting the word out there. Engineers, me included, often fall into the "If you build it, they will come" trap. I certainly thought that. I thought, "I'm going to build this great piece of traceability software, this lightweight MES for manufacturing and all these manufacturers will come knocking." While we've had a great customer and early adopters' feedback, you must put the word out there. People need to be made aware of these new, emerging technologies and trends. All too often, people stay focused on their day-to-day work.
Aaron: What have you found effective methods for getting the word out about Serial?
Devon: We've been creating a lot of video and multimedia content. It's engaging and helps people understand the product. Our user interface is simple but some of the ideas we’re communicating require more time and visuals to explain. Having videos and multimedia posts on social media has been helpful.
Aaron: Which social platform has been the most effective for finding your customers?
Devon: LinkedIn has been the best. People are on there from a professional, working perspective.
Aaron: We've found the same. I read a bit about Serial's Grid Builder and how it simplifies the analysis of sub-assembly data. Can you talk about that?
Devon: It's best to explain the Grid Builder with an example. Let's say we're building a medical device of various parts and sub-assemblies with a PCB, some sensors that connect to the PCB and an injection-molded housing. All of these parts have their sub-assembly processes. There might be incoming quality inspections on the housing, flashing and firmware uploads for the PCB and tests on the sensors before final assembly. You're collecting data along the way and at the end of the line, all these parts come together for a final functional test. The device then goes off into the field.
When you’re a quality engineer or manufacturing engineer trying to understand something—say, you want to know if there’s a strong correlation between sensor-level testing and the final testing at the end of the line—that seems like an easy question to answer. But often, it’s an hours- or days-long process to aggregate data from different places. You’d have to join data from different serial numbers. Data from the sensor might be serialized to the sensor sub-assembly and data from the top level is serialized to the top-level assembly. So, you’d spend time with VLOOKUP in Excel, stitching things together. The Grid Builder makes this super easy. You drop in a list of serial numbers and then you can drag and drop any data point you’ve collected on your manufacturing line—cycle time, operator, sensor test measurements—and build your table the way you want it. We’ve also released a companion to the Grid Builder called the Graph Builder, which does the same thing but for graphing.
Aaron: That sounds awesome. Would it be accurate to think of the Grid Builder and Graph Builder as Excel on steroids, built specifically for analyzing sub-assembly data sets?
Devon: I love that characterization.
Aaron: One last question: Are there specific tools or processes you learned at Tesla and Apple that you've applied to Serial? What's one thing you've done to accelerate the speed of engineering?
Devon: Our mission at Serial is to automate busy work so people can focus on the tasks and decisions that matter. Our customers feel this when they use our product but we also apply that mentality internally to building software and running our company. Some of the things we've done to accelerate engineering are automating validation testing. Every time there's a new software build, we have a suite of tests that run to ensure we're not fixing one thing and breaking another. We also have a robust style guide of reusable building blocks, kind of like Lego bricks, for building new user interfaces. This makes the UI clean and uniform but also accelerates how quickly we can push out new features. We try to eliminate the mundane tasks and busy work so that we can focus on the bigger picture.
Aaron: That’s terrific. Devon, it’s been a pleasure getting to know you and learning about Serial. Thank you for sharing your insights with us. How can people get in touch with you?
Devon: The best way to reach me is LinkedIn. Just search for Devon Copeland. I'd love to connect with people in the hardware engineering space. I'm a huge hardware nerd, so I love hearing about what people are working on. You can a
Recommended Comments
There are no comments to display.