Human in the Lead: Building a Better Data Strategy with ARKANCE

What happens to project data after turnover, and how much of its value gets lost along the way?

ARKANCE’s Tobias Scheele and Nick Miller join DBIA’s Director of Virtual Design and Construction, Brian Skripac, for a conversation about making project information more useful from design and construction through operations. They discuss where information tends to break down, how teams can improve continuity without prescribing specific tools and why automation works best when it supports human expertise rather than attempts to replace it.

This is the first of two episodes from the conversation. Part 2, coming at the end of the month, turns to AI, digital twins and the questions organizations should ask before investing in new technology.

GUESTS:

Tobias Scheele
Executive Vice President, Americas, ARKANCE

Nick Miller
Director of BIM Services, ARKANCE

Brian Skripac, CM-BIM, CDT, LEED AP, DBIA
Director of Virtual Design and Construction, DBIA

Catch Part 2 of this conversation, "Bird by Bird: Tackling Data Strategy One Step at a Time with ARKANCE," out now!

Access all our free design-build resources and learn more about Design-Build Done Right® at dbia.org.

DBIA members are shaping the future, one successful collaboration at a time. 

Transcript

Copy Transcript Copied

august 2026 part 1

Fri, Aug 14, 2026 12:56PM • 32:36

SUMMARY KEYWORDS

Data strategy, project lifecycle, AI, digital twins, design-build, data management, project execution, automation, common data environment, information flow, project delivery, data quality, human ingenuity, project outcomes, technology investment.

SPEAKERS

Brian Skripac, Erin Looney, Nick Miller, Speaker 1, Tobias Scheele

Erin Looney  00:07

Welcome to the Design Build Delivers podcast, brought to you by Archons, an Autodesk Platinum partner. I am your host, Aaron Looney, and speaking of Archons, two of our guests this month are part of the Archons team. The other one is Brian, who's back because he technically never left. Someone get this man a cot for the studio, please. This month, though, we are doing something just a little bit different. My conversation with Archon's Tobias, Sheila, and Nick Miller, along with Brian Skripak, DBIA's director of virtual design and construction, covered so much useful ground. It was just too much for a single episode, so you're going to get a twofer here in August. In part one, we are looking at the foundation, how organizations can build a better data strategy, create continuity across the project lifecycle, turn project information into something people can actually use, and take all of this forward through design and construction long after delivery into future projects, then at the end of the month, we're going to return with part two focused on AI, digital twins, and the decisions organizations should make before investing in any new technology. So we hear terms in the industry like data strategy, AI, automation, etc. ad nauseum. That just sounded like gibberish. But I want to start a step earlier than that today because I suspect a lot of people might say, "All right, cute robot and all, cute drones, nice plans, nice tools. But what is any of this actually supposed to help us do? And we're going to start with you, Tobias, to give us a leadership point of view. What business problems are AEC leaders trying to solve through better data strategy?

Tobias Scheele  01:44

Thanks, Erin, for the for the nice tee off. But when you're looking into into the business, and when you're looking what what do really AEC leaders are looking on? So there's a couple of items. So first, business is not going away. Everybody these days talking about what are you doing with your data? As you say, what's happening with drones? What's happening with AI? All these items, and sometimes when you're turning up the news, you're wondering what is this world coming to an end, or where will this all go? The fact is, people need a roof on top of their heads. We need infrastructure. We need buildings. We need hospitals. Yes, of course, we need data centers as well. That's the business AEC is supporting on what they are doing. So they need to execute projects. They need to bid for projects. They need to win projects. They need to execute projects. They need to make this as flawless as possible. They need to do this for the best available cost for their customers, and they need to do it in a way that's sustainable for them, so to stay in business. Hence, all what we are seeing right now, at the end of the day, brings it down into how can you execute most efficient projects. How can you do it in a way which makes you staying competitive, which is appealing for the customer? At the end of the day, to be honest, some of those projects you just want to look them beautiful. So, because I'm still engineer, I like to watch construction sites. I love to see buildings or big infrastructure projects when they are starting from a pile of dirt, big hole, and then there it is. Wonderful building, a wonderful bridge. These engineering marvels. We have to get back into what is this? So, how does it does it feel for people, and how do you make it again most efficient? Because there are 1000s of people working on this. The whole industry is hundreds of 1000s of people, and they're all asking the same question. So, what am I doing better with it? We're already in.

Erin Looney  03:35

