Interview with Ian McGaw, Vice President of Technology and Innovation at ENGworks

Transcript

Ledge: Ian, it’s great to have you on. Thanks for joining us.

Ian: Yeah. Thanks very much for having me, Ledge.

Ledge: If you don’t mind, for those who don’t know you, would you give a quick intro of yourself and your work?

Ian: Sure. Absolutely. So, Ian McGaw. I’m the Vice President of Technology and Innovation at ENGworks. We are a technology service firm that focuses on the building sector.

I’ve been working in this space for about 15 years now, focused mainly on creating integrations between different systems of information. Essentially, connecting the virtual world to our built environment.

So, whether that is having to do with IoT sensors and pulling that information and aggregating it together to run some machine learning algorithms, or simply just collecting data from the field from people that are installing devices and pieces of equipment.

So, very exciting space and just been really exciting.

Ledge: Absolutely. Just for the audience then, we’re talking about building physical buildings. The places that we all work and live.

I think everybody has this sense now that technology is becoming embedded and this mesh of information-generating devices and sensors and IoT, all that stuff. All of which rolls up in some way or another to software systems which will be very familiar to the audience.

Maybe paint the picture of how those worlds are coming together, I guess people say, at the edge. The edge environment necessary to turn the world into an information device or mesh at large.

Ian: Absolutely, Ledge. The worlds have really collided in the last 10 or so years. Just to give some background to the listeners and to your audience, the AEC or architecture, engineering and construction industry is typically behind and very lagging in technology adoption and using the new technologies.

So what we’ve done at least recently – and when I say recently I mean in the past few years – is really diving into some of the different visualization components. What we’re trying to do, as I mentioned before, is smooth out the process between the office and the field.

By utilizing some augmented reality – and we use many different platforms to provide these experiences; we’re using the HoloLens, or we’re using a thing called the RealWear or the Magic Leap as well – what we’re doing is we’re essentially creating these virtual mockups.

It’s very similar if you think of creating a wire frame. We’re creating these kind of bits and pieces virtually that do go together, and then we’re able to overlay that in our physical environment.

What we’re finding is that a lot of tradespeople that are in the field that are installing these systems and things like that, they’re able to capture a whole bunch of information that we previously didn’t have access to. So that’s one thing that we’re really doing that’s pretty interesting.

Then, another thing that we’ve doven pretty deep into has been some machine learning with IoT devices. What we’re actually trying to do, and on the cusp of doing, is connecting a living building’s systems, through these different sensors – and we’re looking at things like temperature, humidity and vibration and even some lighting analysis.

We’re pulling all that information into a database and were applying machine learning to it. It’s essentially just regression trees. It’s nothing out of ordinary or really groundbreaking in that sense. But what we’re able to do is find and identify alerts and alarms before they become an issue in the field.

Typically, when a building is in operation we’re always there to be proactive in the maintenance. Traditionally, building operators are late to the game in that case. If the fire protection system goes off and it’s filling your office with water, they find out about it once your office is half full. We want people to understand that much earlier and be able to be proactive instead of reactive.

Also in that light, what we’re doing is we’re able to take those insights from the sensors and pull them back into our design process. So, typically an architect or an engineer would be able to understand exactly that a specific office or a specific area may be too hot in a building. So to redesign the system for thermal comfort for the people that need to utilize that space. All data driven, very in-depth pieces like that.

We’re really focused on the digital transformation of the AEC. I think sometimes that that acronym and those words are a little bit overused, and certainly some buzzwords at this point, but as I mentioned because the AEC is a little bit behind, we’re really trying to do that.

Now, one of the things that I feel very deeply in is learning from other industries. Which is really why we’ve attempted to take some different programming and learning from different industries, specifically web development, and applying them into our projects.

For instance, I’ve got a project right now that’s a hospital and it’s quite large. I believe that the total budget on it is about $850 million. What we’re doing with this is we’re collecting and managing all of the information throughout this building life cycle, and we’re using different tools throughout the different phases to either gather that data or to QA that data. We’re actually utilizing MongoDB, the Atlas product, to house all of this information in kind of a blob storage, if you will, where it’s pretty unstructured and we’re able to query that information pretty quickly.

That project has been very interesting but the reason I bring it up is because when we first began we didn’t start with MongoDB, we actually started with an Excel file in Dropbox. But our data requirements became so large that we needed something else to host and to maintain that information.

The reason I bring that up too is because on each one of our projects what we try and do is really apply our constant check-in/check-out methodologies, or the CI/CD methodologies, there. It seems as though it works pretty well for buildings and our project workflow.

Ledge: In software we’re going to be talking about CI/CD obviously. It’s continuous integration, continuous deployment. So that each time we do some work it autobuilds or in some nature just goes up to… The penultimate would be we can submit some code, it will automatically run through all kinds of testing and it will just go to production and everything will work.

