Should Your Firm Build Custom Tools?

BILL ALLEN: All right. I think it's 8 o'clock, so we'll probably jump in there and get started. Thanks, everybody, for making it early morning. Hopefully breakfast was good and flight was good, all of that.

So today we're going to be talking about Should Your Firm Build Custom Tools? And I brought some people up here that are a lot smarter and more well-versed and qualified to talk about the topic than I am. So we have a great panel here. I'm going to let them actually introduce themselves if that's OK. First one is--

RUTH PARR: Oh hi.

BILL ALLEN: Ruth. So Ruth, do you want to give--

RUTH PARR: This is my first mic check as well. Hi, I'm Ruth Parr. I'm with LS3P. I'm Digital Practice Manager. I forget what I wrote on there. Probably was not as professional as what everyone else will say. But I'm an architect by training. I've been in the technology BIM realm for the last five to seven years. And yeah, I'm out of Greenville, South Carolina.

BILL ALLEN: Thanks, Ruth. Next, we'll go Dustin.

DUSTIN SCHAFER: Oh wow. We're out of order. I'm Dustin, Chief Technical Officer at Henderson Engineers.

BILL ALLEN: Dustin?

DUSTIN SCHAFER: Yep.

BILL ALLEN: Luther?

LUTHER LAMPKIN: Yes. I'm Luther Lampkin I'm RG Construction Director of Technology in engineering.

JOSE GALINDO: Hey. Good morning, everybody. I'm Jose Galindo, VP of Digital Practice with Huckabee out of Texas.

JOSEPH BERTUCCI: Good morning, everyone-- oh my gosh. Joseph Bertucci. Also, my badge says BIMtucci, so formerly known as Bertucci. I am a BIM Design Manager at Amazon. I have a large experience in commercial-themed entertainment background and excited to be here-- ready for my closeup here, so it's really bright.

BILL ALLEN: But yeah, put on the glasses for the lights, that's good. So all right. So I don't know if you guys noticed, but for the panel, what we want to try to do is get a good cross-section of different industry. So we have construction represented, architecture, manufacturing.

And so there's a lot of different skills up here. People with a lot of experience in both working with building tools internally as well as externally. Some of them have software devs in-house, some of them out-house, and a hybridization of both of those.

And so I have some pre-positioned questions for the group. But of course, I'm sure all of you guys are here for this class maybe for yourselves. And so we will open it up for questions for you, too. So if there's questions that you guys might have, we'll get through our list, and then I'll open it up to you guys, and then you're welcome to ask some questions and we'll let the panel answer those.

A little bit about me. So my name's Bill Allen. I'm the President for EvolveLAB. EvolveLAB, basically we build custom tools, and a lot of tools we built have been for these guys, but they also have hired other people as well. So hopefully you get some other representation beyond just ourselves.

But we're really excited to be working with these guys and doing some really amazing things. There's some serious talent on this panel and some really great culture. And so that's just a little bit about me and about EvolveLAB.

So I want to-- we'll go ahead and kick it off here and ask the first question, which is, why did you choose to develop custom tools at your firm? Was it to gain a competitive edge? Was it to streamline your process? Or other? And maybe we can do a popcorn or we can go down. If someone has no comment, that's OK.

RUTH PARR: I think we all have comments.

BILL ALLEN: Everyone has-- I love it.

RUTH PARR: --the questions ahead of time.

BILL ALLEN: That's right. So yeah. Ruth, maybe we'll start with you. Why did you guys at LS3P decide to build a custom tool? Was it to solve a problem? Was it to try to get an edge? To streamline a process? What was the reason?

RUTH PARR: Yes.

BILL ALLEN: Yes, all of the above.

RUTH PARR: Yeah, so for LS3P, we're Southeastern US. We have 11 office locations. And I think a lot of what we're working on is building consistency across our BIM, across our deliverables, across our project workflows. And one of the things that we're trying to do, especially with our app development, is lighten the load of our project teams.

And so we're trying to identify those things that aren't adding value to our projects to encode that with any type of automation or tool-building so that our teams can focus on the more creative, nuanced aspects of architecture. And so yeah, streamlining our process is probably the key answer from your question that I'd go with for that.

