S5E22 James Trevelyan | What Research Tells Us Is The Most Important Quality of Engineers

Welcome to another episode of the Being An Engineer podcast. Today, we're excited to host James Trevelyan. James shares insights from his extensive research and experience on effective collaboration, cultural differences in engineering practice, value creation, and accelerating engineering development through experimentation. 

Main Topics:

• Engineering collaboration skills
• Communication vs email
• Cultural impacts on innovation
• Project failures due to collaboration issues
• Improving listening skills
• Training priorities
• Creating value for clients.

About the guest: James Trevelyan, is a renowned engineer whose career spans significant contributions to both academia and industry. James's work has profoundly impacted practical engineering applications and education, notably in areas of robotics and automation. His extensive research and development projects have pioneered technological advancements and provided critical insights into engineering practice. With a focus on enhancing the utility of engineering work and its recognition in society, James offers invaluable perspectives on navigating and succeeding in the engineering world.

Links:
James Trevelyan LinkedIn
Website
Book

About Being An Engineer

The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us

Transcript

James Trevelyan: 0:00

You know, I was incredibly shy when I started out being an engineer. I really was a nerd, and I had a pulling people skills, but I was put in situations where I had to do something about that

Aaron Moncur: 0:25

Welcome to another episode of The being an engineer Podcast. Today we are excited to host Professor James Trevelyan a renowned engineer whose career spans significant contributions to both academia and industry. James's work has profoundly impacted practical engineering applications and education, notably in areas of robotics and automation. His extensive research and development projects have not only pioneered technological advancements, but have also provided critical insights into engineering practice. With a focus on enhancing the utility of engineering work and its recognition in society, James offers invaluable perspectives on navigating and succeeding in the world of engineering. James, thank you so much for being with us on the show today.

James Trevelyan: 1:14

Pleasure, Aaron, lovely to meet you.

Aaron Moncur: 1:16

Well, James, can you tell me a little bit about how you decided to become an engineer?

James Trevelyan: 1:21

I never really thought of anything else here. And, you know, from as early as I can remember, I was playing with model trains, taking things apart, you know, I definitely have always been inclined towards mechanical engineering. But, you know, several times in my life, I have been rudely dragged into other areas of engineering out of necessity as well. So yeah, it was it was really wasn't a decision. It was it was something that I just, I guess channeled myself into right from the very start. Yeah.

Aaron Moncur: 1:59

In your in your genes and your genetics, which is part of who you are.

James Trevelyan: 2:02

Somewhere there. Somewhere there. Yeah. Not it's not common in my family, my, my family of anything, tend to be progressive politicians. somewhat naive to the realities of politics, and also quite quite a few religious religious personalities and rise fisting. Okay, so I did, I did follow, I did follow some of my relatives in writing some books.

Aaron Moncur: 2:28

That's right, and we'll talk about one of them, in particular, the making of an expert engineer. Before we get into that, can you share a little bit about you've had an extensive career in academia, but you've also been involved in industry, what, what do you think is one of the keys to effective collaboration between academic research and industry implementation?

James Trevelyan: 2:53

I think that, you know, my career has essentially been one where I've had a foot in both camps pretty much all the time. So that's made it possible for me to shift between one and the other, reasonably easily. One of the things I've discovered from my research is that academia tends to be an an anti collaborative environment. You know, when you're a student, collaboration is generally regarded as cheating. And academics are the most successful tend to be the most successful of the students in adapting to that culture. So it's actually really difficult to get color effective collaboration in most academic environments. And my research suggests that starts with the assessment process. Because when you think about it in in the university, the way that you get grades, which is essentially how you you how your your contributions are valued, is that you sit down in an examination hall or, or somewhere, maybe in a quiet spot with a laptop, to write your assignment. And when I was teaching, and I tried to introduce students to the realities of engineering, which I was not only exposed to professionally through my life, but also course exposed through my research, which drew my attention to lots of things I'd taken for granted and never taken much notice of when I was actually practicing an engineer. I would put the students through an exercise where they not only had to collaborate with others in a small group, they also had to collaborate between the groups. And you know, some of the students came to me bitterly resentful, saying things like Why the f should migrate suffer just because those guys are too lazy. And my response would be Well, welcome to the real world of engineering as well

Aaron Moncur: 4:55

as like, General,

James Trevelyan: 4:56

but it but one, one of the things What struck me was the emotional the emotional resentment to this idea of collaborating. And it took me some time to figure out really what was going on until I realized that that there is the something we call an education, the hidden curriculum. It is the messages that we send to students non verbally, we never actually explain it. And so one of the things that we do a very powerful message for students is that you get grades by sitting down on your own and working on your own, and you don't pay attention to what other people are doing. And at this message, unfortunately, goes with them into into their working lives, and causes great difficulty for many. You know, I was just lucky, I was put into situations where I had to adapt into a more collaborative culture. But it's it's much easier for some people

Aaron Moncur: 5:54

Have you found that this is more true in the than others. past 15 20 years with the rise of social media versus before we were so connected yet paradoxically alone.

