Peer Check
Peer Check

Episode · 3 months ago

#16 - The DNA of Highly Effective Engineering Teams in 2022


Every great feat of engineering comes down to one thing: the team that made it happen.

And whether you’re building everyday products that become part of people’s lives, or designing cutting-edge innovations that might end up on the moon — your success is determined by the way your engineering team works together, communicates, and gets things done.

So what exactly do today’s high-performing engineering teams have in common?

Based on 100s of conversations with ambitious teams along with our own research, we’ve identified the trends that set top teams apart. In this episode of Peer Check, CoLab’s CEO Adam Keating delivers a keynote address to share the highlights.

Listen as Adam breaks down insights on:

  • Why more F500 annual reports than ever mention faster time-to-market
  • How top engineering teams are commercializing new technologies faster than the competition
  • Practical examples of digital transformation sourced from over 100 manufacturing companies
  • 3 engineering processes you need to rethink for effectiveness instead of efficiency
  • The real opportunity for cloud technology in mechanical design 

More information about Adam and today’s topics:

To hear this interview and more like it, subscribe to Peer Check! Find us on Apple Podcasts, Spotify, or our website—or just search for Peer Check in your favourite podcast player.

Welcome to Pure Check, a colab podcast. This is a show for engineering leaders who want to challenge the satas quo for how design teams work together. You're about to hear a conversation about the ways the engineering world is changing and how top teams are carving a new path forward. Let's do it. Hello, everybody, welcome to this virtual keynote and today I'm super so excited to talk about the DNA of highly effective engineering teams and what we know about that in twenty two. First thing we're gonna talk about is why are all the fortunate companies talking more and more about speed, time to market and margins? What is causing that? What does that tie you into the way that we're working. We'll then dive into why teams are reframing effectiveness and efficiency, which part matters more now and how you uhould think about that. We'll give you three things you can think about. They're a little unconventional in terms of how how you can help your team today get better, and then we'll sum that up with what those DNA are. With that, let's jump right into it. So, first thing we're noticing after looking at you know, fifty to a hundred of the Fortune five D and it reports in the manufacturing sector is that there's two things that are happening. One is there's this extreme pressure to get things out faster, grow revenue targets, and improve cost margins. But at the second time, if you read the risk section and every single report, there is a lot of nervous companies out there because of the supply chain, because of COVID, because of war, because of talent, because things are getting harder and harder and manufacturer in a way that makes sense. And because of all of that, it's causing this inflection point in how we build hardware in all of our industries. There's automotive, you know, pure product development, medical, airspace, and defense. It does not matter. We are seeing disruption across the board as tume as to rethink how we do things. So start with one most controversial. You look at Tesla. Oftentimes, you know, people love Tesla or they hate Tesla. I think it's a really interesting case study because it's one company who's ultimately had two very different outcomes on two of their premier vehicles. You look at the approach to the models and now the Model three. That program got to market really fast, for an automotive program. It did two things. One is it's force electrification throughout the entire auto industry and arguably beyond the auto industry. I don't think if Tesla didn't push that ten fifteen years ago, we'd see such a competition today on the EV race. I think it'd be five or ten years from now. The second thing, though probably more importantly, is it's just fundamentally changed the expectations for delivering a vehicle to market. Companies were comfortable with fifty six sixty development windows. Now Teslas say hey, we're gonna do this in forty. That was the Model three. You then look at the cybertruck, a bit of an unconventional approach to product development. Probably the potentially doesn't quite hit the current truck own our market because of the style versus a Classic one fifty or a big dog Ram not quite an exact fit. If you look at this New York Times headline, it kind of says it all. Because they're not delivering the cyber truck despite having you know, a lot of pre orders, people are now starting to look elsewhere. I think it left a really wide door open for companies that are super hungry to come in there and frankly eat your lunch. So looking forward, right you bring in Jim Fairley. A completely new mindset at Ford has been established, and the forward lightning is taking people by storm is being talked about all over the place. I hear it talked about a collab honestly a weekly basis about people wanting to bottom and they're gonna get those to markets sooner and they're going to see return on that, and that difference in getting there for the Model three fast versus a cybertruck now being pushed out, could be the difference that initial market share, which is a huge thing for market competition. And if you really look at hardware itself, hardware is really hurt. And I think if you think about building...