Now, it’s rare to find an environment that it can achieve that, but what does that look like in the physical space? It seems harder to imagine MVP build and test as you go when you’re working with steel, concrete and dry wall.

Just paint that picture because it might be foreign to those of us in the bits and bytes world.

Ian: Sure. To give an example of that, one of the things – and actually you keyed off on it – is some of the building materials.

We’re actually doing rapid prototyping on a lot of our construction materials. Things like concrete, for instance. Certain high-rise buildings need a very high tensile strength type of concrete. So, what were able to do is rapidly test whether a certain product, whether that’s concrete or steel, is going to fit the bill and allow us to, for instance, build taller or come up with a different type of building design. One that maybe . What I mean by that is it has a pretty small base and then it gets larger as it goes up.

That’s kind of the CI/CD that we’re doing. Is more of a rapid prototyping and applying what we learn from those prototypes into the building design.

Ledge: Okay. So you can use digital technologies then to model and predict before committing to a design that may or may not be exactly what you want to do.

Ian: Precisely. Yes.

Ledge: Understood. What does that iteration cycle look like then? That speaks to a software and agile mindset where you don’t… I guess the picture would have been that you drew blueprints and designs and engineering and all that, and you just kind of went and built it. So it would be more like a waterfall kind of design or methodology that would be familiar. People in fact come in and often think you can build software like way, and you can’t.

I guess you’re able then to push right more and more and more prior to the build in a more iterative fashion then?

Ian: Yes, absolutely. One of the things, and the reason that we’ve identified these pathways in this way, is because our design and construction schedules are always shrinking. We never have enough time. So our iteration cycles – and it really depends on the project – but they’ll range from anywhere in the week range to maybe three weeks, maybe a month, depending on what we’re looking at doing and how inventive we’re trying to get.

Ledge: So you’re using these sensors and tools as you go. Then, once you have entered the physical build and you’re taking feedback then from what actually happens on the ground, does it often deviate from the predictive modeling? What kind of thresholds do you experience there between real world and computer world?

Ian: It’s a great question. When we first started doing this it used to deviate greatly. However, there was a large shift in mindset and the acceptance of some of these technologies by people on the ground. So what we’ve seen now is, the standard deviation in what we’re seeing out in the field versus what we have created virtually is very close to zero at this point.

Of course there’s still certain deviations that we can’t account for. Building tolerance is typically, you try and build to about an eighth of an inch of a building tolerance. So there’s a little bit of fudge that’s allowed in there. Whereas certain other tolerances, if you think of aircraft manufacturing, your tolerance is almost zero if not zero.

Ledge: Sure. So you’re able to not have to deal with microns. You’re talking about a couple of millimeters maybe, and that’s okay. The material can count for that.

You actually modeling the future state – you talked about the climate control, for example. So you can go through a design before the building is made and kind of go, hey, that office is going to be stifling, maybe change the way that this is built.

Ian: Oh, absolutely. One of the things that we’re doing today is we’re actually taking some of this tribal knowledge that we have, and we’ve got some really talented building engineers here as well as some software engineers that are collaborating together, to take this energy analysis information or the knowledge of the calculations and actually try and automate that process.

For instance, if an architect draws a box, and we’ll just call it 100 X 100, and it’s got glass all the way around it. Well, the southern side of that building is going to get much hotter than the northern side just because of the heat gain – at least here in the hemisphere that we’re in. So what we’re able to do is to identify where that solar gain is automatically coming in and then understanding, okay, well we need 15% more cooling in those areas.

We can work backwards into the design then and say, okay, well we may need a larger rooftop cooling unit just on that side. Or, when we’re balancing the building, what does that look like? So that we’re not creating a negative pressure flow and things like that throughout the spaces as well.

Machine learning is really helping in those functions as well. Some of them are just are just straight hardcoded in there because of the way that the legacy calculations had been created and are being utilized, but that’s one thing we can do.

Another great example is having to do with clash detection. Oftentimes – and this is more of the traditional route – an architect and an engineer would collaborate together and come up with this 2D building on plans. They would never really look at how the different systems interact with each other. So, starting about 12 years ago, certain technologies came out that allowed us to quickly generate three dimensional models and identify areas where, for instance, a piece of HVAC ductwork might be running right through a piece of support steel.

Before, we manually had to go and identify these problems and then fix them in these native softwares. That’s very much how in the waterfall method you identify a bug, you have to go back and fix it. But what we’re getting to now is, as the architects and engineers are drawing out their systems, they’re automatically identifying where issues may arise or have arisen. Again, that’s just with the use of some nice, sleek algorithms.