I'm glad you think we teed it up really nicely because we're going to have a good conversation about some of the more specific pieces of what you were just talking about, and so now we're going to talk to you, Nick. Let's bring what Tobias said to the project level and talk about what core data management actually looks like in real life.

Nick Miller  03:52

As I thought about this topic, I felt like there was a lot of different symptoms that I could talk about here. I think in reality, what it looks like is it's a team of people that are disconnected from the next person in the business life cycle, and their kind of only goal is to meet whatever contractual obligation is on their piece of paper, regardless of how it impacts the next person downstream in the business life cycle. So that's kind of at a high level what we see happen in reality. Again, at the at the individual level, it's people working from different versions of the current set, right? It's people answering or submitting RFIs that maybe were answered in a submittal that was submitted weeks ago. It's a field team working off a printed set of plans that does not actually match what is the most current set of pieces of paper. As crazy as that sounds, that's still a common issue today. And really, what we see is when people are not comfortable with the data strategy or the communication plan, they start to develop their own shadow system. Now they're managing an Excel file and some files on their desktop that represent what they think is the current set, and it just creates this compounding area. Of potential information loss that creates rework and schedule slips, and suddenly we're fixing a problem on a project site that should have been addressed in a clash detection meeting months ago, and we missed it because the person who was in charge of submitting that model was not on time with their model submission. So how it manifests, where it presents itself, I think it's in reality it's different for every client based on the issue. Sometimes it's just the PM on the job site spending hours looking for a piece of information. It can be very very simple in terms of how that manifests itself. It becomes problematic, and people are spending lots of time in soft cost things that they just don't even realize are potentially consuming and sucking up the labor on the project holistically,

Brian Skripac  05:41

I think one of the things that you said there, Nick, was interesting. Right, you talked about people really looking out for their own individual deliverables and not thinking about the next person in the project cycle, and that's a big opportunity for design-build teams to really mitigate that approach. Right now, you're breaking down those contractual barriers, you're planning a team approach from the outset where you can define what that next person you know what that next person needs down the road. You can plan for how that information is going to get from point A to point B and to point C. Whether that's design information going to the trade partner, design information going to the builder, or it ultimately getting downstream to the owner, and being able to have a structure and a framework in place to know how data is going to be formatted, structured, named, organized, whatever it is. Now it has much more of a fluidity throughout the project life cycle, and not just being here's my set of contract documents, go bid it and build it kind of approach. So, I think that's a huge opportunity. That it's also an opportunity by having all those partners at the table at the outset on a design build team to really say, all right, how are we going to do this? How are we going to approach this? This is what we need. Who's going to contribute to this? Where is it going to live, and how is it going to be shared?

Nick Miller  07:06

Yeah, it takes an immense amount of planning for a design team to use a piece of content that meets the facility operations requirements 18 months from now. Like you have to have a thought process there, and that connective tissue is really where we see the greatest advances in project execution and data exchange.

Erin Looney  07:23

Quick follow up: If somebody were to look for the top two or three symptoms that things might be getting out of hand, and you're headed down a path to poor data management and absolute chaos, what would those three symptoms be?

Tobias Scheele  07:39

When I'm looking from an executive perspective on it, the first thing is you're losing control. So that means you're losing control on the schedule. You're losing control on the cost. When you're looking at this one, this is extremely important. When you're executing, I'm talking about small projects. So when you're whatever upgrading your garage, so that should go smooth, but when you're going into the bigger ones, so the bigger infrastructure projects or the bigger building projects, here it is really highly important that from the beginning on you do have a right plan, you do have a right structure and architecture to handle data across all the disciplines and across all the elements of the life cycle of a project, and then even getting into the point where you have hundreds or even more 1000s of subcontracting elements working. How do you keep this all together? If you don't have, I would say, a good plan at the beginning, a good architecture at the beginning, maybe all looks fine at the beginning, but later on, when you're going into more executions, more and more difficult to get an overview on it. That's what you, as an executive, want. Where am I? Where am I against budget? Where am I against schedule? And what are the elements which are on a critical path? So because they have all ripple effects, and then God's sake, if someone in the middle of the project finds out there is something which isn't as right or right planned. I need to go back two steps. What is the ripple effect here? And I'm sure everybody has these horrendous stories when construction sites coming to an end, and then everybody is wondering, okay, what are the spare parts doing here? Or even worse, something is completely missing in the building, so something isn't where it should be, and then try to fix that. And you want to avoid this. The first item that really goes down is data. So when we're talking data, and here it is. What's the plan? But again, this is from a high level. I'm sure Nick, you have hilarious stories about how this looks like in reality.