...really company software, that is difficult. But there are things in hardware that no one else can explain. You've got supply chains to worry about, You've got actually team of building physical prototypes. It's extremely difficult to do true agile because there's things that are in waterfall that can't really happen the same way you would build software. And the list goes on and on and on. But the truth is, we make this way harder than it needs to be. And by we, I mean everybody in the hardware world. My backgrounds mechanical engineer, co founders, awsome mechanical engineer. We ultimately started Colab because we were frustrated with the way we worked, and we saw it across a bunch of different places, started in fortunate companies and energy, aerospace, defense, waiting, the startups, and medical generally even worked for Tesla, and the common trend across all of that was that things are just way too slow, way too painful, and they're not really focused on engineering. The dream you're sold in engineering school is not what actually happens when we get out of the workforce. Um And a really good example, like you're looking at and a picture off the Internet of the Testla Model three in part of the battery pack or one systems there and you see the connector DFM on that connector can take eight to twelve weeks, and that connector is like one of ten thousand parts in that vehicle. And it might be a small problem, but think about that in like a summation of what causes products are programs to go late? And you then compared to software development, imagine asking a software developer to take screenshots of their code, put it in the PowerPoint deck, send it to via email, and then they take it down on their desktop and send back some red lines. And that process takes six eight weeks or a pr Every single software developer would just straight up quit. You have none, there'd be zero. Yet as engineers we do this every single day. And that's a very small example of all the things that we think about and theres of how we can be better at getting products to marketing. Because on top of that, the expectation bar has gone up every single year since COVIDS happened. In particular, it's not COVID, it's recession. And it's not recession there's war. There's not a war, it's supply chain crisis. On top of that, every product is getting more complex. The expectations for better margins are always there from shareholders, and everybody is fighting to get things out the door faster. And when you look at like how probably development was done twenty years ago versus the way it's done today, the process itself is almost the exact same. Now. We had some breakthroughs in the late nineties early two thousand's with cat tools going mainstream. You know PDMS, PLM is coming out, you start seeing c A and the rest. But if you really look at how we work together, how we develop, we're pretty much still in a waterfall stage gate process that hasn't changed a whole lot. People have made things more efficient or automated little parts. We haven't rethought how we've worked in such a long time. And if you look at the inputs, we've magnified that by a factor probably an x. What we've done is we've created this bottleneck now that is making it near impossible to actually achieve the really lofty, ambitious goals when they should be achievable. We have gotten way smurder as an industry broadly. Yeah, we're still not moving that much faster. Why is that? And I think the thing you need to think about with this is not just a program. If you think it's on a program basis, you can look at, Okay, we were two months late or five million dollars over whatever, it's much bigger than that. This bottleneck doesn't just cost you a month or two or five million dollars in budget. It actually shifts out when that product goes to market. So if you miss a design problem, which we've all seen happen late in the game, pushes out a timeline. You're recognizing revue slower. Your competition is probably there earlier, so you missed it, a market chair, and ultimately that's going to compound on every single program you do, and our time, you're losing the long game. That's not true for everybody is starting to change, like respondamentally starting to become a belief that...