James Trevelyan: 6:10

You know, there is a discussion amongst economists called the productivity puzzle. And essentially, economists are trying to explain to each other why global productivity has taken a hit since around 2005. If you if you look at global productivity, and particularly in in wealthy countries, productivity increased by about 2%, two to 3%, a year, through the second half of the 20th century. And and even early, although we don't really have much data before the 1950s. And, you know, it might, it might be worth remembering what productivity is, it's it's pretty much a very pretty simple concept. It's the the ratio of the goods produced, compared with the labor and other inputs required to produce those goods, on a grand scale across the whole economy or across an enterprise in industry or whatever. And thinking about what happened in 2005, that that changed everything so much. To my mind, it was the introduction of the smartphone. In fact, cars, smartphones and other devices have been around beforehand. But when I was working as an engineer, in the last century, it sounds like a long time ago, doesn't it? When you want it to get the attention of other people, you wanted to find out, get some information or whatever, you had the choice, you could send them a letter, you could write a report and send it off, you had to get it typed, and so on and so forth. And, you know, getting an answer would take weeks, if you were lucky. So normally what you had to do is actually go and see people or at least call them on the telephone. So it was actually necessity to talk to people. Now, of course, text communication is fast, free and easy. And interestingly, in the 1950s, psychologists discovered that if you only communicate with text, you undermine trust, and undermine collaborating. But that's a lesson we seem to have forgotten. There's some really interesting books written by people like Sherry Turkle who worked at MIT, and thoroughly recommend those books if you know if you have the chance to look at them. And she has looked at the way that social media and electronic communication has changed the way people interact. You know, and it does give people more of an option to withdraw. So as engineers, since, you know, we have to still have to produce results, even though people work differently, it's really helpful to understand what's been happening, and realize that we do have to adapt and change the way we operate to take this into account. So yes, there's been a huge shift. And I think we're still grappling with the consequences of that shift. And particularly when it comes to things like organizational culture,

Aaron Moncur: 9:15

I think you're right. I have certainly noticed even with them in my own small organization that and I would say this is particularly true of the younger engineers, but maybe true to some extent with all of the individuals that there is a almost an unconscious preference towards emailing people. And it drives me crazy, especially when I see an urgent need for something right, we need to get an answer quickly. A project deadline depends on it or something like that. And I'll ask the engineer, were you able to get in touch with whoever it is the vendor, the customer, right to get this answer? Oh, yeah, I sent an email. I'm waiting for them. respond. Now just I want to pull my hair out, don't send an email, when you need a quick answer, call them or if they're in the vicinity, go visit them, you know, I'm actually putting together a presentation for engineers about communication. And one of the very first slides is a scale of urgency and the different methods of communication that one should and could use, depending on how urgent that communication is. And of course, email is down at the low end of urgency. And then as you increase in urgency, maybe text or direct message, and then at the high end of urgency is in person visits or a phone call. But I think for whatever reason, probably social media has something to do with it. As a society, we have become less inclined to just talk to people in person or even over the phone. But yeah,

James Trevelyan: 10:55

I think that that's a very valid observation. And you'll find many people have have remarked on that, you know, I had an interesting experience. Early on in my I think it was my academic career, I was asked to consult with a large number of people on a particular issue. And I dreaded this because I thought, I really don't want to spend hours and hours and hours collating all the different points of view. So I sent a large number of emails, but I put the important information on which people had to comment, I put it in an attachment to the emails. And out of about 400 emails I sent, I only got five replies. So that saved an awful lot of time and effort. So but you know, I was deliberately exploiting this reluctance to engage with email, in order to do use the amount of work I had to write loophole,

Aaron Moncur: 11:48

I love it.

James Trevelyan: 11:52

Nobody, nobody could complain that they weren't consulted.

Aaron Moncur: 11:55

That's right. They had the opportunity. They blow

James Trevelyan: 11:57

That's right. Yes. Well, so yeah, it's, it's it. something that you can exploit. But it's, it's, I think, definitely, you're on the right track, it is hard to encourage people to get on the phone and call, you know, there's, there's a reluctance, and, and so on, but it's once you get over that shyness, you know, I was incredibly shy when I started out being an engineer, I really was a nerd. And I had appalling people skills. But I was put in situations where I had to do something about that. And I got some good training courses, and so on, and so forth. And, and so it's important, I think, for young engineers to understand, we all develop differently, we all develop at different rates. And you know, as engineers, we tend to be early developers when it comes to MCAD, to mechanical or mathematical skills, understanding science, and so on and so forth. And, and maybe our interpersonal skills, lag behind other people. Not everybody, but definitely I was one of those. But it's something that develops over time. And there's no need to classify yourself as being a nerd or a terrible communicator for the rest of your life. It's these are skills that are easy to learn.

Aaron Moncur: 13:17

Terrific point, we all change and grow over time, who we are today is not necessarily who we're going to be tomorrow. Thankfully, yeah, thankfully, asked my wife. Right. Well, you are joining this conversation with me from Australia right now. And I've never been to Australia, but I have the sense that it's there are a lot of commonalities culturally, between the United States and Australia. But you also have experience working in some countries where culturally and probably in other ways, socio economics, etc. Things are very different, for example, Pakistan, how has your experience working in countries like Pakistan shaped your approach to engineering and innovation?

