Peer Check
Peer Check

Episode 7 · 8 months ago

#7 – The Science of Engineering Collaboration w/Dr. Alison Olechowski


The idea of the “solo innovator” working alone on an invention is pretty familiar to most of us. But when it comes to complex mechanical design, engineering is inherently collaborative work. Great breakthroughs don’t come from individuals; they come from teams.

Dr. Alison Olechowski, Assistant Professor at University of Toronto, joins host Adam Keating to share perspectives gained from leading multiple studies on the impact of collaborative practices in engineering.

Listen to the full episode as Alison and Adam discuss:

  • The results of successful collaboration
  • The benefits of designing collaboratively
  • The need for stakeholder input in co-design
  • How to create opportunities for co-design
  • The future of design engineering 

More information about Alison 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 peer check, a Colab podcast. This is a show for engineering leaders who want to challenge the sats 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. Welcome to peer check. I'm your host, Adam Katy, and today we're talking about the changes that are happening in engineering, design collaboration and what's actually making engineers happy and productive. My guest today is Dr Alison Elchevsky, nyc Queen's engineer leading the ready lab at University of Toronto's an assistant professor and do is an absolutely incredible research and user studies to help us figure out what we need to do going forward be better. Alison, welcome to the show. Thank you, Adam. Fun To be here. I want to get right into like just what is the ready lab and why did it become so focused on engineering collaboration? How did that all come about? Well, the ready lab is my research group at the University of Toronto. I really love being a professor. It's pretty cool the amount of autonomy you get, and I built the ready lab as center to study engineering, design collaboration. So that means that I hire Grad students who come into get their masters in their PhDs and they do research under my supervision and then we generate papers and insight and we try to it with the world. And so how it came to be is that I've always been interested in collaboration. I guess I've always been interested in design, and many folks study design and and many different ways. When I was starting out as a professor, I had to try to find a topic that I thought was interesting and compelling at and had a bunch of research questions associated with it, like something that we weren't really certain about how it works. And as I explored different topics, I kept coming back to collaboration, partly because, like, the products that really matter these days are just increasingly complex and so we can't design them on our own. We need more people. And then secondly, I was just feeling like we have great tools for like specific domains. That's kind of like not old news, but you know, we've really figured that out. And what sort of bottlenecking design is the interfaces between people, between domains, for example. Broadly speaking, yeah, my lab looks at engineering design, but a lot of our projects are looking to improve the way designers collaborate with each other when they're designing their products. I'm going to say thank you right off the hub for actually diving into this, because I think lots of people know it's not great and lots of people knows lots of challenges and opportunities. The very few are actually putting, you know, rubber hit in the road here and actually figuring out what needs to be done and it's a place that I think, like you said, there's so much investment in. You know how people build software and there's there's an opportunity now for you build in physical products and complex products to really accelerate that...

...pace. I guess super cool. There's like some actual, real tangible inside on their side of that. So I'm really interested. You wrote you're releasing tons of papers, tons of insights every year. It seems like your students are incredible, based on what I can tell from reading the work they're doing. I'm curious, like just off the hot foes a lot on collaboration. What sort of your initial gut reaction to the research over the last three, four five years? Like give us sort of the synopsis of what you're seeing broadly happen in the industry. Well, I think I think it's a super interesting time to be studying collaboration for a bunch of reasons. So one is that, like researchers have been talking about collaboration for, you know, forty, forty years now, especially when it comes to engineering, but only in the past few years has the internet become so ubiquitous and computers have become so powerful that collaboration is becoming much more practical at scale, and I'm sure you guys know this at Collab to you know, we used to talk about distributed teams as sort of an exception. Now, especially if we factor covid in and sort of the like natural experiment that the world went through in terms of working virtually and distributed teams, it's just so much more common, and so I think what's really been interesting in the past few years in terms of research studies is, well, okay, I'll say I think everything's interesting because we're just starting to describe the differences between collaboratively working and working by yourself. I think the default for so long when it came to looking at the way engineers design is to imagine them really designing by themselves in it in a cubicle on a computer workstation that's not well connected. There's a so, so much to be learned about what happens when we collaborate more seamlessly, I guess, which can be really cool because we can draw on findings from different fields. So, for example, if we look at Psychology Research, it tells us that, like, humans are generally more engaged in their work when they are working with someone else. Like that's true generally in work. Before some of our studies it's never been really looked at specifically in engineering. But we thought, like you know, engineers are unique, but not that unique. It's got to be true here too. Their studies in other fields that say, like when you work on a team you can be more creative like that. That should be true in engineering to or maybe you can discover more errors more quickly. Again, that should be true in engineering. And so it's been just neat to kind of scratch the surface of exploring these principles from other fields but in the context of engineering design. It's funny too, because a lot of those things have like small nuances on the Engineering Front. I think that's where the really interesting insight happens. Like I remember you telling me ages ago about this study you did where you actually watch the emotions of somebody collaborating with someone...

