Sean started where most engineers start… with an interest in maths and science.  He grew up in a very small town in the middle of Ireland and his mum worked for the local county council.  And while he didn’t know any of the engineers on staff there, he kind of had a baseline understanding of what engineers did. 

But Sean’s real interest was around buildings.  He wanted to know more about buildings.  He originally had his heart set on becoming an architect, but when that didn’t turn out he looked towards engineering.  Which he says was a very good decision…. 

I would have made a very poor architect

Extra discussions during the episode

This is a “close” copy of the words that were spoken during the Podcast, Season 4 Episode 17

It is not 100% accurate.
The guest was Sean Brady

INTRO

Sean: [00:00:00] I would have made a very poor architect, I think a much, much better engineer in terms of how I think about the world and approach the world. 

[00:00:06] Mel or Dom: [00:00:06] do you remember the very first project you worked on as an engineer after you had graduated? 

[00:00:11] Sean: [00:00:11] Yeah. So I went straight into postgraduate after I graduated. and then basically came straight out to Australia  after that. And my  first jobs I did when I came out here was we did a lot of instrumentation of bridges. So we’d put strain, gauges, we monitor essentially how bridges were behaving in, in real life. 

[00:00:28] So it was great when I first arrived because you got sent here, there, and everywhere put instruments on bridges and you got to visit places and you found when you did that, that bridges behaved totally differently in some cases than people think they behave when they model them and do the calculations for them. 

[00:00:44]that was my first sort of introduction to there’s difference between how we designed things and how we think things work versus how things actually work in real life. And that was sort of a splitting point for me once I got there, I was like, no, no, I’m really interested in how things actually work as opposed to how we designed them to work, which is, which is totally different than in some cases. 

[00:01:05]Mel or Dom: [00:01:05] so your first job as an engineer was essentially in Australia. So what made you hop on over? 

[00:01:12]Sean: [00:01:12] A mixture of, of adventure, wanted to come over and, do something a little bit different. And I actually got a job before I came out. So I got a job in Brisbane working with a company who specialized in instrumenting bridges and understanding how they worked. And I had done a lot of work like that in the PhD. 

[00:01:28]and  my supervisor had met somebody who was at a conference and they happen to live in Brisbane, Australia. I rang them up at one o’clock in the morning, one night, um, and basically said, can I have a job? Can I have a job, please? This is this, this quite idea. And it went, it went from there and that was about 17 years ago now. 

[00:01:45] Mel or Dom: [00:01:46] I can understand this. I’ve worked with. A lot of engineers who’ve come from Ireland over the years. And it’s great that we have such wonderful climate over here because then we get all your, the engineers and they stay. So they come over here on visas and then kind of go, yeah, this is nice. 

[00:02:04] I think we might stay, see,  

[00:02:07] Sean: [00:02:07] me and my partner came out and we said, two years, I’m gonna go back home. That was the plan. 

[00:02:13] Mel or Dom: [00:02:13] Okay. It’s 17 years later. 

[00:02:15] Sean: [00:02:15] no, absolutely didn’t work. 

[00:02:17]Mel or Dom: [00:02:17] now you have come a long way from where you started engineering, basically putting the instruments on the bridges, as you were saying. So where are you now? 

[00:02:27]Sean: [00:02:27] So there’s a few things I do now. primarily I’m a, what I would describe as a forensic structural engineer. So I get involved with structures that have either collapsed or have significant defects. And I really get involved when people want to understand what caused those defects. You meet engineers who do the compliance side and who work out well, was something designed the way it was meant to be designed. 

[00:02:54] That’s not what I do. I’m really interested in. I don’t really mind how it was designed, what actually took place on the day to create a situation where this structure broke or fell down. So I spent most of my time on that sort of work, usually on large infrastructure. and that’s one piece of  what I do. 

[00:03:13]the other work that I’ve got into more recently is. Looking at things in the mining industry a recently finished a parliamentary report on mining fatalities in Queensland. And that was a data driven forensic investigation of why fatalities were still continuing to occur. 