James Trevelyan: 14:08

Very good question. Aaron. First of all, I would, I would caution you and say that Australian culture is very different to American culture. Just Just Just know that be prepared. Okay. But, you know, but definitely, I think you will be right in saying perhaps is more in common between Australia and in America than there is between, say, Australia and Pakistan. Well, I, I'm not quite so sure about that. But definitely, you know, it's it. First of all, it's refreshing, because when you operate in a different culture, you suddenly become aware, much more aware of your own culture, and how that's different. So, of course, I had the advantage of of marrying a wonderful woman who was born in Pakistan, her family there. And the first thing that you get exposed to there Is, is the amazing hospitality of people in a hospitality is part of the culture. And the difficult part is how to decline hospitality when you either haven't got the time or you need to be somewhere else. But at the same time as an engineer, I was struck by two or three things. The first was the amount of rubbish around the place dirt rubbish, the place looks rundown, and I'm sure many of your listeners who have been to less developed countries would would echo that perception. And I'm thinking, you know, surely labor is so cheap here, why don't you know, it was so inexpensive to hire people to tidy to clear it up, clear up the mess. The second was, and this only emerged over time, how expensive it was to do business there. You know, I was I was involved in a project to develop improved devices to help people clearing landmines in Afghanistan. And, you know, I naturally thought that, it would be a great idea to do this work in Pakistan, for two reasons. One is we could save a lot of money because labor is pretty cheap there. And secondly, we had direct access to the to the the fellows who were actually removing mines in Afghanistan, because at the time they were based in Pakistan, they'd commute, because the the situation in Afghanistan wasn't particularly conducive for for living conditions, there was a war going on there. And I found, to my surprise, that it was actually a lot cheaper to do the do the engineering work in, in Australia, when you compare the quality of the results, so I struggled to understand why smart engineers, who had had been educated to some of the world's best universities, struggled to produce results in Pakistan, that one could take for granted in a country like Australia, or even the US. And yet, you know, Pakistani engineers, Indian engineers, because this, this is a problem that I soon found is is common to lots of lots of countries, engineers from these countries come to countries like Australia and America, and they do really well. So what's going on here, and, you know, eventually I realized it was something to do with the local culture and the environment. And after 20 years of research, and some of your listeners might wonder why it took so long to figure it out. But it's a really challenging issue. After 20 years, the best way I can summarize this, is, is to explain that engineering, essentially, has two broad activities. One is the application of technical knowledge. And some of its scientific, some of it mathematical, some of it just practically acquired experience. And this knowledge generally works the same everywhere. You know, you need pumps to send water uphill in Pakistan, just as much as Australia. And the same pumps will do the same job. But the other side of engineering, is how do you get the results translated to action, because in engineering, you know, we engineers seldom touch even often, we're not allowed to touch the things that we are responsible for. So we have a huge collaborative undertaking, involving lots of people, ranging from the people who provide the finance to the people who get their hands dirty. And certainly, that the understanding of what's needed, has to permeate the whole organization. And that's the challenging part. Because in the cultures that you will find in countries like Pakistan, collaboration is far more difficult information doesn't get freely exchanged in the way that you might think it does in a country like the USA, Australia, Europe, Britain, France, and so on. And once you realize that you've got these barriers, you can understand why it's so challenging for the engineers to do things. Now. Of course, early you were talking about my book, The Making of an expert engineer. And almost by accident, I stumbled across engineers who had somehow magically overcome these issues. They were able to produce results, which equal equal to the best in the world, in that environment. And yet, they couldn't explain how they'd managed to do that. Some of them had been exposed to engineering in developed countries in Britain, America, so on, but many had not. And so it was a real puzzle to me to try and understand how it was that the engineers managed to produce these results, you know, it was very easy to identify them once you knew what to look for, because they were paid extraordinarily high salaries. So typical engineering in India or Pakistan will earn around about a quarter of what an engineer would earn in the US or Australia. In rough terms, these engineers were actually earning more than their counterparts in countries like Australia. And that was because their companies realized that these individuals were so critical to their operations, they wanted to make sure that they would never think of leaving. And so you know, this, here's the answer to my puzzle. If only I could understand what it was that they were doing differently. And that's essentially why I wrote the book, he was to understand what they do differently. And it turns out, that it's not rocket science, anybody can learn. And so my hope is that one day engineers in every country in the world will understand that collaboration is something that you have to work through a local culture. And that understanding how that culture works is the key to getting great results in engineering. And the shame of it is that we don't even teach collaboration in engineering schools. It's all technical stuff. And it's assumed that just because students work in groups together, they will somehow learn to collaborate, when, when you actually look at what students do, as a researcher, you actually find that in spite of the fact that they work in groups, they're still engaging in anti collaborative behavior. And it's a real struggle for many companies to turn young engineers around, and to get them to collaborate. You know, as engineers, we're often accused of having lousy communication skills, companies complain that fresh graduates have, you know, poorly developed communication skills, I think what they really mean is that they have poor collaboration skills. And, you know, collaboration is much more complicated than just communication. So here's a whole area, which is a big struggle, I think, for engineering schools. Because introducing this idea of collaboration does require a culture change in education, and culture change in companies is hard enough, getting culture change in education is far more difficult.