BILL ALLEN: Thanks, Ruth, that's great. Jose?

JOSE GALINDO: I think we started with some similar goals as you did. I know when we first engaged with you guys, that was one of our goals, was really trying to streamline what we were doing. But ultimately I think it was trying to gain a competitive edge for us being a regional architect in Texas specializing in K through 12.

Our projects, I think like everybody else's, is extremely fast-paced. And really, we were struggling a lot with how to get client buy-in early on a project, get them to stick to the things that they actually said they wanted. And so we didn't really find any tools on the market that could really help us with that.

And so as we revamped our whole frontend charrette process, that's what we were looking for, was tools that could help us to really get client buy-in and streamline the pipeline from the decisions they make to our production process.

BILL ALLEN: OK.

JOSEPH BERTUCCI: A good answer.

BILL ALLEN: That was a good answer, I like it.

JOSEPH BERTUCCI: Same thing on our end. I mean, I think the biggest thing is also to streamline our process. That's probably the big thing we're trying to do. And at the same time, having a competitive edge. So the reality is that the tools aren't being built enough that we're trying to solve. So we're trying to build them ourselves or seeking people that can do it.

Because we're just trying to have answers now and not having to wait for them to be built. And we're on the-- our industry is on the verge of innovation and we just keep trying to push that and push that. So having that edge and moving that needle in the right direction.

And as much as we would love to wait for the tool to come out, we just need to get it developed now at the end of the day to streamline our process. Deliverables aren't changing. It's how fast we're producing them.

BILL ALLEN: It's interesting how similar your guys' answers were, is that there wasn't a tool that already existed in the marketplace, but we have this idea or thought that we need built. We're not going to just wait for something, we're going to go ahead and build it ourselves.

JOSEPH BERTUCCI: Correct.

BILL ALLEN: Luther?

LUTHER LAMPKIN: I probably say fill in the gaps. For my job working with a drywall contractor, there's a lot of tools that weren't as developed, so we reached out to Bill at EvolveLAB and constantly built our own tools just to make sure that all the components that we were looking to do and customize that weren't there from the different softwares, which won't-- I think a lot of the times won't ever be there.

I think that 75% will be there and then the other 25%, it's our job to collaborate with other people like Bill, EvolveLAB, and other technology integrators to be able to fill in all the different gaps that you need, just like you were saying before, that a lot of the stuff isn't built and our clients demand great service. And I think it will be an injustice if we didn't evolve and learn faster and reach out to our network to build what we need to build now instead of later.

BILL ALLEN: Thank you, Luther. Dustin?

DUSTIN SCHAFER: A long answer. I got a long answer, not Luther. So the short version is that they don't exist on the market because they can't. Because the tools that are built for the market require you to adapt your business to their tools.

So if you go to collect data or have a specific way that you work, none of that can happen because they have to make them generically enough to apply to everybody. So our problem was we couldn't apply machine learning algorithms to the tools because they just didn't do that. So we wanted to apply ML, we wanted to collect data, and we wanted to track user clicks, so we could do both of those things, collect data and then apply ML to it, and just couldn't do that.

And it's because the data is structured in such a way that it's specific to your company and they can't do that generically and then tie into your system very well, so people just don't do that. So to us, it was step one in a part of a long plan, and efficiency, I hope, comes with that, but the real gain is down the road when we can tie it into our whole data architecture. Is that me making that noise?

BILL ALLEN: A little bit. Yeah, your microphone--

RUTH PARR: Lost your mic.

DUSTIN SCHAFER: I lost my mic.

RUTH PARR: You knew that was going to happen.

DUSTIN SCHAFER: Cool answer.

JOSEPH BERTUCCI: Yeah, but I think he had a good point.

BILL ALLEN: Mic drop.

DUSTIN SCHAFER: Yeah. Mic drop.

JOSEPH BERTUCCI: Yeah, he had a good point in regards to a lot of the tools out there are just built to build towards a broader audience.