[00:03:30] And we were looked at that over the last 20 years. So that, that work is continuing and ongoing. and the parallels between it and the forensics are a huge cause at the end of the day, it’s still people and  it’s things going wrong. and because there’s people involved, even in a very technical professional, like engineering, you still get the same things not working out the way people planned. 

[00:03:54]Mel or Dom: [00:03:54] What got you into forensic engineering? Was there something like that sort of drew you to it? 

[00:03:59] Sean: [00:03:59] Yeah, it was, I mean, and it was one of those things where it looked like a sort of a natural combination, but it wasn’t planned. I remember when I was in uni and I work out reasonably quickly that I did not like design,  I’ve got no issue with it. Obviously it’s, it’s a very admirable profession, but to me, design is all about coming up with ways  of managing the uncertainty, and building in the conservatism that you need,  into a structure to make it work. And that didn’t appeal to me. I was always much more interested in with. Yeah,  how does it actually work?  if we really break it down, how does it work? 

[00:04:33]what all the work I did with hanging around real structures when I come to Australia, Monitoring, you’re collecting real data on how real things work when you sort of start applying the normal engineering theory to it, you find this, it actually behaves in quite a different way. And that’s the bit that I got really interested in was let’s follow the behavior. 

[00:04:51] Let’s try and model that and chase that down. And that was essentially forensic training. Certainly didn’t think of it like that at the time, but it was all about asking you what really happens. And when you get  a failure where something kind of structure collapses or, or breaks, really what people want to know was what was it doing the second before it fell? 

[00:05:10] That’s the key thing they’re asking. I found out that whole sort of six, seven years of training of I’m hanging around real structures, that that was sort of sending me on a path naturally. And you end up in the failure analysis because it’s where those skills work out best. 

[00:05:28]Mel or Dom: [00:05:28] So you’ve mentioned that you’ve recently just finished a parliamentary inquiry into the mining industry in this area. What got you into that side of things? 

[00:05:39] Sean: [00:05:39] Again, it’s sort of a natural progression. It was interesting because you, you start off looking at engineering failures and you say to yourself, well, engineering is a technical profession. engineers tend to think of themselves as very, very rational people. so we must have of technical causes  for failures for collapses, why things don’t work. 

[00:05:57] The more you get into that, you find that. Yeah, sure. There usually is some sort of technical failure, but it’s really the organizational factors and the human factors behind that, that are the key for causing these things. It’s people misusing codes, it’s people not checking things.  it’s the wrong materials and going in the wrong place. 

[00:06:18] And many engineers have the view that, you know, engineering was complicated and we must learn something new technically from all these failures. And the reality is we don’t. most things fall down for the exact same technical reasons they have over the last 50 years. what hasn’t changed is the human and organizational part of it were much more likely to cause a problem. 

[00:06:39]It’s not really a human error issue. It’s  humans are fallible. We will make errors. It’s when the system we build around us  to keep us safe, to catch the error. It’s all the checks and balances. It’s when that breaks which we sometimes see happen in spectacular fashion, that we get our collapses. 

[00:06:54] So that really over a long period of years, I got more and more interested in the human factors, the organizational factors that were driving these technical failures. And that sort of led me to, I did a lot of presentations about this sort of stuff. And that just led me  to the mining review, which is essentially looking at the organizational and human factors behind why things go wrong there.

HOT TOPIC 

[00:08:51]  I think it’s important to talk about because, we structural engineers particularly do not tend to see the world in terms of failures. failure and learning from failures and how to think about failures, particularly  from a systems perspective, to think about failure of a system. we do believe  it’s what happens to bad engineers, not what happens to us.  and I think if we’re really going to solve some of the big challenges out there as structural engineers and as engineers in general, we really have to start thinking about failure in a different way. And we have to start thinking of it from a system perspective and a complexity perspective. 

[00:09:25]Mel or Dom: [00:09:25] is it a case of when the failures occur as well, we as engineers, don’t tend to analyze them the way that we should? Cause you were saying earlier that one of the things that you didn’t like design is very prescriptive. 