...we need to invest in how we work and not just in what we build, and people are starting to focus on how do we fix that bottleneck? And my thought is I think COVID in particular sparked people to think about, Okay, we could work remote, we could work around the world, we don't like printing stuff off, we could work in digital tools like Microsoft teams. But that's only the very first step. Like that is the absolute fundamentals. We need to get much better at thought. But the teams we really figure out how to fix the bottleneck and how they build products are going to win the long game because if you look at a simple example here, the same graph, same timeline, if you were able to take every single design iteration and do that twice as fast, you might be able to cut months out of that cycle. If you do that across twenty programs, the impact that over five years is going to be tremendous to your competitive position and doesn't take much more than looking at Apple, right, one of those famous companies in the world, both for their products and for knowing how and known for how they liver the products. They do developer launch events every single quarter. I mean, they do the big days, three four five million people signing online to see what they've launched. And it's not just because the products are cool. It's because everybody believes that Apple is going to build incredible products. And if you look at this, Apple said they're going to challenge and push on time to market, and every year since then they have without failed put a new iPhone out, they put out watches, they pushed advantage on laptops, they pushed the price point up in all these things, and it supports everybody else to behave differently to the point you know earlier this year where they had three three three trillion dollars in market value and ultimately just a machine now that are not just pumping up awesome products, but they've built a machine that pumps out absolutely incredible products. And the difference here is Apple is not playing the old game. The old game is focused on efficiency. It's what is in front of you and making a little better. Apple is setting the standard for how product development should be done. They are rethinking what it means to be effective so they can win the new game, which is going to be the next time to twenty years and and Peter Drucker said this like, really, well, you know, efficiency is doing things right. Effectiveness is doing the right thing. And if you stay, if you take a second, just think about in your day to day when people talk about getting better, they're almost always talking about efficiency. I've sat down with people in C suites, vice presidents, and the words I always hear are efficient. You read those and reports, you often see the words efficient. The question you should be asking is should we making this thing more efficient? Or should we not be doing this thing? At Paul and this is where startups really catch up to big companies because to be a startup and to win, you have to be ruthlessly focused. And ruthless focus us means you de prioritize everything else that isn't going to add tremendous value. If you look at these big companies, we do a lot of things. Have you really measured like does this fantasy widget we added to this new vehicle really matter? You might find I'm a complete waste of time money, and we're not doing enough job of saying do we need this both in the product and in how we work. So we did a survey about nine months ago with about a hundred engineering leaders and asked them how do they spend their time um and from that survey at the manager, director VP level, the average was eight to ten hours a week or spent literally just sitting in design review meetings. The meetings themselves, and if you think about your boardroom when you have one of these, it's often you know, five, ten, maybe even more people sitting around a computer screen looking at one person presenting, somebody taking notes. It's almost the least effective way you could possibly get your feedback. You're olligeness the things you know into...

...that conversation because I'm one person to do it at a time, and everyone else is sitting and waiting. And then what happens is the problem solving happens offline. The meeting should be for problem solving, yet right now it's the only means to cover up the effectivest gap. So when you go ask teams how do they do design your views? Will tell you meetings is the primary means for a design your view And I'd argue that that's crazy. Software developers very similar stream do not have meetings to review prs. They have meetings to review prs when they go wrong. What is a huge problem We default the meetings in the hardworre world because we don't know how to work together effectively. Look at number two, three, or four, or five and six on this list reviewing power point to pds. That's because we don't know how to share cat natively and actually work together on the actual data catss CAT screen shares and over the shoulder discussion a little bit better. If we're working together. A realist, at this point, we should be able to just talk fluently from where we're two and at the very bottom, we got PLM. It's one of the questions I always hear or i'll hear from skeptics, is you know our PLM does this? And we asked a hundred people that are in leadership roles, do you use your PLN for designer view and communication? And twelve percent said they do. And the answer is PLM is too complicated. It's not conducive to having an innovative, creative discussion with your team about these hard problems. And Ultimate has leading people into this world of doing things that are not effective at all. And when you look at this in a real world example, you take a program, let's say it's forty months budgets a hundred million dollars. If you take the lines of just making what I just showed you more efficients of better meetings, you know, better screen shares, all that kind of stuff, and you do all that really really well, you might turn ten percent. So you're talking thirty six months, nine million dollar budget, and that's if it's done really well. Say you focus on effectiveness first, same budget, same time on. You then question what should we be doing? So start with do the right things. That might be cutting some part of the product scope, There might be some rewriting some part of our actual product development philosophy, that might be moving a key part of our decision making earlier in the process so we don't have no downfalls later on. But doing all of that to eliminate the waste. All of us have saw this happen in lean. You think about manufacturing, yet we don't do this very well when it comes actually designing the products we're going to manufacture. Take that, start working on each of those processes to make them all a little better. So start putting those efficiencies into those processes that actually made the cut from the first pass. Because of that, and because you're invested in communication, you should be able to catch these mistakes earlier. And ultimately the end of the day a program could look like, you know, say thirty months months and maybe it's three quarters of that budget. But but just going for efficiency, you'd have to cut of all of that and as the next to impossible to see happening. When you think about this, there's a new working potential that we need because today teams think about you know, there's trible all the time, their speed, just quality, and just cost. And generally what people will tell you is that you can do two of them, but not three. So if you pick speed, you pick quality, cost is going to go up. You pick quality, you pick costs, speed is gonna go down. And that's ultimately the trade off that you've been wired to say we have to make as an engineering organization, what I'm going to tell you is that that's not true. It is true. If you're not willing to invest, you're not willing to make change. But if you are willing to invest and actually think about doing things in a more effective way, you put something in that can go through and you can actually pull out all three of those levers into a way that is favorable for you, along through a couple of examples later on. But doing that is the change we need now because going faster and reducing costs but having quality problems is not going to fix you winning the long game. It only going to help you fix a...