And as-- from an owner's end or from a consultant's end, we're trying to adapt those tools-- so our workflow versus the reverse is really what we want. We want to be pioneering our tools to be built towards our workflows instead of having to adapt them and always trying to do this entire work-around procedure in order to get to the result we want.

So pursuing the custom built tools route always becomes an added competitive edge for our industry because it streamlines our process more versus taking a tool that's more for a broader audience.

LUTHER LAMPKIN: Yeah, to piggyback on that, I think the biggest thing is that if we can't turn our data into information, then that's the part where we're starting to try to adapt more and more because we have a lot of data, but is it information? I think that translation is where we're trying to get better and better at.

BILL ALLEN: Mm-hmm. Yeah. Good comment. You guys-- Dustin, you brought up a good point, and Joe and Luther as well.

Having your own kind of data source and these tools that don't accommodate those and having to work with that process and that standardization, do you think if the industry had some shared data source, whether it's IFC or some kind of other standard format, it would help with that process? Or do you feel like that's just not possible in our industry?

DUSTIN SCHAFER: Yeah, it would help a lot. So right now, like what we're struggling through is-- like nothing against any of the Autodesk products, but one of the options is to just structure data from PDFs because that's what everybody does to normalize their final answer, is print it to a PDF and put it in a table or put square footages on things, and that seems like really lame.

Like if it was in a structured database and then you print to a piece of paper, basically, and then structure it back. But the point is that you get a solid consistent answer from everybody that way. So it'd be super helpful if there was a structured data format that people followed that you could count on and it wasn't different each time you got to a different project.

BILL ALLEN: Yeah.

LUTHER LAMPKIN: I mean, I think we've tried it with the IFC format. We've just struggled along a lot of the ways. I think the biggest thing that, going forward, if we focus a lot more on the end goal first, mainly facility management, and work backwards, I think we would actually accomplish our goals more as opposed to doing these data drops all the way through a project and we always had that data loss towards the end of the project.

BILL ALLEN: Yeah. I like your comment of like starting at the end and then working backwards. What's your end goal? Where is it going? It's good. I had some other questions on that, but I'll try to keep it on topic. I have questions about KOVI and other things. But I'll try to keep it within the theme here.

So are there major problems your firm is trying to solve with custom tools? How would you categorize this problems? Is it disconnected data, which I think-- Dustin, you were just talking about productivity challenges. Luther, you were talking about earlier labor shortages, et cetera. What kind of problems is your guys' firm trying to solve and how would you categorize those problems?

RUTH PARR: I think there-- I think there are a long list of reasons we do this. I think that doing more with less as always-- that's an easy one. Everybody wants more out of less work. And also using as much of the computer to do the manual work as possible.

I think another bigger concept is the idea of our aging architectural knowledge-- or, I mean, not architectural-- I use that a lot. The knowledge that's encaptured and people who are going to retire in the next five years.

And I think some of our tool development is intended to try to capture and codify some of that so that we can pass it-- so that we can do it consistently across our projects and also pass on that information to future teams even if the person isn't still working at the firm.

BILL ALLEN: Yeah. That's a really good point.

JOSE GALINDO: A wonderful transition over to us, because I think our big focus is really on how can we co-author with that data? So capturing the inherent and latent information in our firm, getting that structured, and then having a way to actually use it actively in the design process and not have to go find it and try to suss it out, but actually just have it be there visible at the forefront of the design process was really our goal.

BILL ALLEN: --Jose.

JOSEPH BERTUCCI: Yeah. I mean, ours is pretty much everything we've already stated, which is disconnect the data. We have data sources also in multiple different locations trying to tie all the information together while also improving productivity.

I always push back on some of our leadership principles, which are-- and one of the big ones is not only being customer-obsessed with our workflows, but also inventing and simplifying what we're trying to do as well. So it's all in this streamline effort of trying to automate this process more and more and more, and we're trying to do that with not only the staff we have on-hand, but also seeking whatever we need to improve that automation process as well.

LUTHER LAMPKIN: I think for us, we want to tackle three things. One, we want to tackle the fact that drywall framing wasn't a part of coordination. So just to get that in a broader spectrum, especially early on in design.

