What Would You Say You Do Here?
The Bobs: image courtesy of Gregory Classics
“What would you say you do here?” This is one of my favorite lines from the movie Office Space; a movie that feels hauntingly familiar to anyone who has spent any amount of time in corporate engineering. And, as Milton Waddams found out, it’s important to have a good answer. It makes sense, then, that the first article I write for my new company explains what we do and why.
Why?
I knew I’d grow up to be an engineer from a very young age. My first-grade teacher told my parents it was “abnormal” that for our class project on our heroes I chose – not famous athletes or movie stars – but Thomas Edison, Albert Einstein, and Henry Ford. She may not have been wrong. I always had a passion for cars, trucks, tractors, you name it. I grew up reading stories about engineers like Carrol Shelby and Kelly Johnson. It was only natural that I would go on to become an engineer. So, I went to college, got my degree, and found a job. I was ready to make my mark on the world of engineering.
I was in for a rude awakening. It’s not that I didn’t enjoy the work; in fact, I’ve worked on many great projects with some great people. It’s just that everything seemed so…. difficult. Not technically difficult; there’s nothing I like more than a good technical challenge. Things were operationally difficult, as though someone had poured molasses on the gears of the engineering machine. Why was this the case? Is it because the people involved were not smart or talented enough? No. Did they not work hard enough? Again, no. It took me years to figure it out.
What Google Gemini thinks of the engineering machine.
I think the best way to illustrate the issue is by example. This is a real example that I have witnessed in person. This is an extreme case, but I think it’s emblematic of the issues at large. Names have been redacted to protect the innocent and guilty alike.
Imagine your task is to design a simple EV gearbox. Nothing groundbreaking, just a single-speed, 2-stage helical gearbox. You’re going to need some gears; that’s 1 engineer. You’re going to need bearings to support those gears. That’s another engineer. Does this engineer analyze and select suitable bearings themselves? Well, no. They send requirements to bearing suppliers and ask the bearing suppliers to recommend suitable bearings. What about the housing? That’s another engineer. The housing engineer is also responsible for the seals, right? No, that’s another engineer. Well, two engineers, really, because that guy just does static seals. Shaft seals are another engineer.
Okay, that seems like a lot of people, but we’re done right? They’ve got it handled. Well, except none of them do CAD, so we’re going to need a CAD guy. And if you want parts made, you’re going to need some drawings. Those are done by the team overseas to save a few bucks. Then, you want to make sure these parts are going to work before you just go into production. Well, you’d assume the responsible engineers are in charge of analyzing and validating their parts. Nope, that would be the validation engineer and the separate team of CAE analysts. There are separate teams for requirements management, DFMEAs, and functional safety. I could go on, but I think you get it.
With that number of people involved, how are they all going to work together to pull this off? Not easily, that’s for sure. As the number of people involved grows, the overhead required to communicate and coordinate action across the organization increases exponentially. The opportunities for errors in communication grow significantly. Conflicting priorities among the different teams involved create tensions that can be difficult to resolve. Agile decision-making is slowed by the atomization of responsibility and decision-making authority.
So, what’s the point? The point is that, for decades, none of this was a problem. In fact, if you’re in an industry with a relatively slow pace of change, with a range of broadly similar products, this may be the best way of doing things. That one gear engineer can manage half a dozen programs or more. Rather than have everyone do their own analysis, you can consolidate that work into a single team. This reduces software license costs and (in theory) reduces the risk of mistakes. As long as the scope and pace of change stays low, the overhead costs that result from this structure are not a problem.
Here’s the problem. The industry today is not one with a slow pace of change and broadly similar products. What we’re seeing today is a pace of technological change and variety not seen since the early 1900’s, when it wasn’t clear whether the future of cars would be gas, electric, or steam. It wasn’t totally obvious that this whole “horseless carriage” thing would even pan out. Just 10 years ago, the number of electric vehicles available for sale could be counted on one hand. The number of plug-in hybrids could be counted without having to take off your shoes.
Get with the times, ladies.
This is just the beginning. It’s becoming increasingly clear that different application requirements and consumer demand mean that transitioning to pure EVs across all applications is going to be infeasible for the foreseeable future. This is going to drive an explosion in the variety and complexity of automotive powertrains to suit different applications.
Today’s OEMs and Tier 1 suppliers are massive organizations and as they say, “big ships turn slowly.” The same structures and processes and cultures that functioned for so long have become a significant hinderance. They are struggling with the challenge of developing the complex and varied solutions needed quickly and cost-effectively. So, now that the parade has been sufficiently rained on, what is to be done about it? What’s needed is an industry partner that brings a fresh approach to solving today’s challenges.
What We Do Here
So, what would we say we do here? At Coder Research & Engineering, our mission is to lead the creation and development of innovative technology that advances the state-of-the-art of high-performance vehicles. In this case, “high-performance vehicles” includes not just sports cars, but commercial vehicles, off-highway vehicles, and anything with demanding performance requirements above and beyond the typical passenger car.
We do this using nimble, lightweight processes and a multidisciplinary approach that allows us to deliver solutions faster and more efficiently than a traditional engineering organization. We offer the speed and innovation of a startup with the industry experience to avoid having to relearn the lessons of the past. We are built differently to help our customers deliver projects faster, more cost-effectively, and with higher quality than once thought possible.
We have the experience necessary to support the increasing complexity of powertrains on the horizon, including:
Electric Powertrain Design & Development
IC Engine & Powertrain Design & Development
Hydrogen, Propane, Natural Gas, & Other Alternative Fuel Systems
Advanced Fluid & Thermal Systems Design & Development
We have a history of successfully delivering projects for customers in the Automotive, Commercial Vehicle, Military, and Off-Highway markets. Serving both OEMs and Tier 1 suppliers, we cover the full range of development from vehicle-level analysis and systems engineering, down to component design & validation. From design studies to product & system development and low-volume production, Coder Research & Engineering is your ideal partner for your toughest projects.
Reach out to us today at: contact@coderengineering.com
Evan Coder, P.E.
Founder & Chief Engineer
Coder Research & Engineering