Ledge: That’s fantastic. I imagine you, in your role, you must have many cross-disciplinary team members. You’ve got all kinds of inputs, machine, human or otherwise, that you need to pull together into some kind of a cohesive, orchestrated dance.

I’ll talk to a lot of tech leaders who are now at least having to look at that from a standpoint of, gee, how do I manage and integrate data science and software engineering? You’ve got both of those and then you’ve got all other sort of disciplines that are pulling together.

How do you conceptualize the right cross-functional team to know that you’ve got all the right ideas in the right order at the table? What does that process look like?

Ian: Most of the time, those decisions are typically left up to a building owner or kind of the ultimate client on a building project. So, sometimes we get the team that we get. We have to do a lot of education early on in the project to say, look, here’s our baseline, this is what we can do but this is where we want to go.

I don’t want to pick on architects, but we always run into the architect that just wants to draw their design out on a napkin and say, hey, this is my concept and let’s just build this. So, for those folks, it’s a bit of a change in thinking and mentality of, okay, well instead of on a napkin let’s put a virtual reality headset on and let’s sketch it out in there. So that we can then start digitally and carry that forward – so that we’re not going back and forth between a digital and an analog input. Would probably be the most difficult thing that we’ve had to deal with in these projects.

There have been a couple of projects where we have worked directly with the owner, and we were able to select the team. You know, a couple of the things that we look for in terms of valuable team members, one of the questions we always ask is, are you open to learning new methodologies and trying new methodologies?

The second question that we ask ourselves as we’re evaluating these partners and teams is, what do their communication protocols look like? If a singular team member is not communicating with the rest of the team, well, you’re only as good as that person’s communication. Being as these teams are generally quite large, you’re talking typically between 25 and 30 stakeholders on a decent sized project.

Then the third thing that we always evaluate is, how do these team members work with other team members? We don’t want someone to just simply come in and say, oh, this is my way or the highway, kind of a mentality. We always foster and like to foster a creative and collaborative environment on our projects. Simply, that’s because there are so many unknowns when you’re designing and building a building, and then of course operating it, that we have to stay flexible. We have to stay agile.

Ledge: Absolutely. Just off the top of your head, I’m curious. How much of this is a technology problem versus what percent is a people problem?

Ian: Technology is catching up. Before, I would say that it was probably a 70/30 ratio, where 70% was lack of technology. But now I think we’re getting much closer to a 50/50 breakdown. We’re seeing this a lot too as some of the older generations are moving on and sunsetting and some of the younger generations are really wanting to push this technology, and almost wanting a pushbutton solution to identify some of these things that we’ve known for hundreds of years now.

Typically, HVAC design, the algorithms have not changed for about a hundred years. So we’re really trying to bring that in-depth knowledge forward.

All of our projects, actually, we try and identify who the mentors are in those projects so that if we’ve got a younger engineer or architect or whomever, they can then couple with that mentor and really learn much more than they would have just on their own. Of course these are very intelligent people as well, and not that they couldn’t figure it out on their own, but they’ll figure it out in half the timeframe with some of these mentors.

That’s one of the things that’s very near and dear to my heart, is the mentorship and passing on that learning to others.

Ledge: Fascinating stuff. So, I’ve got a lightening round for you. I didn’t tell you about this ahead of time but this is important stuff.

Star Wars or Star Trek?

Ian: Wow. That is quite the question. I’m going to have to go with Star Wars at this point.

Ledge: Okay. What are you reading right now?

Ian: I’m just finishing – and I’m a little behind on the times on this, but I was just finishing Zen and the Art of Motorcycle Maintenance.

Ledge: Excellent. What can’t you live without?

Ian: Probably my iPhone.

Ledge: Everybody says that. What’s the last thing you Googled for work?

Ian: What was it? Oh, gosh. It was about… It’s actually for work. I was thinking of something else. What was I thinking about? I think it actually was aircraft maintenance, because what I wanted to do and understand better was to understand how the ground team is constantly maintaining aircraft in near real time where they’ve got these very small windows of operations. To see if we could garner any insights from that to the building side.

Ledge: Excellent. Very interesting. So I don’t know if you ever watched The Office on TV. There’s a classic episode where Jim is messing with Dwight and he’s sending him faxes from future Dwight. He tells him the coffee is poisoned and all kinds of things to mess with him.

But I like to ask, if I gave you one sheet of paper and a Sharpie, what would you fax back to yourself ten years ago?

Ian: Don’t drink the Kool-Aid.

Ledge: Care to elaborate?

Ian: When I say don’t drink the Kool-Aid I kind of mean, don’t get caught up in the mundane. There is always something newer and better that’s out there and we just have to keep our eyes to the future.

Ledge: I can’t beat that. Ian, thank you so much. Thanks for your insights and love hearing about what you guys are working on.

Ian: Absolutely. Thanks very much for having me.