The second and third would be incorporating IPD process and the Lean process and how does that really tie into BIM? Because that's more of basically a design build as opposed to design bid build. And how are we going to structure ourselves for that type of delivery system?

And obviously we reached out to you to further that avenue which has been a great success so far incorporating those aspects of it. But really, really finding out and understanding, how does that lean forward to those processes in BIM and how does that make you more efficient?

DUSTIN SCHAFER: Yeah, I touched on it before. The biggest hurdle was that we found the generative design tools to be pretty restrictive, so we wanted to be able to run standard algorithms to optimize design. And then keeping track of the data and integrating it into the overall stack of all the other software was really difficult.

And the other thing I forgot to mention is that you can't build your own UI if you're using somebody else's tools, and if you have multiple tools, they have multiple user interfaces. And so being able to tie all those together into one user interface is much better.

BILL ALLEN: Yeah.

DUSTIN SCHAFER: Eventually.

BILL ALLEN: Good comment. I'm curious, too, maybe for Jose and Dustin, you guys both talked about co-authorship with design tools. And sorry I didn't preface this question beforehand, but I've been really intrigued with this idea of co-authorship with tools and how you can make that more intuitive.

What are you guys doing, as much as you can talk about it, with co-authorship? What does co-authorship mean to you? How is it different than maybe what's being marketed? Yeah, what do you think about co-authorship and is it a pragmatic process or more practical than what it is? So I'm going to ask about seven questions, maybe one.

JOSE GALINDO: Maybe? We don't know yet. I think it's something that we're currently exploring actively, is-- and I don't have a good answer of is it really possible to co-author a design with design data? Because we haven't really found that magic recipe yet. We're really trying to answer the question.

I think it's a very common experience, or at least for me. I go sit in a charrette and I watch a designer rehash the same basic principles that they just did a few weeks before on another project. And I think that there are certain moments in the project where either data is being dropped from the process or we're repeating things for no real purpose. It's just, this is what we've always done.

And yet, we still end up coming out of the charrette off-program, building's too big, it's overbudget, it's just-- it's too much. And how can we actively give people feedback, bring some ideas, maybe perhaps of gamification into the charrette process where people are actively starting to see-- and not just our designers, but the clients themselves, too, the big user groups that we put together, how can they see the impact downstream of their decision?

To me, it sounds like a really promising avenue to explore. And our tool that we've started working on has helped us, and I've seen some glimpses of where people move a space from one side of the building to the other or change the size of it and they realize the implication of that to their budget instantly as opposed to us coming back later and telling them, well, that's going to cost you this, and they don't quite get it because it's just talk.

That graphical-- speaking to what you're talking about, too, I think being able to build the graphics of the application to reinforce key messages is something that we just can't do unless we custom develop.

BILL ALLEN: A good answer.

DUSTIN SCHAFER: Yeah.

BILL ALLEN: Dustin?

DUSTIN SCHAFER: Yeah, so I feel like-- we feel like that humans are good at making decisions and computers are good at ranking things against lots of different factors-- like lots of parameters. So I guess as a person, I can generally rank against one or maybe two things. Like I could optimize for cost or I could optimize for the way it looks or whatever. And as you gain more experience, you gain more parameters in their ability to do that.

But computer could rank generative design options against lots of things-- 20 or 30 things with different weightings. And then a person can look at the top 10 and decide what's best. And that last step is really, really hard to program. But it's natural for a person, once they see the force-ranked options, they can look at them and be like, oh, that's that one.

And so to me, co-authoring is that blend of ranking things-- generating a bunch of options, ranking them, and then letting a human make the final decision based on their experience, I think that's where the power sits. So there's art in figuring out the equations to generate, and then there's art in making the last decision, and then in between it's not super artful, so you don't need a person to do that.

LUTHER LAMPKIN: One of the things I would like to-- that we wanted to do, we wanted to actually track trending, trending analysis with the models. And because we are a drywall contractor, we have the ability to actually go into the models and actually make sure that our model is more complete because we want to start talking more about usable data. It doesn't just mean data, but usable data.