...short term problem. And right now we need to think long term because the whole world is just thinking about short term recession. There's a lot that's going to come after that. We're gonna keep going. There was a recessions as need and lots of other things go wrong. We're still here, but there's a lot of companies that aren't because they're very narrow sighted at the time. So the difference between the two, the teams that make very similar mistakes and the ones that are really investing in affections are pretty stark. I think the first one is that teams that are focused on efficiency and making the same mistakes are really focused on tools and technology versus the ones that are thinking about effectiveness are thinking about their team and how they work together. And then as a result of that, the last themselves, what tools do we need to actually augment and do that. You'll often see the graph of a plot where talks about people, process, technology, transformation. A lot of teams start at the transformation end. I would argue you need to start with a vision at the transformation end, the then come back to the people, fix your processes to make that work, tie the tools on that makes sense, and then you'll see that result on the exact same thought. Most teams are only thinking about incremental improvements, and there's a really good reason for that because they're underwater, they're underresourced, and things are extremely stressful, with very little power to make change. But if you're sitting in a leadership role, this is your opportunity to start with a small piece of change and challenge what your existing process looks like. There's nine times out of ten it's not the way you can most effectually do that, and that's what we see most effective teams doing is challenging status quo and rewiring your existing processes so they are effective. And the last one is the mindset. How many times have you heard someone say it works or it's not broken, and we've always done it this way. That is the most dangerous mindset you could possibly have when it comes to actually making a real change, because it leads to complacency. And all of us have done. As much as I would love to tell you that Colad has never fell victim to saying something like that, we totally have, but it's more on mindset generally that we don't and I don't think that's true and hardware often so the people are thinking hard about this, which posts should we change, how do we win the long game? Are really really getting ahead? And I think about this company that reached out to us probably three or four years ago. They came to a very specific problem about how their supply chain was working and wanted to turn their partners or suppliers into partners to be able to get through designer rations way faster. They had this really clear vision of a very specific part that was blocking them from getting to market faster. Two years later, they've got their entire supply chain running through this completely different way of working because they just picked a nugget and so stepping stones, we got one supplier work in the rest, and now it's just this beautiful transformation that started with something so simple because they picked the right spread, the right spot to start. So I think one good way to summarize this is that insformation happens by putting effectiveness first, so picking the right things to focus on, then making them hyper efficient, So doing the right things right, because ultimately, at the end of the day, we're not saying efficiency is a bad thing. I'm saying efficiency on the wrong thing is a bad thing, and that we do a lot of that. So questioning why we are doing something is one of the most important things you can do. Just the question why why is a really important question. And just like we do root cause, like for a failure analysis, you asked the five wise, we should be asking the five wise and why are we doing this? Why are we building this product feature? Why are we working this way? Why are we sitting with fifteen of us in a board room where fourteen people are checked out the whole time? Because that's not effective. So do the right things first, then do the right things right, and if you do that, there's ultimately a large upside for your team and being competitive, happy and successful long term. And it really just three unconventional places that we're seeing teams invest today that are...