[00:09:38]Is that part of the failure as well that we’ve taken what people have told to say in regards to the theory as to why things work. But as engineers, we’re not spending enough time actually looking at the physical world and saying, well, that’s what we were told back at university, but in reality, now that we’ve grown with data, this is what’s really happening. And maybe we should be applying that a little bit more regularly in regards to our designs and our standards and our codes.  is that something like that you see happening to engineering as a whole? 

[00:10:08] Sean: [00:10:08] I’ve been thinking it’s certainly part of it Dom. I think, we structural engineers are particularly bad at learning from failure. most professions are to be fair, but we’re a little bit interesting. We’re a little bit different than the mechanical engineers and the electrical engineers in the sense that  we structural engineers can’t prototype. If you’re not a structural engineer, you can do your designs theoretically, you can then build a prototype and then you can test it to figure out what, where you went wrong or where your theory doesn’t quite stack up. And you can refine, you can work out all the bugs. We don’t do that as structural engineers. We build bespoke things. And we only build them once, we can’t say to a client, we want to build your building and by the time we have a built, we’ll actually know how to build a properly. So we can’t say that to them. So what happens is we have a whole pile of assumptions and conservatism built into structural engineer that allow us to cope with those uncertainties. And then when we build a building and if it doesn’t fall down, well, all we can say is, well, it was successful, but we don’t really know why it was successful. 

[00:11:14]we know most of our assumptions have worked, but if some of them haven’t been right, we’re not always able to see them. We never quite know how close to the line we are when we do structural engineering. So, when failures happen, that’s an incredible feedback loop for us to understand how close to the line we are and how we can do it better. 

[00:11:35] So I think we structural engineers have a real difficulty of it, dealing with failure.  when you talk to engineers and you ask them why famous failures happened Many people are not able to answer those questions. And it really does come back to, we’re not very failure literate is the term that that is often used for this. 

[00:11:53] We do you think failure has happened to other people.And  it happens because people are bad engineers and we don’t necessarily understand that it is all these combinations of factors and it’s the system break down. That’s, that’s going to be really important in there . 

[00:12:06]Mel or Dom: [00:12:07] It is hard, cause as you said that people think that you’re a bad engineer, when in reality you can follow all the guidelines and everything.  People think that the engineers have done a bad job when in reality it’s not, they’ve done a bad job. It’s there’s usually, cause as we were saying before, there are so many factors that are associated with it.  

[00:12:22] Sean: [00:12:22] I put it up. It’s like different way Dom. what you can have is, you can have one massive stuff up, you can have someone really getting something wrong. That only culminates in a collapse or a failure, if all the defenses we’ve put in place to catch and identify that error fail. 

[00:12:43] And that’s when we get failures. So we were definitely seeing, if we stay on structural,  you see almost half of failures happen because of designers. Almost the other half happened because of construction errors. When you get to design errors, it is usually mistakes with computer programs, computer models, mistakes in calculations. 

[00:13:03]And when you get to the site, it’s usually people put stuff together in the wrong way. They put all the stuff there, but they put it together in the wrong way. And if those things aren’t caught, that’s where you really run into the trouble and you get the bad failure. 

[00:13:16]What is amazing when you show engineers  the way we get things wrong, it is really simple design errors. For example, one of the common design errors you see in bridges is people that calculate the dead load wrong. the dead load, the self way to the bridge should be one of the easiest things to calculate, you know, exactly how much material you’re putting into the bridge. 

[00:13:37]it’s amazing how many bridges end up with that calculation done wrong. Why? Well, it’s really boring. And engineer’s you, if you want to see where engineers are gonna mess up, find the boring stuff. and that’s where they things go wrong. We find connections instruction are really, really vulnerable. 

[00:13:55] Why because you ask any engineer, do you enjoy designing connections or do you like designing beams and columns? And they say beams and columns and they don’t like designing connections because connections are boring and fidgety and hard. That’s where you go look to find out, well where are people gonna mess up here and where do our checks and balances need to be, to catch that, that stuff before it actually gets out.  I sometimes say to engineers and design offices, you’re the last person who these drawings? Yes. Are you finding design errors? Yes. Well, You’ve just proven your system doesn’t work. You’ve just proven there are gaps and holes in your defenses. do you think then, you know, keep a log of these errors and go back and improve training and almost everyone says no we don’t. do you go back and plug the holes in your defenses where they’re letting you down? They don’t, we as human beings tend to congratulate ourselves about how necessary we are  to be here, to actually find this error, but of course everyone has a bad day or someday you’re not there. And then the error  slips through. 