Aaron Moncur: 22:27

I wonder if the reason that we don't have better communication or collaboration skills as young engineers, is because for right or wrong, and I think it's for Ron, there's no money in it. Right, as a as an industry. And I think this is changing, but historically, as an engineering industry, we haven't recognized the value of communication, at least to the extent that there's actually money in communication, collaboration, education. Okay.

James Trevelyan: 23:02

Aaron, let me let me talk about another aspect of of my research here, that definitely is money at it. And let me explain why. So in doing, essentially, where did I start? So so this, this problem that I was confronted with? Why was it so difficult for engineers to collaborate in a country like Pakistan or India? Essentially, that was my starting point. And so I naively thought that if I observed what engineers were really doing there, I will be able to take that knowledge back to Australia and look up from texts, what engineers did anywhere in the world, and find, and immediately the differences will be obvious. Well, when I got back to Australia, we started looking for research, or what engineers really do. And at the time, the early 2000s, it was really, really hard to find any detailed observation. So what engineers really do in their work. Lots of people had studied engineers. But they were more interested in engineers working in teams, or how did engineers do management and so on, so forth, that very few people had actually asked this question, what's the engineering bit and how does that work? So I soon realized that we had to answer that question. Before we could actually start looking at the differences. So that was the first challenge to answer this question. What do engineers really do in detail? How do they do it? And then we started to notice some interesting patterns. For example, one of my students decided to do a project. To understand design check, design, checking And that started because I asked him what he was doing in his summer vacation before his, the last year of his course. And he said, Oh, I'm checking, doing design checks. And I said, but you're working in a company, you are the least experienced the least knowledgeable person in that company, as a student, how come you are doing design checks when that should be the job of the senior engineers. And he said, Oh, the senior engineers don't have time to do it. So they asked me to do it instead. So I thought, this is really interesting. And what came out of that was the discovery that and and we think it's almost universal, that engineers have an aversion towards activities like checking and review. And it stems from this idea that the valuable stuff in engineering is designed calculations, that sort of stuff. Making progress. And doing design checks, takes time. delays, the project generally gets in the way of what many engineers see is real progress. So there was a reluctance to engage with it. And the more we looked at this, the more we realized that we had to answer a question, well, what do engineers do? And why do they do what they do? And why do they avoid some of the aspects of what would be classified as engineering work? What was it that made made engineers so reluctant to engage in in checking. And that brought us to the idea of value. So in everything that we do, our instinctive ideas of what creates value, drive are instinctive decisions, think for a moment you arrive at the office in the morning, you get your computer started, and you see 50 or 100 emails there. What makes you decide which one to open first? You know, there's an instinctive decision making process there. And psychologists talk about notions of value. Because in essence, we are driven by what we think is going to create value for us, and sometimes for others. So this idea of value, these instinctive ideas of value become really important. And then what we went on to discover was that there was no understanding in the research literature on how engineers produce commercial or economic value. You know, economists basically have worked on the assumption or not really assumption, they've, they've deduced that innovation is really important in creating value. This came out of the work of economists in the 1930s, who were confronted with, at that time, a monumental issue. And the monumental issue was, would capitalism or communism succeed? You know, this was the time when communism had taken a grip on a large proportion of the world, had certainly captivated large numbers of people, even in Europe and America. Who were, you know, had this idea that somehow working people should have much more of a say in what was actually going to happen. So this idea was pitted against capitalism, where essentially the the idea was that it was finance and money and economics, which would drive success, rather than the rule of the working classes. And there was this huge debate amongst economists, of course, they didn't know what we know now. That at least in economic terms, you know, freedom and the ability to allow the market pressures to decide what's what's important. Produce economically a more satisfactory result. Now many, many people, of course, would question it saying, well, we've also got an environmental crisis on our hands. But if you go to countries where there still are traces of the original communism left, you will soon find that the environmental crisis is much more acute there than it is in in countries like Australia and America. But let's, let's all agree we have a major issue on our hands, which we obviously now trying to do something about that set aside. What came out of that was that innovation was really important. And consequently, now today, you will find lots in the engineering media about entrepreneurship, startup companies, and so on. That's where that's where the prestige is. Now, here's the catch. Only about 3% of all entrants, Is are engaged in what you would call real innovation. 97% of engineers roughly maybe give or take a few percentage points. The vast majority of engineers are not allowed to innovate. Why? Because the client says, If this hasn't been done before, find me a way that has been done before. Because I don't want to be the guinea pig. I don't want to be the enterprise that learns the painful lesson that this was not the right way to do it. I'm sure you've come across this before. But you know, one of the engineers I interviewed summed it up beautifully. He said, The only two times I really enjoyed myself in my career. Were when the client forgot to ask, Has this been done before? So as engineers, we have an instinctive desire to innovate. And most of our clients have an instinctive desire to stop us and say, No, do it this way. So if engineers are not innovating, how then they're creating value, this was the puzzle we had to confront. And here I was helped by some really smart economists, who reminded me that there's a very well, very well supported principle in economics, that says the value you create is directly related to your to your earnings in on an average, you know, there's always variation depending on circumstances. But generally, if people are being paid, they must be doing something valuable. And if you just think for a moment, if companies had somehow figured out that engineers don't contribute that much value, that they can make more profits by by firing their engineers, there'd be very few jobs left for us engineers today. And luckily, that's not the case at all. So we must be doing something that produces value. But the question is, what? And what comes out of that analysis is the collaboration is an important driver of economic success. What's the best measure for that? We only have to look at the performance of engineering projects. As engineers, we it's rather discomforting to learn that for major projects, and we're talking about projects over a billion US dollars. The success rate is appalling. absolutely appalling. In rough terms, two out of every six major engineering projects, manage to produce for the investors a financial return, which is at least 50% of what they were promised when the project was approved. All right. Now, that's a pretty low bar for success. What it means is that four out of six don't even meet that requirement. What's more, one in six projects, roughly, one in six projects, the investors lose everything, or practically everything. So there's, there's a major nickel refinery, that's about three or four hours drive away from here, which is a case in point. It was a cost about two and a half billion US dollars. The people who develop the refinery eventually managed to sell it for 250 million US dollars. It to a Canadian company that should have known better. The Canadian company thought they could fix all the issues. And about six years later mothballed the whole thing. So it stands there. Few hours drive away, a pile of steel, steel, tanks, pipelines, all the stuff that you'll be familiar with. And it's it's complete write off. In other words, the investors lost all their money. And unfortunately, the this is the rule rather than the exception. So when you look at why these projects fail, almost invariably the reason is collaboration failures. So what do we get from that? effective collaboration does produce huge financial returns? That's the important lesson. So if anybody says, Look, collaboration is not important financially, just remind them of that. Collaboration failures explained why so many engineering projects fail. And you know, many times they get dismissed as communication failures, management failures, and so on and so forth. But these projects are managed by engineers. We can't get away from that responsibility. So And interestingly enough, the data on which this is based collected by companies who actually specialize in looking at the success rates of engineering projects. That data shows that performance is actually getting worse. Not better. It's getting worse with time.