So we're able to tie in in preconstruction models that we get iteratively, and we were tracking the Power BI and put a cost goal to it. So every time there was a change graphically, we would see the money go up and down based on the different decisions that they were making in real-time. And that affected the customer's decision-making in preconstruction as long going through the IPD process.

BILL ALLEN: Fascinating. Thanks.

DUSTIN SCHAFER: We had a question over there a while ago. If you wanna--

BILL ALLEN: Was there a question? I think we were doing questions at the end, but we can take one. Go ahead.

AUDIENCE: [INAUDIBLE]

BILL ALLEN: Yeah.

AUDIENCE: [INAUDIBLE]

BILL ALLEN: Good question. I'll repeat it for the recording. That's a good question. So the question was, what kind of tools are you guys building? Is it something that sits inside of Revit or another Autodesk tool? Is it a standalone application? Web-based? Can you talk maybe about the use case? Anything that you guys can share about the tools that you guys are building.

RUTH PARR: I'll go first. We've worked with EvolveLAB and a few other developers on Revit add-ins inside the Revit interface. And we've had a couple that have a web interface as well.

BILL ALLEN: That's good. Thanks, Ruth.

JOSE GALINDO: So ours is a web application that exports into Revit.

JOSEPH BERTUCCI: We utilize the Revit API and we do build the custom tools. So we do a lot of data extraction, but using tools such as Power BI to be able to measure things for adoption while we build these other custom-built, I guess, applications utilizing like Reference API and then cloud-hosted applications like BIM 360 trying to extract data from that as well.

LUTHER LAMPKIN: So for us, we use-- early on we used Revit add-ins that extract information. We put that into Assemble, and then we take that information and we draft that into our Power BI dashboard from our preconstruction standpoint.

And then towards the end of the project, we're starting to do more of web-based applications, and we use EvolveLAB for that. They take that data and manipulate it in certain aspects and how does that tie and also to a graphical database that we can represent to the client.

DUSTIN SCHAFER: Ours was a Revit add-in. And Daniel can correct me if I'm wrong, I think it's C# that we wrote it in or is it C++?

AUDIENCE: C#.

DUSTIN SCHAFER: C#? So yeah, wrote C#, used a Revit add-in to did all the calculations outside of Revit, and then pushed the answer into Revit as families.

BILL ALLEN: A good question, though, thank you. We have some more context. I like it. Yeah?

AUDIENCE: [INAUDIBLE]

BILL ALLEN: Yep. So I'll repeat the question again. So the question is, you guys mentioned Revit quite a bit and Revit add ins. Did you guys start with Dynamo maybe as a proof of concept or something as the first step? Or did you just go straight into creating a custom application?

RUTH PARR: I can answer that. So for us, we've had a couple Dynamo attempts, proof of concept, and then we'll usually work with the EvolveLAB team to codify it into a customized user interface and work with the Revit add-in specifically. Yeah.

JOSE GALINDO: So our proof of concept, as it were, was working in Dynamo. The proof to leadership was, can we develop scripts that are actively used in Dynamo across our team, deploy them, measure that they're actively used, and not have the editing of those Dynamo scripts just live with one employee? They need it to be maintainable over time.

And we basically proved out that we as a team could develop something akin to software-- Dynamo isn't that, but we could develop something ourselves in-house, support it, and get it implemented. And then that really built the case for me to go ask for, hey, I want to engage with people like EvolveLAB to develop something more robust that could do more for us. So we use Dynamo as our way to get our feet wet as a firm.

JOSEPH BERTUCCI: That's a good way of looking at it. Similar effort, we're using scripting tools like-- or visual programming tools like Dynamo or Grasshopper to really create what I would refer is like the underlying skeleton or framework that we're trying to achieve. I like Bill's thought process. It's really the start of a proof of concept.

But it's not-- the key thing is on the scalability sense. Like that's great for like a project-by-project application, but if you're looking from a scalability effort, that becomes almost like a recipe that we start looking at like a built-in tool that can help scale that process on a much-- on larger-sized projects or also multiple different projects in the process.

LUTHER LAMPKIN: So the short answer for me would be yes, that we did build a Dynamo script. But the biggest thing that we look to do is just make sure that all of our shared parameters could go into different databases, because at the end of the day, Revit is just a large database that we want to extract information in, but you've gotta have good data in to extract good data out.