[00:14:59]and certainly in my work, we are seeing more and more gross design errors. They’re becoming the big one now. 

[00:15:06]Mel or Dom: [00:15:06] On my side of the fence in the services sort of rhelm, a large part of the problem generally comes between the co-ordination of services as well. So it’s almost as though the engineers don’t want to talk to each other or they’re trying to get the documentation out the door so quickly that they just sort of make assumptions they really shouldn’t make. And then it’s not until you get out on the site where you’ve got an air conditioning system, that’s  got a massive electrical load and A DB that has nowhere near the capacity to cater for it. And then it becomes the age old sort of the two of them looking at each other going, well, you did not ask and go, well, you didn’t ask me either. 

[00:15:42]Well, what you’d assume right back at the design phase to be something so trivial is picking up the phone and saying, Hey, how much, yeah, how much power do you need to this system? And making sure that all those things kind of work. And I suppose that’s where it’s hard as well, because it’s a case of everyone’s to blame. 

[00:15:59] Sean: [00:15:59] Yeah. And we would call those interface errors. So those interface areas of people talking to one another, they are. Yeah, I really lethal when it comes to having failures. And the interesting thing is you see them in every profession, you see them in medicine as well. They’re one of the biggest areas in hospitals, where  if everyone’s not talking to each other in the hospital, or someone makes an assumption about why a patient is here, that’s when they roll into real trouble. 

[00:16:24]There was a, a lot of work came out of the Netherlands,around 2014. And they did a lot of work to try and work out. Why are, why are things failing and why are they not working? And they found your, two key aspects of, and we’re talking about technical failure here. So when I ask engineers, this they’ll say, Oh, well, it’s technical competency is the most important bit. 

[00:16:47] And it is, but other things are considerably more important. Like communication, collaboration are absolutely key, which has come back to exactly what you’re saying. You get the interface stuff right, you’re going to be in a whole lot better place. risk allocation, control mechanisms… so make sure whoever can carry and manage a risk, that they’re the ones who were actually assigned that risk. 

[00:17:10] And of course we don’t do that necessarily when we set up projects, particularly in, in the construction site, we don’t do that. And we tend to push the risk away from ourselves. But if risk ends up on someone’s lap who can’t manage that risk, then that whole project can be in real trouble because the people who can manage the risk don’t have to, the people who can’t manage the risk have to, and it starts to become a recipe for disaster. 

[00:17:34]Mel or Dom: [00:17:34] Yeah, that’s a really interesting point actually. it is such a big factor,  particularly in building construction at the moment in regards to  the associated risk, particularly with D&C contracts. The developers are taking away the responsibility from the engineers so they don’t have to pay the money up front and then pushing it onto the builders at the backend. 

[00:17:54] And the builders are obviously trying to construct something to time/budget constraints. So they’re trying to get things done as economically as they possibly can. But in reality, if they had to spent more time to put the risk with the engineers who actually need to. 

[00:18:08] Crunch the numbers and make sure that everything works and it’s going to come out with a much better product at the end. cause  the risks sort of sitting in the wrong spot. it’s almost as though the risks kind of being watered down and no one’s really being given the responsibility they should have in order to ensure  that nothing goes wrong at the end of the day. 

[00:18:25]Sean: [00:18:25] Yeah, it’s interesting. Isn’t it? Because  again, this comes back to us viewing that we’re a technical profession and we have control over the technical aspects of the project. But the reality is that the way these projects are set up goes right back to the contractual framework. So it goes right, right back to the, the legal side of thing and how risk and commercial risk and financial risk and legal risk are all managed together. 