...while doing cat as. I think it was an on shape study at the time, and you were saying like you could see they were happier, and like happier is like a thing that isn't measured in the engineering feel very often, where as you look at software company MPs, like truly like employee Ne Promoter score is one of the most fundamental things people measure. You go to an engineering org, like that's not what's being talked about. We're actually talked about retention problems and attracting talent or not like tying the two things together. That like people aren't happy. So like that's why they're leaving and not coming, and it's like there's so much there to kind of unpack. I'm curious, like on just like the new generation of cat you particularly on shapes, and I think about even design will right, we use fake my every day. We live in slack, we live in teams of a notion. Everything is kind of real time together. whilstend some of the big takeaways from seeing engineers transition from as classical desktop cat to something that is more real time, collaborative and gets people feel like they're actually working together. Well, maybe I'll talk about that study that you mentioned where we had we did a user study. So we had designers come into our lab and we randomly assigned them to one of two treatments. We would call it. Either working on the cat task by themselves or are working on the cat task with the partner. And you're right, we used on shape for that study and we were able to record not only the screen that they were working on to kind of see what clicks they were making in cat, but also their faces, and we used a Technicolo alogy called facial emotion recognition to look at there, at their emotion as they were catting up the it was actually a toy car that we asked them to design, and then we could we could sort of match those two data sets, so emotion, with what they were doing in cad and you kind of already talked about some of the most interesting findings, which is just to say that catting with someone else was, in general, more highly emotional experience and it it you're right that the nuances of cad matter here. So some something that was quite interesting was it's more highly emotional when it comes to positive emotions, but also negative emotions. Like, I know you're a guy who's done a lot of cad. We've all trained in CAD in our own singular workspace, working by ourselves, totally in control. We know our own ways of catting, and then our participants came in and we're using on shape, which is like a multi tenant cad environment where you know someone else can be in there making changes in the same way in the Google docs that could happen and they could be actually breaking your your tree, for example, or making changes you weren't expecting. So we saw some negative emotion, but we also saw a lot of positive emotion, which is pretty cool because the research says that we should see positive emotion when we're working with someone else, but it says that working through a computer will mediate that. So like the most highly engaging positive experiences facetoface and it kind of lessons as we go through a... But our study showed like it. It doesn't dampen it that much. We still have highly emotional, highly positive emotional experience when we're working through a computer and we just saw some like funny anecdotes from our participants. They would be chatting and they would be making jokes to each other. A funny thing we noticed was our jokes make our partners laugh, but they we also really like to laugh at our own jokes, which is kind of funny, it's true. And so yeah, that was a really neat study where I think we kind of let two worlds collide. Like for some reason we're not that used to talking about emotion in the engineering world, but you're absolutely right in what you mentioned, like we should be thinking about the engagement and the emotion of our designers, keeping them happy, making sure they're learning and having fun. I think in most engineering cultures that's something that we're looking for. It's interesting because we here so much about companies talking about having a hard time retaining employees. You have a hard time attracting employees. I'm starting even now here in corporate fortune, five hundred reports that like one of their big initiatives is to attract the next generation into their company, and it's like that is such a different you never heard that ten years you never heard that five years ago. But it's honestly like an existential threat to everyone, shifting away from mechanical engineering because, candidly, a lot of its ten, twenty years old versus software, like every five minutes something new is happening and the way you live your daily life, you're living in the software right. Just think about how we're talking, run a video call together from Toronto to St John's. We're talking over text message, Ron Video Call, we're on slack wherever we are, and then you go into your actual job and it's a tool from like one thousand nine hundred and eighty that hasn't failure, has changed it all your by yourself. That doesn't feel very good and I think the next generation of people are seeing that. Honestly, people that are in the workforce ten fifteen years or starting now say, well, I'm used to teams and I'm used to the rest, and that connected nature and I think covid also made us all a lot more human to anything with emotional side. I became okay to talk about how you're feeling and we've seen it to like the word fun. I don't think I would ever try to describe it a tool and engineering space is fun before, but like I can see it being fun, going in on shape or even like when we've had users using colab and going through and like just build to see each other talk in real time and context of something engineerine related is so foreign to the world. Yeah, you don't want to be working in a void, right, you want to be getting feedback, you want to be learning from your colleagues, like I think it just it just makes sense and we should be helping our designers be getting there more easily. Yeah, and the interested part of two is I think the negative emotions actually good. Like if you think about whenever you use Google docs the first time, I remember like these crazy highs of it okay, great, I have to send this file around, and these crazy lows of like wow, this is so slow because there's eight of US editing this document. Once those like they mellow out a little bit it, but I think it's stay...