Nick Miller  09:39

Yeah, we definitely have seen all kinds of worst-case scenarios in terms of how you can execute a project. For sure, I think sometimes it looks a little bit like complacency going through the motions. We're having the meetings, but we don't really feel like anyone is holding people accountable to the objectives, the directives, and the things that are coming out of those meetings. So it's like we're having the pulse checks, but we're not actually seeing action against the items that we're addressing. That's one area that we see things kind of can really spiral out of control. Another one is like we talked about: it's a lack of democratized information. People are kind of hearing through the chain of communication what's supposed to be happening, when the new drawings are coming, what that latest update might entail, and it's not really a directed communication from a central authority on the project that's pushing the initiative forward. It becomes this kind of hearsay, and then people begin filling in details with either the worst case scenario or the best case scenario, depending on how they're performing on the job to that point. And then fundamentally, it creates this massive kind of shift between what's happening and what's expecting to be happen on the project.

Brian Skripac  10:44

You talked about the democratization of information. I think when you look at a good data strategy and digital delivery, what's in between that is: Are you leveraging a common data environment? Right? Is there a level of accessibility to the information on the project by everybody. To your point, Nick, to be able to expand on that, and is there a level of transparency and communication that can occur so people aren't well, hey, you're only going to hear what you need to know in this meeting that you're at, but there might be something else going on in the project or seeing things that are going on. That accessibility and transparency, I think, are really key, and that builds trust on teams, just like we talk about at DBIA all the time. And that's where you have the opportunity to better execute and deliver on projects with that whole team approach.

Erin Looney  11:31

Brian, let's stay with that for a few minutes. Our sorcerer supreme of VDC, who has been sleeping in the studio since mid July, for anybody wondering where he's been can't get him off the show. He just keeps coming back. We are happy to have you back again. We're always happy to have you. You mentioned a connection there to design build and to DBIA, and obviously that's where most of our listeners are expecting these conversations to go. So let's stay there for a few minutes. Let's talk about how better data can support collaboration that is key, integral to design build.

Brian Skripac  12:03

One of the big things, if we go back, having this whole team approach at the start of the project. One of the things that we talk about in other documents that we've released, whether it's the VDC primer or I think even more relevant is the VDC project leader's roles and responsibilities. Right, having somebody embedded in the project who is going to maybe a good word is translate the needs of the projects into that digital delivery, data management, data structure terms that are going to allow all these people to execute on the project goals might not be a an upfront conversation that always happens, but is certainly one that needs to occur, and being able to see that transition of all that information from concept through construction to turnover is really a key element. And having that role on a project, I think, is a big opportunity for design-build teams because you're not starting over at those transitions like you would be in a traditional project delivery mode, where the team is producing their deliverables, and then it stops and gets passed off, right? You may not know what was the what was the reason behind that data structure, the naming conventions, the content development that was there. Now you just pick it up and look at it and say, I don't even know what to do with this. There's not a continuity that can occur, and I think that's a real value for design-build teams and how they work.

Erin Looney  13:26

So going back to you for a second, Nick, because Brian brought this back up. We've talked before about actually specifically last month's design-build delivers episode about the value of data beyond a single project, and I think there's more to this than what we talked about there and what we've briefly touched on here. So let's start with you, Nick, and then we'll go to you, Tobias, and talk about how project data lives beyond the delivery of a project.

Nick Miller  13:55

Yeah, absolutely. Getting a project completed and paid for is the first step in what is actually a 30-60-year life cycle of a building, and I think understanding how the team who will support that building operation, what information they need, and how they intend to operate that facility is super important. It is definitely something that lives well beyond the project life cycle that you're talking about, and informs decisions and cost structures and planning efforts over the life cycle of that entire facility. So I think that's one component that becomes really valuable. I think the other piece there is the lessons learned from a specific project and being able to take that to the next one. If I'm building $100 million building and I can do it for $95 million next time. That's a tremendous savings, and anything that I can learn to help drive that cost of build down year over year, project over project, becomes a tremendous value for my organization, and it creates an opportunity for us to take the assets, the tools, the less. Learned the data handoffs, all those pieces to the puzzle that we just talked about that help orchestrate a good project lifecycle. It allows me to create a more cohesive strategy and ensure that we don't fall victim to the same pitfalls over and over again in terms of data reusage and data lifecycle management.