[00:18:50]And what you see is that has a direct impact on the technical decisions that are made on the dares, some of the decisions that do to lead to failure and have led to catastrophic failures are the product of that organizational structure that is there. and it’s quite confronting  to sort of realize that the way you set up your project can have a very big influence on how safe from a technical perspective that project actually is. 

[00:19:17]and that can seem quite a disconnect at times. 

[00:19:19]Mel or Dom: [00:19:19] I have actually been quite silent on this while you and Dom had been talking because, You guys are in the thick of things and every time you brought up a topic, I’m like, how do we solve this? How do we solve this? you were saying as engineers or structural engineers, you can’t do lessons learned, what did you say you can’t prototype? And for me as a project manager, not being able to reflect and go, this is the lessons that we learned in this. 

[00:19:44] Yeah. In this case, in the structure and things like that, how do you overcome that? You can’t just sit around, waiting for a building to fall down and go, Oh yeah. That’s, that’s a mistake now. And we now know, and let’s move on. how do you reflect on those sort of things? 

[00:19:57] Sean: [00:19:57] Ah, you tell the stories is really the key part of it, but you tell the right story. and it’s very tempting from an engineering point of view. Engineers tend to want to know why, why did it break? What was the technical reason for the break? Is there a problem with the code? Was there a material issue? What was it? and those things are really important to answer, but then you have to make sure you answered the next thing, which we engineers don’t always want to do, which is what were the organizational factors,  that led to the situation where that technical error was missed? what was the drivers for that technical error? Not to be picked up, was it too many interfaces? Like we talked about earlier? Was it because there wasn’t enough communication and collaboration? Was it the way the project was actually set up in the beginning? 

[00:20:38]I think those are the key lessons that we have to pull out as a profession and use those lessons going forward to try and manage things. when we argue that those lessons have nothing to do with us, because we’re the engineers that, I think, is when we run into real problems. 

[00:20:54] Mel or Dom: [00:20:54] And another problem that you raised was that a lot of the failure comes around the boring bits. So the things that people don’t enjoy , when you were talking about that, I was thinking in my head, Oh, is AI going to solve this problem?  How do we fix the boring bits of engineering? 

[00:21:15] Sean: [00:21:15] Yeah, that’s really difficult. Um, and we’ve found that software isn’t necessarily the answer. The software creates different problems that we have to try and solve.  A lot of these comes from when you lose the holistic view of the structure. So if you, if you don’t have someone, you know, who, who is standing over everything, which what a nice holistic view of what’s happening. 

[00:21:40] If we break it down and segment it too much, we run into trouble. So you need someone, who’s got it all in their, in their head and understands what’s really important in it. That’s really critical. the other part of it that is really important is we love, and in the modern word, siloing people. 

[00:21:58] So we love saying that your, your expertise is this and your expertise is this. And you’re going to work there and you’re going to work there and you don’t need to talk to each other because you do your own jobs. The research is showing  not in engineering, but just in general, when you put all whole  group of people with this same expertise together, expertise is really at accumulated understanding of the patterns that govern how you do your job. 

[00:22:22]and they’re full of implicit assumptions, these patterns,  and we like to think we’re thinking rash. No, we’re not. We’re retrieving  these patterns, and we’re using these patterns to tell us what to do.  if everyone in the room’s got the same sort of patterns, then everyone in the room’s got the same sort of  blind spots. 

[00:22:37] They’ve got the same biases. which means that they’re, they do not necessarily see. Failure. Come on now with the benefit of hindsight, we all can we say, well that’s, that was always going to happen, but At the time when we look at these failures, you see all these signals  that people didn’t notice, and that is often due to Blindsight spots. 

[00:22:57]so it’s really important to get diversity into your teams, get a diversity of expertise in there. get people there who will ask the silly questions, get people there who will say, well, why is everyone. Assuming this is okay. Why are we not even talking about this? That’s what you mean, real progress because you’re, you’re getting those implicit assumptions that are quite dangerous and you’re making them explicit. 

[00:23:21] And once you’ve met them explicit, you can start to tackle them when you say well, is that really real in this situation? Is that a reasonable Assumption to make in this case. so diversity and be careful of the expertise. There are two things that are really, really important. If you want to try and solve this problem going forward. 