...skewed high long term, and you see the same with these tools. I bet you that's studied, perpetuated on for, you know, three or four months, where you get used to tendencies and people get comfortable. I bet you nullifies some of the negative consequences be really cool studied actually run long term to see it would be. Yeah, what actually comes out of that? Yeah, true, and and Adam, I will say that you have good psychology instincts, because psychologist would say that it's not. It's not like we need to minimize negative emotions and maximize positive emotions, like if we think about what the designer needs in there and their outputs, like positive emotions tend to associate with with creative thinking and sort of like a peacefulness and a clarity of thought. But negative emotions, studies have shown, can make you really dig into a problem and try to solve a problem in more detail and so like, as you said, those frustrations can also spur on a certain behavior that can be useful for design. Yeah, and I mean I'm definitely not a psychology expert, but I'm I'm willing to probably bet my entire annual salary here that if you looked at where that negative emotion actually is in traditional cad it's just not in the tool. It's in a meeting three weeks later when the work you did was completely waste of time or someone else did it or a thing cry like it happens, but it just didn't happen there because you were at peace, like you said, right, you're at peace for that moment. I think it's actually good to break things quicker. It's the whole velocity of Agile, but for engineering, and it's like I think that's a good thing. It's smaller bumps of like, you know, little drops, versus getting the end of the project. I mean like wow, that was a complete waste of time and we're going to rewrite this entire cab model. And you're like that emotion is the type of emotion people leave teams and companies over. So you had a second paper there in the mix of all that. It was titled are to our two heads better than one for computer design? What sort of the takeaway is it to is it for? Is it one? Like what's the actual optimal team sats? We're working like one integrated part or assembly? Okay, well, great question and we don't have the answer yet because, like, partly, practically speaking, it's hard for us to recruit these mega teams, but we'd would, we would love to. So we really only compared our two heads better than one and what we found there is that two heads are not absolutely better than one head and one head is not absolutely better than two heads. So let's say that you are just looking at speed of CAD. One person working by themselves can finish a cat model quicker than two people working together, if we kind of normalized by by people, right. So the funny thing is like often we're actually in reality trying to hit a deadline. We wouldn't be allowing just one person to work quickly by themselves. We actually need more people to work on the CAD model. So it's not really a fair comparison in that way. But if we say like amount of cat completed per person, one person is faster than two people.

That's because when you have two people doing any task right off the bat they have to communicate a little bit and coordinate a little bit and that takes some time. On the flip side, I think those that that investment is worth it, because what our study did find was that two people end up generating higher quality cat, so with fewer errors, and that's like, I think, really important and kind of to your point earlier. We're gaining time in the end if we're generating cat that is higher quality. So yeah, that's the tradeoff that we found time and quality. Is Interesting because, like, when you think about it, the time nugget you're talking about. There is like this little finite pocket of time versus like time to market, which is right quality of stakes the whole way along the way. Each one of those is, you know, exasperates like whatever difference in time you would have spent avoiding it. Like there's like a ten x multiplier on that and it's it's tricky to like understand that acause is apple to oranges until it's time to market or on the other side, you know actually a change happening once it's in market. Then you're talking about dollar signs and it's the same kind of thing. I'm curious from like each of these studies you're done in the last couple of years, where do you see the biggest opportunity for improvement? You know, in the short term, I think over the next five or ten years you're going to see a lot of things all become cloud and connected and hold of an ecosystem. Where do you see improvement in the short term for any teams? So I will say that something that we that we'd notice in all of the experiments where we're pairing people together is that it's a very different experience. What I'm realizing is that often we learned to cad and and it's such a singular experience that we do it our way and we don't really get insight into how other people do it. And what I've realized is that benefit of designing collaboratively is getting to see how other people approach a problem and get like learning tips and tricks from others. And so if we kind of try to extrapolate from that, I think tip would be to try to get your engineers talking about process a little bit more and learning from each other when it comes to process. We taken a lot of inspiration in our work from software and like pair programming, for example, and there you get to like sure, again, studies have shown that pair programmers are a little bit slower, but it's a really satisfying and engaging experience for the designers. Again, the code is has fewer errors and it learned. It leads to to real learning, and so I think it's one of those things where, sure, it sacrifices a little bit of productivity, but in the end I think letting your engineers take some time to pair up and sort of apprentice from each other can help them hone their craft and learn from each other and and get better. I think it's actually valuable thingly, we see it all the time with our software, to games, like how much you're sharing that knowledge. And I...