Aaron Moncur: 35:16

So I have some questions for you. First of all, this data is all very fascinating. And the questions that come to mind are one, can you define the difference between communication and collaboration? And then to what are some examples of what poor collaboration looks like? versus some examples of what very good collaboration looks like? And then three, what are the steps that one should take to become very proficient at collaborating in engineering teams?

James Trevelyan: 35:54

Really good questions, Aaron. So to answer your first question, what's the difference between communication and collaboration? Well, you can't have collaboration without communication. So the ability to exchange information that least, is fundamental for collaboration. So it's the it's the starting point, if you like. The second, sorry, the third question you ask is how can you get how can you improve in terms of your ability to collaborate? So my suggestion is to start with listening skills. engineers spend of the order of about 25% of their time listening, on the phone, in meetings, casual encounters. And in my experience, as an engineer, the most useful information that I have come across almost invariably has been communicated verbally. So being able to accurately remember that information has been crucial in my career. Why because people are reluctant to transmit written communicator or valuable communication in writing, because it may not be their job to do that. And, but they understand that you need to have that information, but they don't want to know, they don't want other people to find out that they're the ones that gave you that information. So that's why it's often transmitted verbally. And, you know, sometimes people are just much more willing to give you information in a casual conversation than they are in a in a formal encounter. So that's the first step is being able to listen and quickly write notes. Because people are reluctant to give you valuable information. If you've got a you know, if your phone is on record, so much the best if you can sit down, write a few notes. And so in my books, I explain how you can do that. It's really unfortunate that listening skills are not taught in universities, because we rely so much on verbal communication. In teaching, for example, you think about lectures or tutorials, you can get so much more as a student, if you can develop listening skills. In my university a few years back, we decided that it'd be really good idea to teach communication skills to all of our students, right across every discipline. So I found myself on a panel of academics and students to figure out how to do that. And at the first meeting, I was we were all asked, you know, how should we go about this? So all of my academic colleagues talked about standing up giving a presentation, engaging in debate, writing essays, the traditional forms of academic communication. And I was being with my surname starting with tea, I was the last to be asked to comment. So I came up, I said, Look, I think the really important thing is to teach students to listen. And I could see by the expressions on the faces of my colleagues that they were really startled by this, and puzzled and one of them said, Well, why do you need to teach students to listen because they sit in lectures all day. So I explained that I actually measured the the listening skills of my students. And I found that they listened for the first three or four minutes of a lecture and then forget pretty much everything else that was said. That aside, the next person to comment was a student. The students were asked to comment after the academics. And when the students started speaking, I thought, oh, no, no This idea that I've suggested about teaching communication or teaching listening skills, is going to die a death right here. And now, because the student introduced himself has said said, he said, I'm the president of the university engineers club, Student Association. And what Professor Trevelyan has said is absolutely true. I have found as a student that my listening skills have seriously degraded through the years of my undergraduate education. And it was only when I started working in a company that I realized how bad my listening skills were. And I thought to myself, if there's one way to kill an idea in an academic discussion, it is for the students to back you up. And I was never asked to another meeting.