...helping them get there because there's obvious things. Right. If your team is smaller and you don't have a PLM and you're trying that, you're just burning every end of the candle, trying to keep track of records and change out of control. That's an obvious, massive affections play wain you can make, but a lot of teams do today right a place we're optimizing little pieces and we need to take those bigger steps. So the first one is talking about how can we accelerate new product development catch mistakes much sooner by rewiring that design and new process we talked a bit earlier. The second it's really diving into turning your external partners are external collaborators in the true partners through tighter supply chain collaboration, so that's not an absolute pain to do. And the third one is reducing the cost of your product by making it engineering, lead, virtual and continuous instead of the current way it is today where it's extremely workshop focused. Only a few people's real true job and a very discreete basis. So if you think about just getting to market faster and rewire in this design view process, you know, the part that's not working is that the process is making it harder, not easier, for your team to do their job. If you ask most people do they like design of view in the engineering world, they probably tell you know, and it's because it's hard, it's slow. Oftentimes their feedback is not heard, or they're not involved at the right time, they can't find details. It's ultimately just a pain and usually just exposes things late, and ultimately what comes out of that is changes at the very end that are very costly to your company at this point, if you look at that bottleneck we talked about earlier, that bottleneck is what's killing us getting the market. If you think about what design of view really is, designer views and engineer's language to communication, it's the same way like a developer would have a PR as their language. We're really giving feedback and making sure something's done right. A designer view is exactly the equivalent for us building something in the hardware world, and that poor communication leaves the bad decisions, and bad decisions leads the slippage, delays, mistakes and all the rest. Because ultimately, design your view is one of those places you can drive effective is more than anywhere else because they often get the next step. They get us going to where we're going, and if we can do that better, that faster, do it sooner the right people. You can change where your team is working. Three things you can do to get started, and the first one is understanding what is your design view process, what is the standard and thinking about what parts should change, Like if you really are doing meetings every single day, or you're sending around PDF and drawings that you're pulling down, we will do none. Their desktops are printing off, ask yourself why we're doing that, and rethink how you want your team to communicate. The second part of fantas thin about how do you really get true engagement Because to get the people's best knowledge, best understanding, most effective work, they need to feel engaged. If they're disengaged and they're just doing a job and you're pushing them to do it, they're just gonna go through your view nonchalant and not get you what you really need. The more engage they are the better results going to be for you. And the third part, which I think everyone can take advantage of right away, is figuring out ways to make design of you asynchronous so that when you're seeing that boardroom with fifteen people, you're not just waiting for the other fourteen to come through. You could be offline taking ten minutes do your thing. Everyone sees what's going on, and then you come back and focus with a group of you know, a couple of people in a boardroom on a key problem or challenge to solve that thing. And I'll take a really cool example Cracking Robotics, public company in the subsea space, a leader and what they do. You know, four years ago we started talking to them about where they wanted to go and they had this really bold vision at the time of moving way faster and improving quality while they were going through the ISO certification process. And that sounded at the time kind of an oxymoron, like how do you do both those things at once? And isn't irresponsible? And ultimately they said no because they were frustrated with the way the industry standard tools were for you know, communicating our email slide shows for...