...think back to when I was doing you know cat. I was the in solid works most of the time. I would always end up with like the model I needed. I definitely did it in like the worst way possible, just what every single time, and it was always because I was in a time crunch and never really thinking future facing and and a part of that was who I did. Most of this is internships and short term things or startups or whatever, but that's no way to go build something complex because it just comes back to rewriting it, redoing it, doing the same thing over and over again. I think that's we see our software team today. We're always think of how do you abstract this away? How do you make some it's reusable and extensible? You're always having that conversation. I think it happens in engineering now to I'm like more mature companies definitely have it, but there's parts that you can do. I'm like the microscale to educate each other better. I think that you know has a long, long lasting impacts and the kind of stay ways nicely and what I want to chat at next, and it's like you think of a clapative engineering design. We've been we've been using the term codesign and it's something that you can see in the design world in general. What does that mean to you, like when you hear code design, what does that mean to you? I'll be a little professorial and answering this in that there's act like cod design has a definition in the mechanical engineering design world, which is sort of like participatory design, and so it's actually used a lot in the context of like designing a service, in making sure that you are in involving your users in the design process. What it means to me is, I think, fundamentally, a little more broad, which is just a reminder to us as designers that it's not all on us to design the artifact. And so, how can I say that a little better? It's just, yeah, reminding us that we have access to users, we have access to stakeholders and we need to take advantage of that sooner in the process rather than than later. And so I see it almost as collaborative design. Coddesign and the boundaries could be internal to the company, external to the company, or I think we could also improve codesigned when it comes to, you know, vertically within our value chain, or even two different functions within our organization. Like how can we do our design in a way that helps us get those perspectives sooner? Why do we wait so long to get feedback and then have to integrate it in a way that is like costly and inefficient? What do you think, like just I mean why you just described to get multiple functions? You've got the vertical stack. They just different parts of life cycle and people involved. Yes, supply chain. Where do you think people should start? Like, if you're really thinking about this, I hear all sorts of opinions on this. What's your perspective on like a good starting place to try and become, let's say, a little less siload, a little less barrier and a little more engagement early and often? Like where do you think start? As the highest impact, maybe least risk? Oh Man,...