Aaron Moncur: 40:50

That's kind of a sad story.

James Trevelyan: 40:53

You know, it's, look, it's important to understand, you know, I got this from a PhD thesis, a really wonderful PhD thesis, about collaboration in the design of the instrumentation system in the electronics for Volvo cars, if anyone's interested, write to me, and I'll tell you where to look for this. And the student who wrote it talked about the idea of infrastructures within academic environments, there are structures, there are ways of doing things that are so deeply embedded, that you can't change them, you can't even see them, because they're taken for granted. And so we have to understand this is why it's really difficult to change things in education. So rather than trying to change the structure, which potentially would make the whole thing crash and burn, much better to think about what you can do in higher education, and what you can't do, and how do you, how do you find an effective way for students to learn these things, outside of the structures that might prevent that. So that's my suggestion. And, you know, this is a place where I think that companies can do a great deal with young engineers, it's been really interesting to observe over the last 20 or 30 years, how many companies have abandoned their formal training programs for young engineers. And often because they say we don't know what to teach them. And that's understandable, because there really hasn't been, for much of that time, a good body of published research, showing what engineers really need to learn. Now that researchers there, it's time to rethink this idea. And I think that smart companies can do a lot with young engineers in a short time, by recognizing what they need to learn quickly, in order to become effective engineers, and definitely listening skills is the place I would start. And that's, of course, in my books.

Aaron Moncur: 43:11

So I think that earlier, I said, there's no money in communication. And let me rephrase what I meant by that. I have seen companies pay lots of money for technical training. Sometimes the technical trading isn't even very good. But a company here is Oh, technical training. My engineers, our technical people, they need to learn and develop these technical skills, therefore, I will pay this money to have them trained technically. But I have not come across any courses or any companies who seek out communication or listening courses, or collaboration, training, and pay money for their engineers to learn those things. So it seems to me like there's a lack of financial incentive for the folks that might be very good with listening or communication, to promote this type of training. Because companies, by the, by the way they spend their dollars are not supporting it. You have written a book about this, which arguably is a form of training. Maybe can you speak a little bit about what I just said about that? Whether you agree with it or disagree with it, if you've seen examples that that are counter to what I'm suggesting here, and then I'd love to hear from your book, if you're willing to share what are some of the tactical ways that engineers can improve their listening skills?

James Trevelyan: 44:59

Well, you Let me first of all, that's really interesting comment, Aaron, because certainly in Australia, companies do spend a lot of money on teaching professional skills to engineers, including effective collaboration techniques, although I would say that it's definitely could be improved. But here, there's an interesting obstacle that engineers themselves do not like these training courses. And young engineers much prefer technical training courses, because they say, well, that's what's gonna get me ahead in my career. Here, we see the influence of their education. And companies know that they have to do something about it. So definitely, companies do spend money on, for example, wouldn't necessarily be directly on collaboration, but for example, on training engineers to write good specifications on contract management, project management, and so on and so forth. So definitely that's, that's, that's a money making business. In Australia, companies do spend money in in this area, I'm quite surprised that you haven't seen that in the US. That, definitely, it's, that's, that's a very interesting observation.

Aaron Moncur: 46:13

I see lots of training for, you know, let's learn GD and t, or let's improve our CAD skills. Project management, I see lots of training for those things I haven't seen any training for this is how to talk to people in a way that makes them like you and want to be around you and work with you. This is how to well, this is one to use phone versus an email, you know, I just I don't see those courses, I see the technical courses out there.

James Trevelyan: 46:46

You will find them in Australia for sure. That notion, then

Aaron Moncur: 46:50

we just need to move to Australia and get trained there and then come back to the US. Yeah,

James Trevelyan: 46:54

