Trent Leinenbach sits at the front lines of construction technology adoption, as a thought leader and "Construction Dork," as well as VDC & Technology manager at North Mechanical. We discuss how innovation happens in the field as teams really use technology, and how technology providers can handle seemingly endless requests for customization by building for that early.
Trent is one of four hosts of the Construction Dorks, find more about them here: https://www.constructiondorks.com/
Hugh Seaton: [00:00:00] Welcome to constructed futures, I'm Hugh Seaton. Today I'm here with Trent Leinenbach, VDC and technology manager at north mechanical. Trent, welcome to the podcast.
Trent Leinenbach: [00:00:13] Thanks for having me.
Hugh Seaton: [00:00:14] So, Trent, I want to talk about one of those things that the people who don't themselves actually implement technology often, either take for granted or don't take the time to really understand.
And that's what goes into onboarding someone else's software. So you're a user of software, not a software company. So you have to make sure you're using the right... selecting the right thing, make sure that it's working, make sure it's integrated, so on. Talk to me a little bit about the process you go through to make sure all that works.
Trent Leinenbach: [00:00:46] Yeah, it's tricky, right? I mean, that's why we have someone like me. And I know you've spoke with Travis Voss from helm. You know, companies are realizing that there's value to this kind of vetting. The problem is as we evolve and we become more technological those out of the box solutions that are out there Aren't the best for us.
And you know, we have a process that's been implemented over years of doing what we do. And, you know, we kind of believe in that theory that the tech shouldn't shouldn't force your process, you know, The process should force what tech you select and the tech should augment you and help you view to accomplish what you already do.
I mean, we're not, we're not rewriting what we are as a core company, but we're finding solutions to help us accomplish that stuff. And that's, that's why the role is so important because. Your traditional software is an onboarding... you know, I'm not taking anything away from the software companies, but the way it always kind of happened was there were people came on site and, and trained your company to do what they developed.
And it's, it's just not the way we operate. I mean, we select softwares that have open APIs and that are very open-ended and allow you to kind of tailor them to what you do as a company. And that's kind of the step one in, in selection is like, I think some of the first questions that you should ask is, does it have an open API.
Hugh Seaton: [00:02:17] Talk a little bit about what you mean by open API for folks that don't spend time on that.
Trent Leinenbach: [00:02:22] Yeah, sure. So, I mean, does it have the ability for me... I won't get into talking about calls and things like that, but does it have all the information and what I'm doing within that particular piece of software? Does it have the ability for me to pull that and leverage it in a different environment or a different, does it have the ability to speak to the other software programs that we use?
Because, you know, we don't have that one-stop shop. And when it comes to trying to put together a tech stack, you want best in breed in every in every category. So...
Hugh Seaton: [00:02:59] Let me take a sec , you know, some of what you're talking about is, is historically companies kind of made their own thing and they got it out the door and they didn't assume there was going to be an, you know, an easy way to connect their output with someone else's input. And what I think you're talking about is modern software, certainly after they're past their MVP and they're, they have, you know, a relatively mature product, they should be assuming that yes, either they're going to be taking in information and data from something else and, or they're going to be sending it out.
So they need to have an API built, that has rules and has, you know, kind of the you're right. The calls and so on so that someone else can figure out how to connect to that system so that you can use best in breed instead of having to do crazy workarounds, to make things work. That's what you're talking about, right, is that they've thought through how to expose what they do to other systems so that they can connect together. Or you can do the connecting, but either way, if they don't have an API built, they're a standalone little, little island that, that can't connect to anything else.
Trent Leinenbach: [00:04:03] Absolutely. And I think they're going to be dead in the water in the future, for sure.
I mean, especially as roles like myself and Travis and the people you're talking to as those push through more companies you know, those softwares that, that kind of stay closed off and, and try to do it all, you know, they're, they're probably going to fail. For that reason, but you know, there'll be incentives and you just, we're trying to create the incentives for these companies to have that open API and to give us that ability, I mean, there's a big monetization that's capable there, so that's kind of the incentive.
And I think we're okay with that. That's how we're going to get to where we need to be. For that, you know, that data exchange that people like Nathan Wood and them talk about all the time that that's how you're going to get there.
Hugh Seaton: [00:04:51] And, you know, to put this into more concrete words, you're talking about, software that might help with detailing in Revit or software that might help with estimating or, you know, doing submittals or various parts of the, of the end-to-end process so that you're not taking things from one phase and, you know, God forbid having to hand enter things, which of course still happens more than it should.
Right. So phase to phase, and even within phase is being able to pass data from one worker or one specialist to another, because each of them has software that's optimized for what they do, right? Like it is not, not accounting software.
Trent Leinenbach: [00:05:28] Yeah. I always say we have to be able to move data to an environment that can be leveraged by a different skillset.
Right? I mean, so my detailers skill set is in Revit or, you know, insert detailing software here. Revit happens to be kind of the industry standard here right now, but you know, the detailer knows how to leverage the data there. But moving forward to purchasing and management, fab shop and field installation, that's not an environment that, that allows that user to leverage that data. So we have other softwares that we push that data to, and I'll mention you know, GTP Stratus is one that we use here at north. And that's, that's an environment that other skill sets can leverage all of that data that, that comes from Revvit.
But without that open-ended integration of some kind, you would never be able to achieve that. If, if GTP and Autodesk, it didn't have that relationship and the ability to transfer and speak with each other, then that data would live in Revvit and probably die in Revvit.
Hugh Seaton: [00:06:34] Or it would be hand entered from one to the other, which in the, in the beginning, that, that used to be the case sometimes. Right. Is that right? And, I mean, I've heard horror stories, especially on the trade side where different GCs use different things. And people had to find all sorts of crazy ways to deal with whether it was a Procor or a an Oracle or, you know, different, different kind of platform softwares that they all had to support. And it gets a little crazy.
Trent Leinenbach: [00:06:59] Yeah. Or we end up, we ended up spending a bunch of money on something that's data rich, and then the way we pull the information out of it is to dumb it down to something that's lines on paper.
Hugh Seaton: [00:07:10] Yeah. That never happens in construction, right?
Trent Leinenbach: [00:07:13] Yeah. I mean, that's still probably the Uber majority of that, of how that works.
Hugh Seaton: [00:07:18] Yeah. I mean, I think some of that, right, Is contractual and, and kind of risk. One party sense of their, of their own risk and what they want to hand off, which is a series of podcasts of its own.
Trent Leinenbach: [00:07:30] Right. But internally we're, we're going to use the data no matter what. So the struggle we have is when it comes to that turnover to your customer, right.
You know, I actually have to spend money to dumb down what we've done generally. So.
Hugh Seaton: [00:07:44] But it's a crazy world. And I think, you know, that this, this idea of where risk lives and where it doesn't, I don't think we've figured it out yet. You know, I think there's a lot of, a lot of work and a lot of evolution in the industry to, to open up some of the sense of risk when you're passing data back and forth, which I think as I think we're figuring that out, you know, there's just so many new technologies that can create so much more information that no one has figured out quite what risk that creates. So you say, well then we're not going to send it forward because who knows?
I, you know, I don't, I don't want to be the, the case everybody references.
Trent Leinenbach: [00:08:18] Yeah, but you know, what I would tell them is every time you have to manipulate that, whatever, you're calling it, the model to a document, I mean, every hand that that has to touch to produce contractually what the customer needs, you're introducing another step for errors for, for malfunction, for things.
I think when you talk about risk, the more work you have to do to, to get to that, like antiquated deliverable, you're just introducing all the more chances for it to be wrong.
Hugh Seaton: [00:08:48] Isn't that an interesting way of looking at it? Right? On the one hand you have the the risk of, of actually failing. Of actually having problems in rework, and all the fun that that implies.
But on the other hand, you have the risk of later litigation. So it's a tight rope that you guys have to have to have to walk, right? Is between sharing things, cause you know, that'll make the project go better versus not sharing things because you know that that's one risk that you haven't created in terms of, you know, downstream litigation risk.
Which is freaky because no one's a lawyer. Well, not no one's a lawyer, but most people involved are not lawyers. So the sense of what really is a risk and what isn't, I don't know. I always seem to get that wrong when I talk to a lawyer, they're always like, yeah , you're 80% there, but you forgot about this part .
Trent Leinenbach: [00:09:33] Yeah. That's... it is interesting when you think about it. Cause it I think we just... We just have to kind of walk that line. Yeah. Contractually, we have to produce what they asked for in the contract, but I'm still going to take our model, our work to the level that we use internally.
So you know, in, in a perfect world, I would love for that to be the turnover and. It is the superior product. But but yeah, like you said, you got to walk the line for now, right for now, but it's getting better.
Hugh Seaton: [00:10:02] It is. And, and it's not like we just discovered this problem. Like it's talked about all the time and people are trying to figure it out.
I mean, this is where Design Build and IPD start to make more sense, but exactly to not get us too far off track. The next thing I wanted to ask you about is how let's say that you've gone through initial assessment of a technology. It fits something that you know your company needs at least generally.
How does your kind of pre-integration checklist work? What do you, what do you do then?
Trent Leinenbach: [00:10:32] So that kind of looks I guess I'm assuming you're talking about once we've, we've already identified the problem. We've already kind of introduced a potential solution, right? So we're kind of we're we're now the solution being the piece of tech So we're kind of analyzing it, you know, did it pass the initial... like, is it open-ended the API stuff? You know, it does it, does someone actually need it? Yeah. Well, that's right. So is it solving? I mean, but we're past that step, right? We know there's a problem because that usually is step one, you hear about a problem, but then it's my job. Well, is it really a problem because, sometimes you'll find that not all the problems that are brought up are actually real problems, but that's another topic a person's problem, you know, but so then, you know, some of the other checklist items, and I'm just kind of thinking off the top of my head, or, you know, does it, does it introduce double entry?
Does it... are we eliminating processes, improving processes? Are we creating more? That's kind of something you have to look at as well. And then the internal vetting is I have to look at that kind of like a micro use case of the problem that this tech is trying to solve and then test it.
So, I'll take an example, maybe it's a kind of one that we've been looking at recently is like a field sketch app, right. For, for guys in the field to sketch pipe, to then be procured and, and fabricated. So what I do, and what I did with that one is I sat in the office and took a bunch of older sketches that the field had produced, just ISO papers, all the ways that we used to do it from field to shop well, and still do a little bit, but, and I was like, okay, well, step one is, can I reproduce these?
Because I'm looking... I'm looking at a binder full of hundreds of examples of what this tool has to reproduce. I mean, I can't change, I can't change the process. I just have to make it easier. So that's kind of the step one, you know, does it, does it work? Can it do what I need it to do before giving the tool to the actual practitioner?
Because the second I give them that and it fails every time, 10 times in a row it's done, it's killed. I mean, you, you might as well get your money back and pack it up. So that's kind of the important part. I think Jon Marsh talks a lot about you get it to that 60% level. And then once it passes all of, all of those prerequisites and you, you push it out to the actual practitioners, that's where it kinda, that's where kind of the fun begins.
I think we could talk a little bit more on that when we talk about the continued innovation of the products.
Hugh Seaton: [00:13:11] Cool. And so let's assume that you've gone through that checklist and you've... so you figured out how it's going to fit. And this is an important point here is that software used to, when it, sometimes software used to be able to demand that people change how they, how their process works. That was certainly manufacturing did that in the nineties when, when SAP and all these, and it was brutal.
I, I was there for some of that with Sony and I wasn't a manufacturing side. It was the logistics side, but still, and yeah, it was pretty tough. Like you had to learn how to, how to type things in the right way. It was just, it was a laugh, it was a joke. Almost some of that in honestly, though, is, is what we're going through, where the utter flexibility of a piece of paper, no matter what software you use, like it won't be as flexible as paper. It also will have the 50 other things that software does at paper can't. But the point I'm making is modern software and modern workflows nobody assumes that you're going to be able to dictate how people do what they do.
It's the other way around, right? Is it you're going to have to then think about how are we integrating this software into existing processes with as little change as possible, right?
Trent Leinenbach: [00:14:15] Exactly. Yeah. I mean, we're not, like I said, we're not changing the way we operate, you know, that like that sketch app you know, you talked about like, so there's kind of an industry practice.
Your, your actual field practitioners are trained and know exactly how to illustrate what they need. Right. I mean, and I'm not my goal isn't to change the way that 2,500 union members in our city convey that information. My goal is to give them a tool to do it better, faster, cheaper, more accurate, and yeah, exactly .
Hugh Seaton: [00:14:56] Yep. And how do you guys go about like the other reason why software fails? Other than that, it's asking people to change too much. Is that like any change which, you know, using a new software, even if you've made it as seamless as possible, it's still a new thing.
Everything takes re reinforcement, and kind of ongoing support or ongoing discussion, you know what I mean? If you're asking anyone to do anything different, you know that you don't just have one meeting, it has to be an ongoing set of questions or meetings or discussions or whatever it is. Some level of accountability, but also some level of just helping people.
How do you guys go about that? I mean, I don't know if that's a question you can answer with, you know, generally, but how do you... try to
Trent Leinenbach: [00:15:43] yeah. I mean, it, it does take that continued support. It takes, it takes you to, to kind of work with them and, and keep the momentum going. So, you know, you've kind of built it.
You've at least on the internal checks up to the point when they're using it. So at that point you should, you should know that it can help the user. So that's good. Right. But now you need to help them understand how it can help them. Because, you know, they're, they're coming into this blind and it does take quite a bit of support.
But the fun part of that is, is that's when you really kind of watch that piece of tech evolve a little bit, because the one thing software companies are good at is, you know, they're good at coding software. And they're good at solving a general problem, but all us companies, we're all unique. So that's why I talk about the open-ended software, the ability to work with having that adapt to your processes.
But the real innovation comes from once it's in the hands of those practitioners. So like say you put that tech into the hands of those workers in the field. And you're supporting them and you're giving them, you're giving them the general knowledge and everything, you know, about it, to where it's at, at that point, but then where it grows and where they get excitement is they're the ones that generally find the ways to make it more efficient in the ways to improve it.
So that's why I'm always kind of talking to them and you know, as they're using it, you're kind of like, Hey, you know, you've checked in, how's it going? What do you think? And, and when they give you feedback, take it seriously. That's kind of the because if you know, if you're not working with them to improve it, then they're just going to go back. They're going to go back to the way that's comfortable. I mean, everybody's really just looking for the easiest, most comfortable path to the finish.
Hugh Seaton: [00:17:31] Right, well, they're not being... no one's being paid to adopt software or technology of any kind, right. So if it's not allowing them to do what they're really therefore better, safer, more accurately, what, whatever the adjective we use is then you know, what are they there for?
What are they using it for? So I, I think one of the, one of the good things is, although we don't always view it as good thing about construction is, for a lot of these technologies, you can tell pretty quick, whether it's useful or not. Some of them, some things do legitimately look, you got to give it a minute to understand.
So you couldn't dump someone in front of design software and you know, say it worked or it didn't, you do need to learn a little. But a lot of things are not, a lot of things you can tell pretty, pretty quick, whether it's adding value or whether the cost of learning it is too high for the value it provides.
You know what I mean? And I think. That's that's made people a little down on construction technology because it, lots of things that might have looked like they were being adopted, even though people just gave it, some gave it, you know, a little bit of runway, they don't get that runway here because people realize, you know, pretty quick, certainly within a couple of months that it does or doesn't do what they need.
Trent Leinenbach: [00:18:40] If you don't work with the user and check in on him either. I mean, yeah, you're, you're just going to find out that it's not being used.
Hugh Seaton: [00:18:46] Well, this is again, modern software. You know, you, the assumption is you're you have some kind of customer success where, you know, and there's a distinction that you made that before. That's really useful, I think. And that is nobody outside of a company can be even close to sophisticated about what's going on inside a company there's just too much, conversation. There's too much... there are too many things that people don't talk about outside of the company. And they shouldn't because it's, you know, what's their proprietary process or information or knowledge or whatever it is. So there's no way for an outside person to know everything that they would need to know to make their, their product or their, their technology as useful as it could be.
So your point, I love this is, when people are actually using it, they're going to find ways of using it that, that outset even you inside the company might not have thought of because you're not there, you know, with a tool in your hand all day, putting work in place, whereas they are.
And that's, that's really, really cool.
Trent Leinenbach: [00:19:45] Yeah. They're the ones that really should mold it. I mean, you just need to make sure that it's. That it's actually capable of achieving that end goal. I mean, which some aren't, so you have to vet that. I mean, you don't want to waste all of their time and obviously there's real money implications in testing this stuff because... We spoke with with Burcin from Oracle last night and, you know, they got the innovation lab and the kind of that mock construction project where you can test stuff like that. And yeah, I mean that would solve it. But unfortunately for us, we test this stuff on real money won/ money lost projects. So you at least have to do your diligence of kind of weeding out the ones that, that, you know, aren't gonna make it .
Hugh Seaton: [00:20:31] Totally. And that's, you know, the reality is that that as amazing and every everyone I've heard a number of people talk really positively about what what Burcin and that team at Oracle have done. But as amazing is that might be there's, there's one kind of innovation and that sort of looking out into the future and seeing how things can work together.
But again, there's the. Well, th there's a guy, actually, I mentioned to you earlier, before we started named Eric Von Hippel. And this is, this is like a couple of decades ago, but he was talking about lead users, this idea that there are people who are going to take your product and he wasn't talking about professionals so much. So there's that, there's an added a added layer when you talk about, you know, trades people using something, because they bring so much skill to it that a consumer doesn't, but still the idea is the same. And that is, people that are interested and have a reason to care about this are going to play around with it and potentially use it in ways that you didn't entirely intend.
And that, that can be the source of some amazing innovation, both as a user, but also the, you know, the technology provider itself, often will benefit from hearing from that. And that does happen. But I think one of the things that you're pointing out is, as a company who is implementing this stuff, it really pays to understand how people are problem solving and innovating in how they use the tools that you give them, because who knows what value that might take to.
Trent Leinenbach: [00:21:55] Oh, yeah. I mean, we we've unlocked all kindsof great workflows and things just, by those guys that are using it. And and as you know, the role that I have, it's very important to sit there and actually listen and take that stuff seriously. And then I would say the role of the software provider should be to listen and take what I'm saying seriously, because that's the passage of information and that's what's going to ensure the longevity of us using their product.
I mean, as guys out there giving feedback and Hey, you know, I really needed to do this. So it's now my job to facilitate that for him. And it's the software company's job to facilitate that for me. And that's the kind of relationship that that will ensure that that product stays and they'll continue to sell it to me, but if they, if they don't develop it to ease my workers, you know, days and make them more efficient and actually allow them to accomplish what they need to then I don't really have any business keeping it.
Hugh Seaton: [00:22:56] Another one of these interesting lines between two competing kind of pressures. You know, we talked before about risk for you, and for you know, a contractor. For a software company you have, it's not related, but it's similar in that it's two competing pressures.
One is, every company, you mean, like you said earlier, every company is somewhat unique either because they just made different decisions or because they've chosen to compete differently. And as a result, the requests you're going to have of a software company are going to, you know, you're going to have your own unique requirements.
A lot of them won't be, a lot of them are going to be just how the job gets done. But as a software company, you need to be making a decision about how much you're going to listen. And how much you're going, where you're going to listen. But I mean, the reality is most software companies are pretty good at listening, whether they're able to do anything about it and whether they'll invest and can manage, you know, some of the feature explosion that that might mean, like imagine you've got 50 companies that are roughly the size of North or at least the sophistication of North and all are asking for five things, right? That's that's 250 new features that you might have to think about. Right. Probably overlapping, probably not 250 totally different directions. So one of the interesting things that companies have to think about, Is how are we architecting our product so that we can be as open as possible to that kind of specialization. And you know what I see...
Trent Leinenbach: [00:24:18] That's a great point, yeah.
And
Hugh Seaton: [00:24:21] When I see it, so I had a great conversation with Ben... in fact, I published it yesterday. Anyway, I had a great conversation with Benny Baltrotsky from from M suite.
And what we talked about is one of the ways they've approached that. And that is that on the one hand, it is incredibly configurable, but they have out of the box workflows. So you don't have to learn how to configure it because the worst thing is when you know, you go try a product and you have to configure 50 things, and you're like, oh my God, I don't even know how to turn it on yet. So they balance that by having it so it works out of the box with some preset things, but as you get smarter about it, you can dig in and make your own tweaks and your own changes. And I think they started, I think they started from a mechanical contractor Modern, right?
Trent Leinenbach: [00:25:03] They did. Yeah, they did.
Hugh Seaton: [00:25:04] So they learned that stuff that's likebaked in their DNA. So I think that speaks to what you're talking about, right?
Trent Leinenbach: [00:25:09] It does exactly. And what, and what they're doing is, is a great example of how that company can position themselves to kind of satisfy what I was talking about.
And you don't, I think the more linear your software is the more trouble you're going to get into with trying to meet those excessive demands. Like you said, if, if there's 250 software change or implementation demands. I mean, they have to play triage, right? I mean, you know, if they developed something that can't, easily change direction or isn't nimble enough to allow those tweaks by the user, now they got to pick and choose through the triage, well, what are we actually going to do?
Like , and they'll probably look at some mode of, how many of each idea was voted on or something and implement for the numbers. But when you set your software up to have to make those decisions, then don't don't be too alarmed when, when I go out and find another company that will do what I ask.
Hugh Seaton: [00:26:07] You're right. And I think it speaks to, you know, you started this part of the conversation, with the idea of open-ended. And I think that you take that even further and say the architecture needs to assume that you're going to be building flexibility. And over the course of months and quarters and years, you're going to continue to make that flexibility more and more complete or more and more sophisticated. And then you're going to have the second problem, which is yeah, but what do I do for a new user? And again, the way MSuite solves that, and I think a lot of people do is you have kind of out of the box settings that, that you don't have to have a really steep learning curve to get the thing up and running. And then as you get better at it, you can, you can get smarter and smarter.
Trent Leinenbach: [00:26:48] Right. Yeah. Well, and, and leave, leave the ability for the user to do some customization and that's kind of, yeah.
Hugh Seaton: [00:26:56] That's I think that's what I mean, though, right? As you, as the user, get more and more sophisticated, you can say, okay, well, I now know I want to change this, you know, frequency or whatever, whatever the tweak is, right.
It, Trent, this has been really fun.
Before we sign off, I want to give you an, I want to talk a little bit about what you do, when you just mentioned the dorks yesterday. Let's talk for just a minute about construction dorks and when I post this, I'll make sure I have a link back to it. So talk, how frequently are you guys doing the dorks and where did it actually, where did it start from?
I love the, the, the original idea.
Trent Leinenbach: [00:27:28] So we've actually, I think we did one last night. It was a little later, like I said, cause we, we brought a Burcin from Oracle on and did a little interview. But last night was the 25th episode and our first one was may... I'm going to get this right... I think May 19th of 2020.
So it's, it's been a year. And it's it's every two weeks. We've been getting better about it being regular, but I think part of the fun of it is, is it's really informal. So it's not, it's not structured, you know, we don't, we're not upholding, to any timeframe. There's nobody who's telling us when.
And. When and who to talk to. And so, but it's kind of that open platform and that was, and it's, it's a community, right? I mean,
Hugh Seaton: [00:28:14] It's four guys who go deep. What I really like about the dorks is, is there's, you know, w like with this podcast and some others, we want to be thoughtful about how deep we go into rabbit holes and you guys are able to go as deep as you feel like.
And some of the things you talk about are fantastic.
Trent Leinenbach: [00:28:33] Yeah. Well, I appreciate that. Yeah, it's definitely a lot of fun.
Hugh Seaton: [00:28:36] Cool. Well Trent, thanks for being on the podcast.
Trent Leinenbach: [00:28:40] Yeah. Thank you.