...that's a great question. I think you just have to be opportunistic, like, I think something that I'm realizing in the work that I do. So we run these experiments to collect data, but we're also looking for organizations to share their perspectives with us. So we'll do like formal research interviews, for example, and you kind of come across people who get excited about the idea of codesign and you come across people who who aren't, and I have trouble kind of connecting with those people. I just don't get it. I feel like this is an inevitable shift and some people just don't. And so I'm kind of copying out of your your question by saying in the short term, I think the short term win is whatever ally you can make, whether it's like someone on the marketing team who would be excited to give input sooner in a design review, or someone from if you're on design, someone from your manufacturing team who has like raised issues with you and said, like you guys need to figure this out sooner. It's like invite them into your into your design process sooner. Yeah, so I think it's all Owen. I think that actually makes sense, though, because it's not not every company's going to be the same amount. I think finding the people who are willing and excited is actually like the critical part of that right now, because the truth is like, if you look at research and data and the rest that it's hard to deny a lot of these things. But it's emotional, right. It's an emotional choice to make a change. People are stuck doing the way they've done it. They don't have time, there's you know, there's risk. They're real risk and making that change. But if you really go back to like what companies at a macro scale trying to do now, which is soon going to be a much different market place to work in the economy, is going to be tricky. retension and traction employson we hard. So everything's get more competitive. You going to deliver faster products to market, better products to market? You know it's just going to keep it harder and harder. And they make that jump. Something has to change at the working level because they're only doing like three and four percent improvements right now and we need like a fifty to a hundred percent improvement sort of year on year, and I think it's on the Niblis that happen. My question to you is, you know, if you're thinking about those people who get it, who are excited by it and want to do it now and not in five years from now, why do you think they're motivated now? Like you mentioned earlier on that the tooling wasn't there really four or five years ago even. But what else do you think's kind of driving the push for people to really be questioning are we working together the right way at this particular point in time in two thousand and twenty two? I think it might be. I certainly covid. You know, I think there's also a push in the broader culture to being more reflective. I think in general we kind of have touched on this already, but it feels weird that in our lives so much of what we do is... collaborative and connected and then you would come to work and all of a sudden your your sideload like it. I think people are starting to realize, like why, in my enterprise, where we have so many resources, are we are we not taking advantage of the technology that's like fueling so much of the other tools in our lives that help us feel connected? And if I could kind of elaborate on that. So one of my students, Cathy, and actually, by the way, I should give shout out so that our two heads better than one. Paper is from former PhD student for shunk badness who did some really great work there. But my student, Cathy, who's a current Master's student, interviewed twenty designers who are working on working with cad and she asked them about collaborating with cad and I think something that that surprised us was that every single person, each of those twenty people, had a complaint and a barrier about the current norm of collaborating with cad. And Cathy said something that I thought was really insightful, which is like, these designers are working on solving problems every day, being so thoughtful about the design that they're doing, and yet they have they're all creatures of habit and have just accepted the habit of workarounds to make collaboration happen. So the contrast was really interesting. Like working on world changing technology, super thoughtful on their design, and then when it comes to reflecting on their own workflow and their own process, they just hadn't really pushed for change. And it makes sense to me that we are creatures of habit like that. But I think I'm trying to connect folks to see that they can be more, that there are ways to rethink their process and new ways. So sure it's a little bit risky, but that I think can help them design better. Yeah, and it's interesting. David allman talks a lot about decisionmaking and sort of like your product is like a summation of all those decisions you made sort of throughout that build and I always come back to as. I agree like it's hard to make that shift from something you're conflict with, and I mean I did it, you know, seventy years ago and I was modeling. I got used to it too, because I didn't see a light at the end of the tunnel. I think a big part of watch changing now is there is that light at the end of the tunnel and people realize that it's okay to be yourself at work, and part of that means you expect things more than what you've been given over the last ten years or last forty years. Really, because I know, and I worked previously in engineering roles, I didn't think much of the tooling. I thought it was totally you know, this is what it's like to work like. I actually just spoke someone who is still using Lotus notes. I'm like, I would leave a company in a heartbeat, like the second I walk them. I found ot they're using lotus notes, I'd be straight out the door because that is so far behind where team should be. But I think the same's going to happen in the engineering worlds. Teams are going to get to a point where it's like, you know, maybe...