Tobias Scheele  15:16

When I picked this up from again the executive view, there are two elements into it. One is the ecosystem who designs and builds the asset. So for them, again, we've talked about the benefits of being data centric and having the different disciplines working on the same data set, the same language, the same items. But then as well when we're going back, who's the receiving end of it? So the one who paid the bill to get the nice building. Then what did you get in the past? It's always good to have it in the back, so because it's not like this is for the first time done. You got pounds, if at all, of paper or even tons of papers, and usually a couple of weeks later, all what is written there, or a lot of it, is obsolete because changes are happening, or people actually have forgotten where it is. And if, for those who always or have been in their life in operations or maintenance, it's actually quite difficult to find information about existing assets. And I'm not talking about old ones; I'm even talking about new ones. And even if you have it electronically, you need at the beginning. This all goes back into what do you actually want to achieve. You need to have a plan what you're doing with this. Otherwise, you've got a nice database. What are you doing with it? Who's doing with it? What? So, and just having it doesn't doesn't do the thing. So you need to have a plan behind it. But then it comes to to Nick's point. If you're in the business of building big warehouses, you want to learn from it. Of course, everything is specific. It's depending what's the underground, what's the environment you're picking it, with whom do you deal. But there are definitely learnings, similar like an operator. If you're once at a time, the first time you're in such a business, you want to talk to someone who's done this more often, can give you some advice here. For those of you who have like like the 20s of that project, you have some expectations as well. And so, how to get scale effects? So, how do I have if I'm 10 of those assets who are quite similar operating? What can I learn from it? So, how can I bundle those activities? So, but this all goes back into again, what is my strategy? What's my plan here? If my plan is just to get a bunch of concrete on the ground and windows on top of it, then maybe you need to have a different conversation.

Erin Looney  17:30

The Design Build Delivers podcast is brought to you by Archons, your technology optimization partner, helping design build teams streamline workflows with Autodesk solutions, expert support, and real-world training. Ready to work smarter and faster? Get tools, insights, and schedule your AI readiness check at archons.us/dbia. This has come up throughout this entire conversation, and most of the conversations I have with with professionals that information goes through a lot of hands over the life of project. Talk about where where does that flow most often break down between design, construction, turnover, operations, all of those hands, and anyone can take this.

Nick Miller  18:17

It's at the exchange to the next user, like we just talked about, and what happens typically is every handoff becomes a re-entry point. What did we talk about? What are we trying to accomplish? What is the purpose of this data? And unfortunately, when you're designing something against a deadline, your ability to get all of your design intent to document it is not always possible, right? And that creates some gaps in understanding that can be problematic, or potentially you're on the job site, you're building the building and capturing what you actually did versus the you know construction documentation is not always followed through and it doesn't always get documented. I think that's where we see a lot of the breakoffs. It's that connective tissue that ensures the next team has what they need. That's really where that design-build approach, I think, bridges a huge gap in the market today, and kind of eliminates the-it's not perfect, certainly-but it eliminates a lot of the break points that can happen in a project lifecycle because it's simply it's the next person's problem, right? And unfortunately, with the pace at which construction is executed and the kind of circumstances at which they expect to get the return on their value and investment. Sometimes that doesn't allow the current user to create the most perfect data set to hand off to the next user, right? And I think that's one of the problems that we continuously see in construction in a traditional capacity.

Tobias Scheele  19:36

When I'm broadening this up a little bit, up to the point when you are in the let's say planning, costing, scheduling, construction, and then like in a cycling here, you definitely have breaking lines where you're using different tools. So you definitely have breaking lines when you need to work with different departments, and even on. Of different tools, you can argue for all those items you should have a process in place. So you have this well documented, everything is done. What can data centricity bring to you? There is a nice quotation I always like: Every plan falls apart when hit with reality. So, and here reality, as Nick has said, there is a project schedule. There's always, always a problem. There's always, always someone who comes in and want to have a little extra. And this is very in particular when you are on large projects. So hence, sure you have a process to deal with that. But all those items add up. These are entry points for mistakes. So these are entry points for quality problems, and they do pile up. So it brings it back to to the point: Do you want to have one master tool, one master data lake? Who could have it? Yeah, sure. Does it exist? No. So will it exist anytime soon? I well live in California, but I'm not that dreamy. So at the end of the day, it comes down again to the point: what is your strategy? How to deal with data? So how do you want to provide data consistency between the different departments, and then absolutely identify where are the breaking lines? So to next point, out of your experience by default. Where do those breaking lines happen? Where do you want to have automation? Where do you want to take out the human, and where do you need to have the human? Because that's where they add value, which is the design, or which is the construction, which is the planning. I mean, someone who has done hundreds of projects has a feeling for what's feasible. So, how do you capture that knowledge and tools, processes, and then automation. You can even go down to the point as soon as the next one is touching the tool or getting the drawing, and forget all the items where people make hand annotations to the drawings. So try to get them back. So,