Big three d reviews, PDFs, meetings, trackers, all the rest. So they challenge and said, how do we just rewrite how we communicate and make design review decisions? And after doing that, they put all their design decision making in one centralized tool. Mechanical engineers electrical engineers can actually talk to each other with the native data right in front of them in a way that's either real time or a sync file sharing communication. All happens in context, and ultimately all that issue tracking where they're keeping track of themselves is just automated, because that's not An engineer's job is not to track issues. An engineer's job is to find and solve issues, and something else should be taken care of. What is the highest priority is it logged? Is the record there? That is work at a piece of software should do for your team. And the impact has been outstanding over these a couple of years. The first most important one is outside of moving way faster, they saw a year over your decrease in manufacturing errors. And that's incredibly That was the bold vision, which was moved faster or cut down the stakes. To do both those things at a time when almost no other team was is absolutely incredible The best part is they actually used this process then to get ISO certified and the team liked it. What other team has an ISO process that their team likes, I can tell you there's next to zero. I think that's truly outstanding. If you talk go back to that triangle graph, we talk to the new working potential, they're there pull data. Last week they did fifty six design reviews across about twenty people. That's like, you know, eight nine a day. Most teams will be lucky if they got two or three in a week, and they're doing that kind of velocity where they're going through three and four and five pieces of feedback closing in a week one week. We've seen other processes where teams can be open for two and three months on a cycle, and their cycle time now is a couple of days. And that's what's making a difference for crafting. If you think deeper about that and extend beyond just your internal team, you know there's a lot of value in your supply chain, both going down to your suppliers and then also to your customer um and turning them into real partners. The problem today is that it's next to impossible to share your most complex and important data in a way that's easy to use and secure. Email is not secure. It's easy to share depending on how big the file is, which often then you blocked, and then once you said, really, how does someone view it the download cab viewer Trying to figure it out like that is a horrible experience to everybody. Your PLM is good at keeping internal instead either expensive for your team your partners get a license, or it's really complicated, or it's both. At the end of the day, that friction means everybody goes back to email and they did the absolute bare minimum to just get by, because why would you make it harder? And that's killing the opportunity to turn your suppliers into partners, which you desperately need because at this point, looking at the current market, it your supply chain is going to make or break how this works. And there's more than just how to communicate. How do you think about inventory and strategy and parts being replaced is super important too. But if you don't have that relationship, suppliers are just about cost and that's not how you're going to win today. You need to leverage that expertise. You need to think about building resilience that supply chain so that when things get heard, you have a partner to turn to. So if you can reframe that relationship from supplier to partner. And I'm seeing customers do it today, you know, I hear to talk about trusted suppliers or trusted partners. People are doing this, but it's not everyone and it's not common. I think seeing that happen more and then really investing and putting your money where your mouth is, and there's making that easy and training them really late partners will make a massive difference because then you can get suppliers involved early on in the process. So when you get to that awful DFM review at the end where there's five piece of feedback, we can't build this thing. Change all costs too much. That's all considered upfront. That's...