...solid works gets to the cloud and truly gets to the cloud, and x does too, and Creo. Maybe they do, maybe they don't, maybe there's other tools are bridge the gap. This whole ecosystem is going to evolve and those who are cool with it and get used to it are going to have a huge advantage because it's going to help. It's not going to really hinder anybody. It's going to connect this a whole other like force, force multiplier really behind it and I'm excited to see that happen. One of the things I'm curious about on the codesign front, thinking about the cat piece in particular, this codesign is bigger than just cat. I think it's engineering as a whole. Like it's a lot to it. On the cad front, what do you see the outcome likely being? Well, I think right now is very siload between the companies that provide cat tools. Yet every company builds something has a mix of solid works and N X and Creo and everything in their supply chain. Do you see them ever, like really becoming buddies and connecting it all together? Do you think there's going to be middleware layers? Like where do you see this ending up on the tooling front of the codesign question? I wish I could predict the future like that. Right now I feel like there's going to be middleware. I feel like there are just so many reasons that a company gets really committed to a tool and so it. In the long term there might be changed, but in the even the medium term, I don't think there's going to be. But I think, building on what you're actually just saying, the shift generally towards being more collaborative. I also think new graduates joining the workforce and sort of demanding it is going to mean that there's either going to have to be like new features from the from the big players, or there's going to be niche spots to fill for other software programs that help us be more collaborative. I will say to like I here at the university, I see young people learning cad and, for example, if we talk about on shape again, the students are so used to Google docs that they see on shape and it's just like a direct translation for them and there's almost like no discomfort. They're just totally natural in it, which is really interesting to see. It's a SASS thing. Really do any softwares of service. They've all been I've see so much literature about. Think about all the companies that exists is give you ways. It's been up databases and automate notifications, like they literally built companies to make SASS products almost identical, and partially for good reason. Right. It means the experience is going to be kind of synchronous across whatever application you used to you know, there's always a button up here where you can go chat with someone. There's always no vocation where you can go live get the something. You expect everything to be tracked automatically like your your expectations change and I think it's a really important shift because if you don't have to think about what tool you're using, in my opinion that's winning. But I think that's actually winning for engineers and their teams is go do your thing, forget about the tools. But the tools should be there to support you and not be, you know, your enemy or your champion, like they're really just there to be on that playing field. And Will they I'm really curious about like just thinking about, you know, engineers working together. You talked a little bit about finding champions that... can kind of get and make this work. Find an ally, who you know you start with in the claproof front. One thing. We're hearing lots about. His team moving away from drawings paper. All the rest really want to embrace d. But even going beyond that, like the big players, a fortune hundreds of looking at like truly model based definition, but they're seeing a lot of pushback from supply chain in particular, and how to get there. Do you see mbd becoming mainstream and, if so, like every talk in a year, five years, ten years, never like. What's your perspective on how it goes from you know, engineers working silos, engineers working together and engineer's working together without a whole bunch of other information straight all over the place? I guess as we chip away at the problem and we kind of streamlined some of the other issues of collaboration and get used to them, like I think something that is fundamentally a problem is the authoritative source of information and in the folks in my community who study design research talk about that often, like building a shared understanding is really important. And so what is the single source of truths? Is What we talked about for a while. I see MBD as a way to get there. I think I would love for you to get like an organizational change person on the podcast, because I'm a mechanical engineer and I don't exactly have the understanding of all of the inertia that happens to block folks from shifting there. But I to me, if we started from scratch and had no existing you know, commitments to anything like, I think and bed would be the way to go. And so I hope it happens in or I imagine I will see it happen in like ten years. I think it'll be more prevalent. In five years maybe we'll see a big shift, which could happen if like something like the US government says, like, Oh, there must be mbd or something. That's what's really cause a lot of the big shifts and in tooling and in standards and stuff. But until that happens, I think we'll just slowly see a trickle of folks and and maybe sort of like like a split industry? I'm not sure. Yeah, I think. I think it's. Until it becomes a requirement, either contractually from like the owner of a supply chain or a regulatory body or some big government like, it's going to be slow, I think, until it's not slow, and then it's gonna be really fast and people aren't getting ready and it's going to be a whole other source of pain. I'm curious, like in like wrapping all this up and thinking about collaboration, the work the team's doing. You know, where's this going? People working together. What are you most excited to study in two thousand and twenty two, like, what's the thing you're trying to figure out here that you think is going to, you know, be super exciting for us come back or and talk about and all thest time? Two answers. One thing that I'm really excited about is this question of beyond two heads. You know, how many, how many heads can we have working on a cad model and what happens...

...when we have many people working like I think there's been such interesting large crowdsource software projects. There hasn't really been the same thing when it comes to hardware. I would love to see it. The power of the crowd has been shown to be really creative sometimes and really effective at problem solving, and so better understanding that in a cad context would be really interesting. The other thing that we're pretty interested in studying in my lab is creativity in and CAD. So there's some, I'll say, older, studies that describe how cad may not be the most effective tool for doing conceptual design because it hinders creativity, and that's something that you kind of mentioned earlier. Adam is like the tool should be an extension of the designer. It shouldn't be a blocker of the designer, and so folks thought that sketching is certainly an extension of the designer, but in like the early when folks are writing these papers and doing the comparisons, the cad was not an extension of the designer. I think it's time to revisit that, but also to have this other perspective in it, which is what about if we don't look singularly at one designer doing the the CAD modeling? What if we allow some collaboration, whether it's like multi tenant or even just in some other way, allowing to designers or more to work together, can we see the same types of creativity happening that we see in sketching? Awesome, Alison. Thanks so much for joining. I really appreciate the insights and I'm really looking forward to see him. How many heads are on this monster? At the end of the day, you're working together, and what the ideal ways for teams to behave? So thanks so much. Awesome. Thanks, Adam. Colab is on 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 colab 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 Colab softwarecom. 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)