I mean, it's definitely it's a much more much better recognized issue here in Australia, I think. So, you know, where where would you start, if you don't have access to good training courses? Well, here, I have to say my books, there's some very easy to learn methods there. And I would just remind your listeners, you know, that effective collaboration makes a huge difference to engineering results on the ground. Because essentially, in my discussions about value, I talk about three activities that are really important in creating engineering value. The first is what I call value creation, which is the act of creating something which is going to deliver value, eventually a design, the design invention, a new way to it can be something quite mundane like a new way to package a product so that it actually enhances the experience of the person buying the product. And that might not be in bits of you no more plastic, it could mean things like providing really good instruction materials and documentation to an engineering project so that when people receive it, they know how to use it correctly. The second activity is how do you actually deliver that value, which may and this is where collaboration is really important. Because in engineering most of the time, we've got this huge collaborative enterprise. And the value of what gets delivered to the customer depends on the effective, effective collaboration in countless people across some many cases across the world, not just within one country. And then thirdly, it really important is the protection of value. And value protection involves activities like sustainment maintenance, engineering, asset management, protecting the value of what our social licence to operate, which is basically building trust in the communities in which we operate, that what we're doing is the right thing, you know, reinvesting in, in quality of natural environment, because it's the natural environment that sustains all of us, engineering and everything else. So paying attention to protecting value that's already been created, either by us or by nature is is another really important aspect of of value. And so that's what I that's what I try and teach my people in, in my company, you know, cozy where we're producing these cute little air conditioners, which, of course, arose from my experiences in Pakistan. You said what did I learn from Pakistan? Well, one was the need for cooling and not only cooling, but very cost effective cooling, because there's vast numbers of people who are struggling with the released juggling with the heat. And conventional air conditioning does not really meet their requirements because they can't afford it. There's too energy intensive. So getting everybody to understand how you create value through effective collaboration, and how you deliver value is is is, I think the starting point. And that's in my most recent book learning engineering practice. And then there's a free publication on my blog, which talks about how you how you generate value as an engineer. So I'd say those are the starting points, because everything you do as an engineer, ultimately, is driven by the perceptions of the clients in how you create effective value.

Aaron Moncur: 50:44

Yes, I think that there is this notion amongst let's call it the purest engineer in all of us, where we just want to do the engineering work, and we want to do the engineering work really, really well. We want it to be perfect. When in an ideal world, that would be great. But in the real world, our engineering is driven by business objectives. And if we're not able to meet and support those objectives with our engineering, then we have failed as at least employees of that organization. I know that I've worked with engineers who do exceptionally good work there, the quality that they produce is extraordinarily high. But it takes a long, long time to do that work. And in many instances, we don't need perfect work, we need good enough work that gets done quickly. It almost sounds crass to say it that way. But the realities of running an engineering business dictate oftentimes good enough, but quick, rather than perfect, but it takes a long time. Any comments whether you're in agreement or disagreement with with those thoughts?

James Trevelyan: 52:07

Look, the you know, I am just, you know, there's a side of my character, which is just like the engineer you describe, you know, I love spending time to get things right. And so what I've learned in my career, is that, when you are getting things right, in a way that generates lots of value for the client, they will give you the time and the money to do it. Right, you will enjoy yourself much more. So the key thing is to understand where your work starts to create really significant value. And then no one will care how long you take. Because they know it's getting beat worthwhile in the end. So that's the lesson I learned. I was very lucky to learn very early on in my career, I worked on on a project to create robots for shearing sheep. In Australia, in Australia, we don't these days have quite as many sheep as we used to. But definitely getting the wool off sheep's backs is a really arduous task. And so I was confronted with this idea that, you know, maybe we could develop robots for shearing sheep. And my instinctive reaction was, don't be ridiculous, you know, who find me a farmer, that's going to pay half a million or a million dollars for a sheep for a robot to shear sheep, sheep or sheep. So the Professor of Engineering at the time, he was somewhat more enlightened than I was. When I was there, he took me to a couple of farms and look, and we looked at these huge harvesting machines that they use for harvesting wheat. And he said, That's a million dollars sitting in the shed. And it sits in the shed like that for all but three weeks of the whole year. And I suddenly thought to myself, Okay, maybe farmers could afford a sheep sharing robot. So that was if you like, that opened my eyes and knowing that this was an issue which farmers were really agitated about. And understanding that they were prepared to put a lot of money in to find solutions over a long period of time. I really enjoyed myself for the next 10 years, knowing that there was no shortage of money to solve his problem now the interest intriguing thing is that those chips sharing robots have they're still they're just still don't exist. They're still not rope. They're still not sharing sheep and sharing sheds. But the videotape Well, the video of our robot sharing a sheep on YouTube, easy to find just look for robot cheap sharing that has modified the behavior of Shearer's It was sheer as demanding If enormous pay rises of the order of 100 250%, in the 1970s, which motivated the farmers to do something. And that's what got the project started. Since that robot has been demonstrated, the shearers have never asked for a pay rise that wasn't justified by increases in the cost of living. So that change in behavior is what the change in behavior is the reward for the for the wool industry, not the actual robots themselves. So that's a really interesting, you know, lesson that sometimes you develop technology to change the behavior of people, and that actually commercializing the product is not is not an important.

Aaron Moncur: 55:48

That is fascinating. Wow. Well, James, I know we're, we're probably we're coming up on time, or perhaps even a little bit over at this point. Do you have time for one more question?

James Trevelyan: 55:59

Yeah, of course.

Aaron Moncur: 56:00

Okay. All right. We've kind of touched on a variety of things already that that are likely good candidate answers to this question. But I'll just ask it a little more directly. Now, what what is one thing that you've done, or discovered in your research to accelerate the speed of engineering? I know earlier, you talked about senior engineers doing design checks, as opposed to junior engineers. And of course, we've talked quite a bit about collaboration. What else comes to mind in terms of accelerating the speed of engineering and the more detailed, specific tactical you can get about your response? I think the more valuable it will be to those who are listening.