...not your team's responsibility. That is suppliers expertise that they can help you with. Give you a great example of Honey Bobus Fortune Auto Tier one working with many of the big oms four years ago, really wanted to work tighter with everyone across their value chain, and there are teams in different locations the time him they found it extremely hard to get the right person, the right massive CAD file at the right time. Then on top of that, the O a M changes the data constantly because that's just the nature of the beast. You've got thousands of engineers working through this, and it's like, how do you actually keep up with all these changes? If one person is just passing data out to all these people in supply chain and the solutions not peeling here, they don't need appealing, they need to be able to communicate, and paying that kind of money with that type of complexity was not what worked in this particular case. So after involting on solutions to that, they're able to take that data and share with everybody in their internal team and supply chain in real time. Everyone has access to this with the integrity of what came from your PLM, knowing what is there and what is the latest without having to have, you know, an understanding of a full complicate PLM program. And the last part is it started this beautiful real time engagement of being able to have a meaningful conversation and sharing with both partners, customers and supply chain. And really at the end of the day, two major things happened. One was three quarters at a time they used to be spent in trying to fear to share a file and review completely cut out because now to take the file from the PLM, put it into the browser in secure location, invite someone to it, and everyone has it versus before it was taken using FTP might take a few hours fare to do that and get it over, pull it down and people can't view it. All of that's cut out. I think the coolest part is that both their suppliers and their customer really became partners in this had a different way of having a conversation all the way to the point where you know, suddenly this allowed them to have a visual representation of how they would build one of the core assemblies or via cris a vehicle during there a few process that just made it much more rich conversation. Showing that Hunda Mobis knew what they were doing, I knew that they were a partner. Also for an ultimate helped them win a massive contract several years ago. I think the very last part then is something that everybody can do because when I hear v a V or value analysis, value engineering, it's very hard to find people who are focused on If you search on linked in V A V. You'll find a handful of people that come back with that title in comparison every other engineering role. And in truth, we all need to think about it, people are you. We do, but not to the extent that's really necessary. So how do we really make cost reduction engineering lead? You look at the market today and the pressures were having. These targets are getting more and more aggressive, and there's not a real strategy to get there except where the targets getting higher and we need you to hit it is pretty much the emphasis most companies make. Most companies focus on workshops as a source for you know, crowdsourcing ideas, but the higher part then is on top of that is usually limited to several people because it's expensive to fly people around. And then someone's just characterizing all these issues, putting them in the list, trying to figure out what to do with them, trying to remember the context of discussion of all the sticky notes that were on the way board, and it's really not making effective for having a good innovative discussion. And at this point, how you do cost production is critical because if you're not reducing the cost of making your product better, both for the value for your customer and the cost basis for your company. You gotta cut costs somewhere else, and that means you have two choices. You're cutting people mostly or you're decided not to make that next higher. It is limited your capacity of the company. Targets are increasing every single year, whether you make them or you don't. If you make them and you're figuring out great, If not, you're having your compounding effect of how ambitious those things are, and then you're never really getting there and starts to distract you from the rest of new product development work.

So there's three things you can really do here. First one is you need to have a place that is conduced for anyone to be able to participate, not just a couple of people that typically to workshops. It needs to be accessible with the context that people can go there and actually contribute right away and be heard. The second is the shift from workshops centric to workshop augmented. There are places where you will want to fly people together for maybe a major event, or spend a day together on a video call, but a lot of times that's the wrong way to go about it. The more continuous this is easier it is for people to do when they have an idea, whether in the moment or something came up to share lessons learn the better it's going to be. And the third one is going virtual, and by that I mean going beyond just teams. Teams is not enough because it's the same problem as a meeting room. You need to make is that people have the information of their fingertips the same way as that they had, you know, a part of a chassis in their hand, looking at and saying, you know, how can I reduce the weight of this component or how can I take the down from a hundred components to fifty components to save it in manufacturing costs. Then you need to automate the admin. If the admin work is not automated, engineers are not going to volunteer to do this, They're not going to sign up to do more, and then it becomes somebody else's job and they're chasing people every day. So making it so that as accessible and automating the extra work is a critical part to make it accessible. I think a really awesome example of this is Johnson Controls in the industrial equipment space. They have this vision when COVID started that you know, We're not just gonna survive COVID, We're going to figure out how to build better products at a better cost. During code this was an opportunity which was a completely different lens than most companies took at that time, but it said, you know, we're not investing in anything. So the way it was set up very similar in most companies in person via events beforehand. You know, travel adds up. Only a few people can do it because you're going from you know, the US to other countries or bringing people together, and ultimately all the documentation after it's just on somebody and it goes to a black hole that is hard to keep track of. With bringing this into this virtual environment making it continuous, they're able to do way more events now it doesn't take the same set up. The event doesn't need to be a week. It could be two hours. It could be asynchronous, and way more people can be involved. I've seen them when there'll be fifty people involved across an entire product or for an hour and that one hour has produced twice as many high quality ideas as a full week would have. You got way better engagement and people actually have fun. People feel like they can engage and be involved in that process. And the beauty parrot is at the end of the day, all those ideas can be tracked writing context. So if you say, you know, maybe we can change this bolt whole pattern to five bolts or more standard flanage or whatever it might be, that's right there in the context of a three D model could be taught into your drawings or builds, materials, whatever it is, and nobody's worried about that admin work. And the ultimate impact of that has been cutting out a massive travel expense, almost four ex engagement across the engineering group place as many high quality ideas, so not just ideas, high quality ideas, so duplicates are being reduced. People are being engaged thinking about things that haven't been thought about before. Review times go from weeks today's and ultimately they're hitting massive targets year after year and people aren't drove nuts about going through the process. More people are wanting to be part of doing us and that's a huge cultural shift. So we some hold that up into you know, the d n A off those types of engineering teams. An example of cracking you know mobis Johnson Controls. There's many more, but there's a couple of key things that tide those all together. And it all starts with the leader. It all starts with the engineering leaders who are in those companies, because without them, change is absolutely not going to happen. And if you look at Cracking Mobis, Johnson Controls, there was a manager or a director or maybe both in each of those companies who had a vision and who were...