And so we were looking to figure out how can we do that? But yeah, we did use Dynamo at first, and then we went and got EvolveLAB to be more of a technology integrator, which I would actually recommend for everyone to really do that, because the tools are only going to get you 75% there.

DUSTIN SCHAFER: Yeah. Ours-- so it is a really good question for our workflow because our tool we designed with them was laying out ductwork, modular ductwork. And in Dynamo, we had to write the equation for how the ductwork should get laid out. You couldn't use any optimization algorithms to test a bunch of options and then rank them on length or whatever.

So we'd only get so far, and like a person writing an equation in Dynamo isn't going to be very effective. Honestly, you can't come up with a very optimized layout, so we had to go beyond that to get the optimization that we needed.

RUTH PARR: I just want to follow up a little bit. There are a couple of the tools we've worked with that we did have that Dynamo proof of concept, but then there are some also that we've worked with you on that we just didn't think were possible, so we asked your team. Like can Microsoft talk to Revit? Or can view titles move before Revit 2022? So there are some things that we had no proof of concept and it was just a Hail Mary to see if you could do it for us.

BILL ALLEN: Yeah. Shout-out to Daniel in the front row on our team. There's been quite a few times when something is not available via the Revit API, and then Daniel will come in and be like, oh yeah, here it is. And we're like, wait a second, How did you do this? And he's like oh, I just used a recursive algorithm. And I was like, oh yeah, recursive algorithm. Why didn't I think about that?

DUSTIN SCHAFER: Yeah, we all know what this is.

BILL ALLEN: It's just like-- there's just really ways we can sidestep some of that. And to Dustin's point like some things just aren't available, but there's ways you can round-trip that and find other ways to get it. OK. And I want to get to other questions, too, here, so I'm going to keep going through mine.

Do you have in-house software engineers on staff? Do you see an advantage to hiring an outside design technology company versus developing tools internally? I know some of you guys have developers in-house, sometimes you've gone outside. Can you talk about the makeup of your firm?

RUTH PARR: Sure. We're growing our internal coding computational design team. So we're very early in that process. We do have a full stack developer on the technology team, though a lot of efforts are focused in IT and finance. And I think he drew his first wall in Revit like last February or something.

So what we looked for in working with an external partner was somebody who could encode that had that architectural or like the industry knowledge of how we wanted to do things and the understanding of the workflow to then streamline that process. And so that's something that we looked for with our external partners.

JOSE GALINDO: We've done some internal training, but we don't have a full stack developer or any development staff. I was really sensitive, like I mentioned earlier, to the fact that I didn't want to have a person that was going to be leading development in-house and then have that person leave and all of a sudden we're left with dead software that we don't know what to do with.

And so finding an outside partner that we could continuously work with, build a relationship with was probably one of the main priorities for me in finding that so that we could maintain this long-term and continue development.

JOSEPH BERTUCCI: Yeah. The short answer's-- so we do have in-house staff engineers that are able to develop our own scripting and tools as well. And we do look at developing tools externally. We have a design technology team that supports parametrics and being able to lead some of those automation efforts.

But it always starts from our end whether we go internally or externally, which is-- it always goes back to the ROI. Return on Investment. It really starts with the problem statement and what exactly are we trying to solve? If we can't justify the ROI, we need to revisit the problem statement.

And then we need to look at and we have-- we know we have developers in-house. Do we have the bandwidth though to support the development to solve that problem? And then the key thing is the time frame, which not a lot of people look at.

It's always technically going to be quicker if you have the bandwidth to develop something internally versus trying to outsource it. You're trying to look for an external developer, you always look towards vendors that you can trust, that can align with your goals and solve your problems.

But if you need something within like four weeks, I'm probably not going to an external vendor to develop it because the whole RFP process, contracts, everything, you're still looking at-- you're still weeks, months away before you actually get something to solve the problem you're trying to get.

So it's really the ROI justifying it and the internal bandwidth to support it, and if you don't have it, what's the time frame in order to do it? And then that really pivots on, can we do it in-house versus getting a vendor to help us support it?