[00:23:37] Mel or Dom: [00:23:37] So, what are your thoughts on the future of engineering? 

[00:23:39]Sean: [00:23:39] I think we have to take a much more systems complexity theory approach to the future as engineers, And we’re not trained to do that. We engineers are trained to be in Newtonian, you know, we’re trained, you can take any problem and break it down into components or any system, break it into components. 

[00:23:58] And once you understand the behavior of those individual components, you can understand and predict the system. That is how we’re trained. And that works  for many, many things. But in today’s world with the interconnectivity, with everything. Systems don’t behave like that, they don’t  behave in that Newtonian way, they were having a complex where, and really what complexity means is, and we could talk about it all day, but what it really means is that, the components become less important. It’s the interactions between the components that become really, really important. And you can get nonlinear behavior. You can have little causes with big effects  because you get all these feedback loops. These are open systems. So something that happens outside the system will affect the system and the system  can respond and change to that. 

[00:24:48]and almost what you’re doing is you’re trying to keep up with the changes in the system. The system is evolving and you have to keep up with them and be able to deal with that complexity. And I think that’s where the world’s biggest problems are going to be solved, with that sort of thinking. 

[00:25:04] And I think we engineers, one of our greatest strengths has been the Newtonian view of the world that we can break it down and it is incredibly valuable and works really, really well. But I think if we can stretch ourselves a little, learn more about complexity, learn more about systems. We can take on some of the really big problems, not just in structural engineering, but in engineering and in general. 

[00:25:26]but that’s going to take creativity and our awareness of complexity and how it works for us to be able to do that. but when you start seeing the word like that, it becomes a really interesting, challenging place where you can, really try and solve some problems in a very different way. 

[00:25:45]Mel or Dom: [00:25:45] it’s a very different lens to look at the world through.  that’s a very interesting point to consider about the future. What would you say to people that are just coming into engineering? 

[00:25:57] Sean: [00:25:57] Do what you love. Do the bit that interests you most. one of the great things I think about engineering is if you have particular niche, if you have a thing that you love, you will find a niche where you can live and do your thing in engineering. I’ve met many engineers over the years who sort of get on the career path and don’t  know they have permission to get off it if they want and do other things with engineering and get into the piece that they love.  I think that’s the only advice I would give. That’s not straight forward in some cases, particularly as you move on in your career. 

[00:26:31] Mel or Dom: [00:26:31] about to say, is there a window of opportunity there? Just be aware of that window closing. 

[00:26:36] Sean: [00:26:36] And I think it for a lot of engineers, the big challenge you see is that you get to start making choices for the year, your career. Are you going to be a manager? Are you going to get into BD? Are you going to become more of a project manager? And I think you have to be a little bit deliberate about some of those things, you have to say to yourself… well, this is a promotion, but is the job I’m being promoted to really what I want to do. and I think that’s a question  that people don’t always ask themselves. And then there’s sometimes discover this is not a job I really want to do. I prefer my old job a little bit more, but some of those skillsets that you need are very, very different. 

[00:27:10] my advice would be, try and figure out what you’re good at and find a niche to be able to keep doing it. 

[00:27:14]Mel or Dom: [00:27:14] Yeah, I it’s probably one of the things that we’ve part of the reason when we started the podcast was to also show people out there that old view of engineering, where it’s just the case of designing and that’s it, you’re a designer and that’s sort of all there is. Where there’s so many facets,  it really is a career that can sort of take you wherever you want. So I think that’s something that people kind of need to keep in the back of their minds as their career progresses as well. 

[00:27:40] Now, just to finish up, sort of always ask a couple of questions just in regards to engineering and, first being… what’s a piece of engineering that impresses you. 

[00:27:50]Sean: [00:27:50] A few things.  Generally, they’ve got good stories behind them. So I’m not quite sure of whether it’s the story or the engineering, which sort of impresses me most, but I mean anything to do with the Apollo Space program, I tend to get a real kick out of, in terms of the problems that were solved. And the understanding that people had to get the Panama Canal is an incredible piece of engineering as well. 