...weren't afraid to get ahead of the market and say, even when times are tough, we're doing this. We're gonna focus on getting short term value, We're gonna do the right way for the long term. And that today has set those companies up because we're move in way faster than their competition when things are really tough and you go through a recession. Now they don't need to have quite so many people, and they're not in the same pinch that their competitors are. The second one is that they've adopted an effectivest mindset and they've challenged what they should be doing all together. So they're doing the right things first than doing the right things right. When you take that and you couple it with like really investing what I'll call the machine. So if you look at like go back to the example of a vehicle company. How they build vehicles is almost or maybe even more important in the vehicle itself, as you can see by the example of model three in the cybertruck, and it's really hard to tool up and mass produced a vehicle. Investing in the machine of how you design products is equally as important as the actual product that comes out. So teams we understand that how you work as a competitive advantage are the ones that are making these investments and deposits and getting to that new working potential. They're then doing it differently. Um they're not starting at the end where they're only a transformation technology. They're starting with the people and saying, what is you know, a problem in the space that we can solve right now that will help us get towards that angle, that behavioral change, that big rocket moving. So they're thinking big, starting small, iterating and growing that solution and that mindset. It's more people involved, it sees wins, it shows are y and it doesn't require a four year implementation period to just figure out that a tool did not work. And the last part, which is probably the most important, is that although they're thinking big, interesting about the company and these big macro topics if you know cash flow or probably deliver your time to mark or whatever. They're still in touch what the end user suffers with day to day. Because if you're just passing down some massive change to an end user and you haven't thought about how they work, how it makes their life better, you're not getting the engagement. And then you're pushing change versus the end user pulling change. And when that happens, you see a snowball effect and that's what really will drive the next step in that growth. So investing, you know, in what matters to the business, but then also thinking about the end user is a critical part to making that happen. And what I'll leave you with here is just a simple question. Does your team have that DNA of a highly effective engineering team? And for most you probably won't today, and that's okay. Being aware of where you're two it is huge. If you've got a couple of them, that's huge. But the next step is what you do from here. Do you go back and you know, go back to it doesn't it just works? Or do you start challenging, in the toughest times what we really should be doing and how we should be doing it, so when the next recession comes along, you're already way ahead of everyone else. Colab is a mission to accelerate the pace of engineering innovation by giving design teams a better way to work. As an engineering leader, you know it's crucial to empower your team to do their best work. Let Collab help you achieve your goals with our web based tool that makes it easy to share and review CAD files with anyone so you can focus on the work that batters without missing a beat or a bolt. Learn more at Collab software dot com. You've been listening to pure Check, a Colab podcast, keep connected with us by subscribing to the show in your favorite podcast player, and please leave a rating on the show that helps us keep delivering conversations about how the engineering world is changing and how you can challenge the status quo. Until next time,.

In-Stream Audio Search


Search across all episodes within this podcast

Episodes (20)