Normally if would we-- we love, going back to I think the scripting route, we have something as a recipe that helps guide our vendors to say, hey, we've created what we think is the underlying framework we want to do, how do we scale this better?

LUTHER LAMPKIN: For me, anything that's short-term. That's what I would tackle for my coding background. But anything that, for me, I'm looking to solve problems that aren't problems yet. And so that's when I'm reaching out to Bill and trying to figure out what solutions that we can come up with before they even become problems. So it's just short-term versus long-term, and as you weigh those options, you'll make the best decision.

DUSTIN SCHAFER: We have seven software developers-- so we have 1,000 employees total and seven software developers just to give you an idea of scale. And about three years of backlog, probably, on those seven developers.

So we could flex to either if it's something that we want to integrate in with the rest of our tools, we build it in-house, and this was a unique problem that we needed to solve, so we went out out-of-house to help get the expertise to solve that problem.

BILL ALLEN: Would you recommend other firms create their own custom tools within their firm? Why or why not?

DUSTIN SCHAFER: Can I go first?

BILL ALLEN: Yeah.

DUSTIN SCHAFER: Yeah. You will have to do this.

BILL ALLEN: Yeah.

DUSTIN SCHAFER: I think it's at some point, you have to figure out how to do it. So I say it a lot to our company, but I think-- like the IP we're developing is tying together all these external tools in a way that is unique to our company, because everybody has access to the same general software. But how you tie it together and how you integrate things and how you build stuff on top of it as your IP as a company.

And so I'm an engineer, I'm a mechanical engineer, and I'd say pretty consistently in our company that software developers are the future of our company. Like we have to be good at engineering, but we have to integrate that in with what they're doing. I don't see any other way to get it done.

BILL ALLEN: I'm going to go this way this time. Luther, you want to go?

LUTHER LAMPKIN: Yeah. My motto is, if you're not cheating, you're not trying. So any advantage that you can gain from a competitive standpoint, I suggest that you highly do that. You figure out what's unique to your company, how you can-- how you can utilize that to best brand yourself so you won't put yourself in a box.

I mean, we're a drywall contractor, and a lot of times I get people asking me, are we a drywall contractor or a technology company? So you want to make sure that you start to leverage all those aspects as you move forward so you don't put yourself in a box, but you definitely should have custom things that you are going to do within your house that stands out from the rest of the crowd.

JOSEPH BERTUCCI: Yeah, I think every firm in some way or another has some-- or should have some form of a built-in-- custom-built tools-- or workflows, I think, is a better way of looking at it. And not everything is going to have a custom-built tool, but knowing exactly-- I always go back to what I said previously, which is, what is the problem you're trying to solve? Every firm is different.

Some might need an auto-documentation tool, for example. We need an automated drawing set within a certain period of time versus how long it would normally take. Versus some might need like a CAD or Revit translation pretty simple to automate that process.

So it's really knowing exactly what you're trying to solve, but normally it's involving a-- most likely going to be either a custom-built script or tool plugin that will help automate that process because you start to see the value saying, we're trying to--

We can't wait for the tools sometimes to be developed. We have to create those workflows, have our internal developers be able to do it or be able to outsource it to a third-party engineer to be able to provide a tool for our specific workflow.

And it does make us unique. It makes us to say we have that competitive edge that Luther and Dustin were explaining. So yeah, I think it's important that firms start to explore that and looking at the problem statements of what they're trying to do and then scale on top of that.

JOSE GALINDO: Yes to all of that. And I think just to offer a different point. The way I look at this question, I mean, this has to become part of your craft. It isn't the technology and then the rest of the business. Technology is part of the business. And if you aren't trying to develop tools to do what you do best, you're going to fall behind. And the sooner you can start, the better off you're going to be as with anything else.

For us, if we're not challenging-- continuously challenging the way that we're working, we know we're falling behind our competition. I mean, it's a pretty obvious statement, but it's the reality. And that was part of what we were really trying to do here, is we need to start-- are we going to be a technology company?