Brian Skripac  21:54

I agree with both of those points. It's the gaps and the transitions, whether it's project team members or technology-that's where it always occurs, and that is a major challenge in traditional delivery models. Not to beat a dead horse in saying this, right? But when you have that team there up front and you can strategize for how you're going to move from point A to point B, it's a big opportunity, right? Everybody has their own corporate standards, and if you take 10 different corporate standards and try to put them together at the last minute after one party's done and it has to go to the next party, it's just not going to work. And you know, I think that's the opportunity to look at a project-based scenario rather than Tobias's firm, Nick's firm, Brian's firm, Aaron's firm. All right, well, we'll figure out when I have to give it to you. We'll figure out how you're going to use it. It's continuity plan that is really the opportunity there, and you can mitigate the size of those gaps and have much more productive team.

Nick Miller  22:54

As one of my good friends, who's a developer, says, the best thing about standards is that everyone has their own right.

Brian Skripac  22:59

That's the problem you're fighting against. As

Tobias Scheele  23:02

long as you use my one, I'm good. So, but that's a

Erin Looney  23:06

great segue to the next question because talking about standards and everybody has their own. This is something we see with tools and platforms as well. There are lots and lots of them out there, and no matter what field, what industry you're in, there is a suite of stuff that does the one thing you need it to do, and so when you go into projects working with different owners and different teams, everybody might know what information they need. They might know what they've used before, but they might not know or even really want to dictate what exactly those tools are or shouldn't dictate it. So when you run into that, how do you define the needs, the information, the what it is you're looking for without prescribing a specific tool or platform?

Brian Skripac  23:53

When you you talk about trying to connect all these things, it really is back to the owner, and it's the owner defining standards, and that can get a little confusing and muddy when you say owner defining standards. And I think the best practice is there is to define what needs to be delivered and how it needs to be structured or formatted, not telling the project team how they are going to develop that content, what tools they are going to use, and I think those are two different parts of the conversation, and really something that needs to be focused on. So, what are the deliverables? How are they going to be structured and formatted? Not that you'll use this particular solution or technology or software to derive that information. You can use whatever you want, but at the end of the day, I need this information, and this is how I need it to come from you, so I can directly integrate it into my asset management system, so I can use it throughout the life cycle, like Tobias was talking about earlier.

Tobias Scheele  24:52

And you have two extremes, like usual in business. One extreme is highly prescriptive, as you said. Rightly, the owner operators is exactly what they want. So I want to have a building a certain way, a bridge, whatever. Let's call it an asset. Who is doing the following? And here is exactly the specification. And there are items which are non-negotiable, like building codes. In these items, I'm not talking about that. So I'm talking about what they can prescribe in exactly the way. And these are the tools you have to use, or the amount of tools, and this is the format how you have to deliver this to me. You could argue there's a lot of front of work. There's advantages here, and there's as well advantages for the involved companies, architecture, design, construction companies, because they know what they're getting here. But that takes away as well as maybe certain secret sauce they have. Then you have the other extreme. The owner operator says, "I actually don't care. I just need the asset. Who's doing the following? So, for example, so many hotel beds or so many hospital beds, or have a street connecting A to B. Please follow the building code or the city code. That's it. Gives a huge amount of freedom for everybody is involved, but then you're getting to the point you hope everybody speaks the same language. So, because that can be a highly interesting approach when you're going to finishing and things do not go as expected. What is the ownership of this? So, as usually these items, best way is somewhere in between. I'm sure everybody has has stories about one of those extremes they have seen and why they believe they have their advantages and disadvantages. So, in my view, what we are seeing, you need to have them. It's always to be of advantage to have an owner operator who is understanding what they want, but they need to work collaborative together with the involved ecosystem to make sure that this fits what their skills are.

Nick Miller  26:52