James Trevelyan: 56:48

Thank you, Aaron, for asking that question. And it's one I've given quite a bit of thought to. So I'm going to give you your listeners an example from my experience in developing our little cozy air conditioners. What are the things that I've learned is that computational fluid mechanics has its limits. And the most useful way that I have found to speed up engineering development with our little air conditioners, is to do simple experiments with instrumentation that when I started as an engineer was hideously expensive, but it's now very inexpensive, easily purchased accurate temperature measurement for a start, and get engineers to do these simple experiments, simple measurements, because when engineers confront the, if you like ground truth, that's when perception start to shift. So for example, when I took a prototype to a factory in China, and asked them to copy my design, I said, just produce 50 copies, I want to see if this is going to work in Pakistan. And I took it to a factory which will professional copycats. You know, I mean, ethical copycats in the sense that they would replicate designs, as as an OEM manufacturer, for companies like us. So these engineers said about producing what they thought was a replica of my little air conditioner, tiny air conditioner, easily portable. And before I came to the factory to inspect the results, they said, Oh, you know, your machine doesn't really work very well. It hasn't really performed really well in our tests. So when I arrived at the factory, I was a little bit concerned. And they had my prototype there. They had their copy. And they had tested their copy in their very elaborate testing laboratory. And they produced results, which show that didn't really work terribly well at all. I wasn't interested in looking at their expensive thermodynamic testing lab. I had two or three thermocouples. And a, if you like a piece of cotton thread, which I could use to evaluate air velocity, and air direction, turbulence, and so on. And I put my instrumentation on my prototype. And I put the same instrumentation on their prototype. And I said, Whoa, there's your answer. My prototype performed about 60 70% better. And it was quite obvious by looking at these thermocouple instruments which produced a temperature you know, the little$10 instruments that you can buy on Alibaba. And they looked at me in astonishment, and they said, Please We've done something wrong. And so it was this. It was, it was, if you like the ability to demonstrate performance through simple instrumentation, that's what really changed their perceptions.

Aaron Moncur: 1:00:13

That's wonderful.

James Trevelyan: 1:00:16

So think of this, think of the simplest way you can, you can do do a test, you know, I had a young engineer with me just the other day. And he was struggling to understand why the temperature of the tubes in an air conditioning heat exchanger would be the same from top to bottom. He thought, well, it'll be coldest at one end and hottest at the other end, and there'll be a, you know, each tube will be a little bit warmer than the other than the next. And I said, Okay, do this experiment, take this thermocouple probe, get a glass, fill it with ice cubes, put water in the glass, and put your thermocouple probe right in the middle of the glass, and observe the temperature as the ice melts. And, of course, what he observed was that the temperature in the in the water was zero degrees Celsius, 32 degrees Fahrenheit, until all the ice had melted. Because of the latent heat of the phase change from solid to liquid. And when he came back, he said, of course, now, it's obvious. Now I can really understand but having been through my physics education, I was struggling to figure out what it would be. But now that I've done the experiment, and I can see it with my own eyes, now I understand. Yeah, so that's my suggestion, get people to do simple experiments just to learn. Great, great. Well,

Aaron Moncur: 1:01:44

James, thank you so much for spending some time here on The being an engineer podcast, I really, really enjoyed hearing about your research, and some of the conclusions that you've come to certainly recommend your books, and I will include links in the show notes to to those books. Anything else that we haven't covered that you think would be important to share? Before we we sign off?

James Trevelyan: 1:02:10

Well, please put a link to my two little air conditioners as well, I'll make sure I'll send that to you so that people can look at them. And these, I think have the potential to transform the world. And it's been a really fascinating exercise to come up with something so simple, you know, in engineering simplicity is undervalued. Often, but, you know, if you do come up with simple solutions, they can be incredibly effective commercially.

Aaron Moncur: 1:02:37

Yes, I will second that. I know that. We, as engineers, in general, the temptation to make something complicated is high, because complicated is fun, complicated, is intriguing and sexy. And so oftentimes, we go down these these rabbit holes, maybe not even realizing consciously that we're designing something that's overly complex. And I've been there myself, especially as a younger engineer. So I certainly support that that statement that you made. Well, thank you again, so much for for being on the show. How can how can folks get in touch with you?

James Trevelyan: 1:03:22

LinkedIn, email works despite what I said, email to my University of Western Australia contact I'm easily found on on the internet. Happy to engage and help when I can.

Aaron Moncur: 1:03:35

Terrific. Okay. Well, thank you so much again, James, for being on the podcast.

James Trevelyan: 1:03:40

Pleasure, all the best Aaron.

Aaron Moncur: 1:03:43

I'm Aaron Moncur, founder of pipeline design, and engineering. If you liked what you heard today, please share the episode. To learn how your team can leverage our team's expertise developing advanced manufacturing processes, automated machines and custom fixtures complemented with product design and r&d services. Visit us at Team pipeline.us. To join a vibrant community of engineers online, visit the wave dot engineer. Thank you for listening