[00:28:11] Mel or Dom: [00:28:11] And that has an interesting story to it as well. Doesn’t it? Yeah. 

[00:28:14] Sean: [00:28:14] how it ended up being made, what politics and all sorts of the stuff at the background. And then any of the big bridges, I mean, bridges were probably the thing that got me interested in engineering first. And certainly some of those, like the golden gate bridge and that, and Sydney Harbor bridge that you still look at them and bridges are an emotional thing. I think for most people they’ve, you know, even if you know nothing about engineering, you, you can’t help, but go wow when you see what they do. 

[00:28:39] Mel or Dom: [00:28:39] It’s amazing. It always comes back to bridges on this podcast. So many people talk about bridges. That’s not true because in the first series it usually came back to toilets. So yes, that’s true. Yes. Nine lately. It’s been bridges, but yeah. And also Apollo, you must’ve loved doing the research because you’ve got that Saving Apollo? 

[00:28:59] Sean: [00:28:59] Saving Apollo 13. Yeah, the podcast, Saving  

[00:29:01] Mel or Dom: [00:29:01] Apollo 13. 

[00:29:01] Yeah. Podcasts. So you would have loved deep diving into that one. 

[00:29:05] Sean: [00:29:05] Yeah, it was great. And it was a great challenge in terms of..  we wanted to tell a proper tech story. So he didn’t want to do the Hollywood version where you sort of skim over all the tech details, but then the challenge became, how do you tell a tech story in a way that most people will want to listen to it? 

[00:29:19] And won’t really realize they’re being told the tech story until they’re finished. They h opefully will get carried along by the, the human aspect of the story. So, yeah, it was, it was great 

[00:29:27] Mel or Dom: [00:29:27] Yeah, it’s 

[00:29:28] Sean: [00:29:28] um, challenge trying to understand all the techie bits and then get them converted into a way that, that you could tell the story that people would get their head around what was happening. 

[00:29:37]Mel or Dom: [00:29:37] No, that’s a, it’s a good one to listen to. and just to wrap up, do you have an engineer that you admire? 

[00:29:42] Sean: [00:29:42] Yeah, probably Emily Roebling.  she finished the Brooklyn bridge and. I think it’s an incredible story as well, but you know, this was at the time this was a male dominated profession. she basically taught herself engineering to be able to finish the bridge after her husband, got incapacitated. 

[00:30:04]And she got it done.  and it’s just an incredible story of going, yep this is a job that needs to be done and I’m going to work out how to do it. And she got on and did it, even though society at the time said, this is not something you can do. And they tried to stop her on multiple occasions, but were unsuccessful. 

[00:30:20] She was quite formidable in terms of, of getting the job done. 

[00:30:24]Mel or Dom: [00:30:24] Yeah,  there’s a real story there in that. you hear a lot about the whole,  she conquered the times and actually did this thing and it seems when you gloss over it, Oh, just people just did it. Like she just did it, but I think there’s a real story in there in that. Yeah. What you were saying that they did try multiple times and she just kept going and just kept going and delivered it and achieved it. 

[00:30:52] So , yeah. she is an inspiring character in this whole story of engineers. Absolutely. 

[00:30:59] Sean: [00:30:59] Yeah, she really is. She really is. And it’s got everything that story. It’s got 

[00:31:04] Mel or Dom: [00:31:04] Yes, it does, thank you so much for joining us today. We really, I feel like we’ve learned so much. Thanks for joining us. It’s been excellent.  

[00:31:11] Sean: [00:31:11] No problem at all, I really enjoyed it. 

Outro 

And thank you for listening to Engineering Heroes as we present the new dawn of engineering challenges for Engineers Australia. Your hosts have been Melanie and Dominic De Gioia. You can view this episode’s show notes or learn more about our podcast by visiting our website, www.engineeringheroes.com.au 

If you enjoy today’s show, all we ask for you to do is go and tell someone. Either in person or write a review, it’s that easy to show your support for engineers everywhere.  

We look forward to you joining us next week when we bring you another interview with one of our engineering champions.