Yeah, like I mentioned earlier, it it takes a lot of planning for a design team to put data into a design model that will actually facilitate a business outcome for the facility's operations manager 2436 months from now, but I think that's really where owners have a strong opportunity. And one of the most radical things I've seen recently is owners taking payment milestones and not tying them to delivery of building assets, but actually data quality of the asset that they're delivering. So really ensuring that the info they need to drive the process they're talking about is a part of that delivery engagement, and then the payment milestone is associated with that quality assessment. And that really gives them a little bit more control over ensuring that the information they're getting meets their requirements regardless of the technology it's potentially coming from,

Brian Skripac  27:43

and that's a great opportunity for automation, right? You just plug that in, and it goes. Can you imagine if a human had to go through and look at every line of a spreadsheet of data to see if it was the right structure, the right format, had the right naming conventions? No, you can do that immediately and turn it back over and have that QA QC so that is ready to go when the owner receives

Tobias Scheele  28:06

it. Yeah, yeah. This is not just the cost you are adding by doing this manually or the cost you are taking out. It's as well the quality, because I mean, whenever you have these human intervention, you will have, in particular, for for those tasks. So I mean, you cannot be concentrated for eight hours in a row on this. So you will make mistakes. So which means your whole QAQC is even getting more loaded on those items. This is a great example. So and it's great to see as well when you're looking on how do you put this into into motion by combining it with payment milestones, you can really see it shifts the quality or shifts the conversation and the maturity of the ecosystem in the industry, and from going from in the past just asset, then asset and documentation, and now just like asset documentation, but in a certain way, digital and with a certain quality, not at the end, because at the end we all know people run away, and then you have difficulties to find them.

Erin Looney  29:07

Just to make sure everybody listening understands, we were not just advocating for replacing all humans with automation. Just Brian says you can automate that. Tobias says you can automate that. What you hit on, Tobias, actually is really important, and that's allowing the humans working on these projects a little more space to do something other than try to spend eight hours digging into tedium. It really opens the door for more innovation and more focus on project outcomes. So, anybody wondering, we do like the machines, but not in place of the human being.

Speaker 1  29:43

No,

Erin Looney  29:43

an entirely different delivery method.

Brian Skripac  29:45

Yeah, I mean, it's what's the what's the highest value opportunity to leverage that designer, that engineer, that architect, engineer, builder, right? It is not checking boxes all the way down of how many 1000s of lines of spreadsheet data, right? There's more rational thinking, decision, experiential outcomes that come from the experiences that they have. That that particular QAQC thing that Nick mentioned is perfect for automation.

Nick Miller  30:12

And we're we're shifting our thinking from even human in the loop to human in the lead. We think that's a better phrasing to say like they're driving a process opposed to being connected to it and informed, so I think there's a layer of accountability that still is present and very important with the human approach, even when automation is being leveraged holistically.

Brian Skripac  30:32

The computer hasn't been sued yet; the professional has.

Tobias Scheele  30:36

Yeah, and bringing it to the point, where does human ingenuity and creativity and thoroughness really brings the added value. So this is really, and this is again when you want to have a conversation with someone why they did certain things or how do they executing it. And this this is where the value is coming in, not in checking the lines on the spreadsheet. Don't get me wrong; it needs to be done. But you want to free the resources of a really high value-added person and the experience they bring. And even if they are new, so the experience they will bring, the creativity they had to the driving seat. Where do they add more value?

Erin Looney  31:18

Once again, for the back of the room, no one here is advocating for replacing humans, so don't get any ideas out there. So keep the human, not just in the room. Keep the human in the lead. Better data, smarter automation. Sure, those can move design-build projects along more smoothly and set up future projects for success. But as Tobias stressed, it goes back to strategy. And do you know who creates the best strategy: human beings. But that's where we'll leave part one of this conversation. And thanks, as always, for listening. And of course, thanks to our guests Tobias Sheila and Nick Miller of Archons, and DBIA's Brian Skripak, who I promise we will be Brian free after the next episode, just for a little while. We do tend to miss him over time, but as with any good thing, you know, we can have too much of it sometimes, right? Part two comes out at the end of the month, where we'll pick up with AI, digital twins, and the questions organizations need to ask before putting money and time into new technology, like whether they have the data strategy and the culture that they need to make that investment worthwhile. The Design Build Delivers podcast is brought to you by Archons, an Autodesk Platinum partner. Learn more at archons.us/dbia.