No, we're an architecture firm. But we know that it's going to be a component of our firm moving forward just like BIM and VIZ and all the other constellation of services that we offer as a firm, technology is going to become part of that.

Do we want to be leading that or do we want to just wait for everybody else to do it and then follow in their footsteps? And we made the decision to lead.

RUTH PARR: I think yes to everything everyone else has said. And one thing that comes up a lot for us is that there are a lot of right ways to do things. And when you're working in a larger firm setting, that consistency is key both for what goes into the file-- consistency is key.

And getting our tools and our workflows streamlined so that our teams are doing more with less. They're not doing as many manual clicks. We're doing a lot of functional-based tools. That then embeds the data, that then we can have easier, better insights from.

It's-- yeah. I think the fact that there are a lot of-- there are many right ways to do things, and building these tools helps us choose the best right way for our firm, for our project teams that we want to see that feeds data upstream for our larger firm insights and innovation.

LUTHER LAMPKIN: And Bill, I want to say one thing, too. Always-- I will always challenge, every time I brought some innovation, who's going to pay for it?

So in that case, when you think about building tools, don't just think about what's going to solve a problem sometimes just internally, but also, there are a lot of great people who may have the same issues. So we've gotten our tools sometimes and given those tools out for other people to use, too. And to the ecosystem-- so it goes both ways.

And also, too, when you're bringing these innovations, companies-- even when we're on IPD projects, they don't mind if you're bringing innovation that's going to help the project and charge for it.

And so we've gotta be able to balance both. So we're not just our head in the sand and saying, hey, I've got this cool tool, but you're always going to come back to cost-- cost, cost, cost. But if you balance those things out, I think it'll work out on both favors.

BILL ALLEN: --comment, Luther, thanks. I'll just interject real quick just for a moment. So like we do some crowdsourcing, too. So some firms will pay for certain features and other firms will pay for other features. So that's another way to bridge that gap. So maybe you're not on the hook for like the entire ticket for some applications depending if it's 100% internal tool versus a hybridization of something like that.

I want to get to audience questions. So I'm actually going to let-- I'm going to do one last question and then I'm going to open it up for questions to the audience. And so last one. What challenges did you run into when creating your custom tools? Any lessons learned you would share with the audience? Anything you would do differently?

JOSEPH BERTUCCI: I go back to my schedule comment. Like knowing-- I think it's understanding and budgeting how long it actually sometimes takes, and that's really the justification between how we're doing things internally and how we're doing things externally. And we've learned that quite frequently.

And I think from my end, I mean, I'm always big on trying to do things as much internally as a cost savings, but knowing that when I see a scalability factor, we may not be able to support that bandwidth internally and we might need that support externally and try to budget for that as much as possible.

But knowing the time constraint. So if I'm looking for a solution for a problem, I'm knowing exactly how long I want to actually turn that around by. So we look at quarterly goals that we're trying to hit.

BILL ALLEN: I don't know which way to go now because we were in the middle.

JOSEPH BERTUCCI: I had to start differently. I had to shake it up.

RUTH PARR: Yeah, yeah.

BILL ALLEN: Luther and Jose, you guys can arm wrestle or rock, paper, scissors.

JOSE GALINDO: I think teeing off was something you were saying a minute ago, actually, my favorite I-word now is impact. I'm tracking impact across what we do because that's the best way that I've been able to work with my CFO, is really not looking at traditional ROI, it's highlighting the impact that the tools we're building are actually making on people and our clients, and making a more illustrative view for him and for the rest of the firm of what we're doing.

But I think also, one of my biggest lessons learned was, you think your people until you start to try to develop a tool for them. And then when you start doing that, you realize you really didn't know as much about how they worked that you thought. There's so much variability across the firm. And how do you capture all of those different nuances of how people are wanting to work and how they're working and try to bring it into one tool? It's not easy.

And so becoming an anthropologist of sorts and really getting out, getting into projects, I started getting into charrettes again and working in charrettes. I hadn't done that since I was an intern. And just trying to really get back into the work to understand at a deeper level what we were trying to do because you don't want to get six months into developing a tool and find out, oh, S-H-I-T, this isn't exactly what we need to be doing. So yeah.