Building Trust in an Industry That’s Actively Avoiding It

DAVID JOSLIN: I'd like to welcome everyone out to our panel discussion. This is Building Trust in an Industry That's Actively Avoiding It. So hopefully, you're in the right place. We've got some good discussion topics and then we're also going to keep a mic ready for any questions from the audience as we go about the discussion. So feel free to raise your hand, ask questions, and we'll try to keep this-- we'll try to keep it somewhat interactive.

So I'm going to flash that up there. One of our panelists is from Autodesk, so don't buy anything based on what he says.

MAN: I insisted this was put up there.

DAVID JOSLIN: I'm Dave Joslin. So I am the applied technology manager from Gilbane Building Company. I work out of the Phoenix office. So a little drier than what people might be used to out here. And my role really is supporting the Virtual Design and Construction group and making sure that we have the software tools we need, they understand how to use things. I'm there to help fix things when they're broken. And I came up through that group, helping project teams succeed and solve issues.

So we'll go through our group, give everyone a chance to give a little introduction to themselves and their background. So we'll start off with Bob.

ROBERT YORI: Did you do this on purpose? I just noticed that we're all aligned in the same way. That's great.

DAVID JOSLIN: Totally planned.

ROBERT YORI: Excellent. Well done. Hi, everybody. I'm Robert Yori. I'm a digital solutions studio leader in New York City for AECOM. Our studio, I like to characterize us as playing in two domains. We play in project-oriented domains, so in the BIM and VDC space, in computational design. Then we also play in the product space, which is application development, UI/UX, front and back end development, and data analytics.

My background-- I'll give you the very brief version-- architecture, into technology, into physical product, into sustainability, into UI, into technology and civil engineering, and now I'm here. I hope that wasn't too long.

GEOFF CAMP: Hi. Good afternoon, I'm Geoff Camp with Suffolk. Just a little background about myself. A little over 15 years in the construction industry. It was a second career for me. My educational background is actually in architecture, but I've never practiced or been on the design side.

So I came up, similar to David. I came up through a VDC role. Probably the majority of my career was project assignments, being on site and working with teams. I really love that role because you're kind of a generalist on the projects. I think if you do these processes and use some of these technologies properly, everyone's engaged in it and you're a facilitator and information manager, rather than a more of a-- you're less of a technical person.

In my current role as director of process innovation, I'm really responsible for-- the analogy I use is like a quarterbacks coach. Like, we empower our project teams and our core people, like project managers and superintendents, to implement some of these tools and processes. So I'm there to guide them through that, to connect them to resources, and just empower them. So I touch a lot more of the projects on a broader basis now.

ANDREW MAYO-SMITH: Awesome. Andrew Mayo-Smith, so as mentioned before, I work for Autodesk. I've been with Autodesk for about eight years. Currently in a sales role, although I've worn a couple of different hats since joining. I was in Customer Success. And then I was a technical support specialist, always servicing construction accounts at an Enterprise level.

Before Autodesk, I worked for a general contractor in the greater Boston area. They actually did all of New England. And before that I was doing some facilities management work. And before that was engineering school.

DAVID JOSLIN: Cool. All right. Thanks guys. So to get us started off, the good old tell you what we're going to talk about thing. So we're going to break this into three major chunks.

Like, what is trust? What does it mean to us, to each person? What are the things that help or hinder and some of the challenges we might encounter? And then, what are some of the ways that we can try to build that and strengthen project teams? With the overarching goal, why are we talking about trust today?

And I like to use this rowboat example here. This was during the Olympics a few years back. And the British team got a little bit off. And they nearly collided with the Italian team, if I'm remembering this correctly. And it came down to they got out of sync.

So the idea here is that for the projects that we work on, to have the most success, to work the most smoothly, we need to trust each other. We need to be working together. Everyone's got to be rowing the same direction. So that's the impetus for this discussion today.

And so the first thing I want to launch off to the group is, what does trust mean to you? And why is it important in what each of you are doing? So--

ROBERT YORI: You're looking at me.

DAVID JOSLIN: Start off with Bob.

ROBERT YORI: Yeah, sure. So, thanks. I think about trust in a few different ways. I can think about trust among entity-- well, among people or the larger extension, by entities, by stakeholders in a project, whether that be discipline oriented or some other arrangement.

I can also think-- in some of our conversations, we came up with the idea of trust in data and how much you can trust the information that you're receiving. Those are two aspects to that. I think there are other dimensions to it, but I think, fundamentally, that's it boils down to, at least in my experience, with trust and with lack thereof, about whether you have faith in the team, in order to be able to hand things off seamlessly, or the information that you are receiving and the validity of it.

GEOFF CAMP: I think the people in the audience should know, in preparing for this session, we met. Some of us hadn't met before. We decided to come together to talk about this. So I think that personal aspect of relationships and just having communication and interaction with people is so important.

I wanted to share a quote. As we were thinking about this, I was looking up quotes about trust. And I like this one. It says, "Trust dies, but mistrust blossoms." And that's from Sophocles, who was an ancient Greek playwright. And when I thought about this, I know a much more elegant way to say that, which is "One oh, crap, erases all the atta-boys." And that was told to me by a superintendent.

The idea there is that there's a fragility to it, that the earning of trust and how we build up that reservoir, it's difficult to do and you have to do it over time. And it's very easy to break that down. So I hope we can talk today about-- throughout my career there's some just small interactions, things you do with people. Like, I'm going to talk about even things as simple as where people are positioned. In a space where you're working together says things. And so I think there are some things we can do to really encourage that type of relationship building. And that's the foundation of trust.

ANDREW MAYO-SMITH: Yeah, when I was thinking about it, I likened trust to-- for those of you who've played on a team sport, there's a sense of-- you can feel momentum when things are going one way or the other. And it's sort of similar with trust. I think of it in a similar way, where it's difficult to quantify or pinpoint exactly when you feel like you have that trust, but there's this sort of underlying energy between a group of people when trust is there, versus you certainly notice when it's not.

GEOFF CAMP: Right.

ROBERT YORI: It's that level of collective ownership, rather than feeling of the need for a singular type of ownership, whether you're talking about an individual, again, or a particular team, or discipline, or so forth.

ANDREW MAYO-SMITH: But it's particularly complicated in an industry like AEC--

GEOFF CAMP: Oh, yeah.

ANDREW MAYO-SMITH: --where you have a team working together on an individual objective, but there are your different stakeholders. And everyone wants to end up in a good space individually, but you also think about-- it's hard to find another industry like it, where it's so collaborative, but you're not really all with the same jersey.

GEOFF CAMP: You often very specifically have very different obligations, very different roles and responsibilities, even if collectively there's a shared goal.

DAVID JOSLIN: Cool. All right. So Bob, you kind of touched on this earlier, the idea of trust in different things. So going into this, when I started the concept, and before we started having our discussions, the main thing I was thinking about, that trust between people. But one of the things that's come up in our discussion was also the different facets of trust. Right?

ROBERT YORI: Right.

DAVID JOSLIN: Whether that might be between people and companies, trust in the process that you're using, or the tools, or the data that's been generated from those. So kind of building on that, what are some experiences you guys have had in relation to those different facets of trust, either where you might have run into some challenges with that or benefits from those?

ANDREW MAYO-SMITH: We see it all the time with technology implementation. If you go in and the group just refuses to buy into that the idea that it might improve their way of doing things, they're just kind of pushing a rope. So establishing that belief that what you're going to do could make it better. And that's from a technology perspective, not that it's unique, necessarily, to architecture, engineering, or construction. But when it comes to software implementation, we definitely see that a lot.

GEOFF CAMP: I think we talked about, before today, a little bit, sometimes, the software solutions are set up for a worst-case scenario too. Like you have to control and restrict. And I think where our conversation got a little interesting is like, how can we create spaces where people can be more open with their information, without changing the risk profile or the responsibility, while also maintain those fail safes? So whether it's inadvertent or malicious, that you don't have disruption to the

ANDREW MAYO-SMITH: Right. Yeah, thought a lot about permissions-- from a technology perspective, you can probably get a pretty good sense of the trust dynamic if you just went into the permission settings to see what people are capable of doing, and seeing, and moving around, and stuff.

GEOFF CAMP: Right.

ROBERT YORI: I can give an example that doesn't even touch on technology. Let's say as an architect, you get a set of existing conditions drawings. Let's say they're hand-drawn. Let's just completely take technology out of the picture. I've never been instructed to utilize existing conditions drawings that were prepared by somebody else. Because once you do that, you assume ownership of any mistakes, rather than going out and verifying it yourself.

So I think there's an element of risk control that's associated with trust or lack thereof. And I think this might be jumping to another one of your questions, but-- is it?

DAVID JOSLIN: Go ahead.

ROBERT YORI: But we also came around to this idea of agreements, contracts as proxy for trust between individuals or entities. So I think the example that I gave is if you work in a small town and you do single family residential architecture, you might have a relationship with a few of the builders in the area. And you're probably a little more casual with that working relationship than you might be if you're working, let's say, in New York City, and you're doing 60-story office towers, and you've got people bidding competitively for them.

Because you've developed a working relationship in the first scenario, and you have developed a level of trust. But if you work with a lot of strangers, you haven't had the opportunity to build that trust.

GEOFF CAMP: Accumulate your atta-boys.

ROBERT YORI: Right, you can't accumulate the atta-boys on the first try. So agreements themselves are a proxy for trust, at least in the beginning.

GEOFF CAMP: Do you think they should-- a contract should actually enable a complete absence of trust because it's so prescriptive and specific about who's responsible for what, even going into the methods for interaction between the different people? It's almost like you maybe could have zero trust. I don't think anyone would want to work on-- be involved in a team that functioned that way, but theoretically, maybe you could.

ROBERT YORI: I think those documents are-- and I don't say this pejoratively-- I think those documents are written with the expectation of no trust. Because oftentimes, you'll see agreements written for worst-case scenarios, So they sort of embody this distrust.

I guess, to put it a nicer way, which I really mean it this way very clearly lay out expectations and deliverables. S that's there's no ambiguity in what's expected of individuals or organizations and their roles in a particular project. If you have a good working relationship, as I said, let's say, maybe with a residential builder in your hometown that you're working with, you don't need to lay everything out so specifically. In some cases, it's more of a waste of time than anything else.

DAVID JOSLIN: Yeah, that balance between the roles and responsibilities has already been established or it has to be written--

ROBERT YORI: Yeah, through experience.

GEOFF CAMP: And to your point, I think, we're often-- people would probably choose to work with or interact with their preferred team, or the individuals and entities that they have been successful with. But obviously we don't always have that choice.

DAVID JOSLIN: This is not how it works.

GEOFF CAMP: I'm a little bit of an optimist, where I think-- I was thinking about this and I don't think we come into a new business relationship, especially in like in AEC, like a project environment, I think there's some level of trust, even if it's an entity we haven't worked with. It might be low, but I don't think we come in at zero either, which is a starting point.

ROBERT YORI: No. Absolutely. I think we kind of came around to this-- to borrow a phrase, trust, but verify. So how does that how does that fit in current context? What does trust, but verify mean in the technology space that we all currently occupy? We've observed, perhaps, some opportunities to maybe make the verify part a little bit more robust, rather than just trust.

So I think that that's something that's in the back of my mind, how can we orient the tools that we use to encourage trust by providing a-- I think it was you that mentioned the safety net.

GEOFF CAMP: Yeah.

ROBERT YORI: Yeah. Yeah.

GEOFF CAMP: Right, free, and enable the collaboration, but reduce the risk or manage that, so that people don't-- there's not that gun shy, kind of sheepishness about sharing information. And we talked a little bit too, it's about respecting. I think like I had an experience early in my career, where almost being-- seeing behind the curtain, it can be misused, even if it's not-- it's not done intentionally. But it can be disruptive. Like respecting each other's roles on the process, respecting the design process.

So I think when those things are open to you, you have to-- it's what you do with that information too, that greatly impacts the trust and the relationship.

ROBERT YORI: Sure.

ANDREW MAYO-SMITH: I think the technology-- technology's role in this whole conversation about-- in industry and what trust looks like changed a lot once cloud collaboration became the norm. So groups were always collaborating. They just looked a little different. Now, to your point, with cloud collaboration taking place, the collaboration is accelerated and it's a lot more documented.

So from an Autodesk perspective, when people were just working alone on Revit, and then you might share that model with somebody, now it's just so much more rapid, and there's so many more stakeholders, I think--

GEOFF CAMP: Fluid.

ANDREW MAYO-SMITH: Yeah, much more fluid. So the cloud shift I think has changed technology's role in the whole trust conversation within the industry.

ROBERT YORI: That reminds me of when I first started teaching Revit, you get to the part about work sharing. And especially in the early days of Revit, people just didn't register what that meant. So you're sort of noodling around.

Or just an example outside of AEC, does anybody remember the first time they got on like a Google Doc or a Google spreadsheet with somebody? And everybody just thought they were doing their own thing. And it was just utter chaos, because everybody was just doing everything all at once. At least Revit has some protections in there to people-- to keep the same 10 people from editing the one thing. But yeah, it was chaos.

I think about us in-- so the group that I-- these got, of course, the BIM, and the VDC side, and the software development side, and I take a look at parallels in software development itself. So when we spin up a software project, we'll have a code base, which is in like GitHub or something.

And there's a pretty well thought out idea about individual contributors, what they do, developing modularly, forking off a branch, scheduling the merge back into the main code based, testing it before that ever goes to production, forking that in. And then also, these different layers of applications. Assuming they're web hosted, you've got a staging site, you've got a dev site, and then you've got a production site.

So the production site is live. That's what the end user sees. But you've got the dev site, which is the really messy one, which is kind of like the rawest version of your merged code. And then the testing one, of course, is to comb through those and comb through the knots. And then finally, it gets promoted to a production site.

So I think about that a lot. Especially in the larger VEC projects that I've worked on. The model isn't so much the exploration space, as much as it is a record of the decisions that have been agreed upon. And I think what could help trust is, perhaps, a more granularly organized system, or at least the possibility of a granularly organized system that maybe parallels in some ways the software development methodologies, that allows for those different layers and levels of vetting before it gets committed to the production model.

ANDREW MAYO-SMITH: I just found out that Bob knows more about software development than me, for sure.

DAVID JOSLIN: I do want to take a break here because I know we've got at least one question from the audience. And we've got a mic that we'll bring up here in a second.

ROBERT YORI: You shouldn't have interrupted me. I could have segued until the mic came up.

GEOFF CAMP: It looks like it's--

DAVID JOSLIN: Yeah, so you've got the gentleman on the end there. And then--

ROBERT YORI: I think you might have to turn it on there.

AUDIENCE: It's on.

AUDIENCE: Test.

DAVID JOSLIN: There we go.

AUDIENCE: So I come from an architecture standpoint, like Geoff, I guess. Now I'm in construction. But some of the biggest challenges with trust, I think, is the way the contracts have been written for the last, I don't know, 100 years. Because we've been specialized. But now, that it's starting to go into Design Build, I think because owners are starting to see that architects don't have all the information and input, because they're not experts, nor should you expect them to be because they don't work in the field.

So I think a lot of that trust is that we expect 100% CDs. Owners expect it. They paid for it. They believe their-- the city checked it, so it got permitted. Why wouldn't it be trusted? But the problem is, the reality shows that the drawings are not 100% accurate. They're actually very flawed in the real world.

And trying to change that is difficult. Contracts have to be completely reevaluated. And building those relationships with Design Build subs is another thing that owners have to-- and contractors have to vet out. But I think that that's one of the biggest challenges, is explaining that and getting the owners to see the value in Design Build, versus going out to bid. That's the challenge, I think, that we are-- in the industry, that we're facing. And I think that technology is that bridge builder, where we can actually do it and make it work.

And another thing that I also see, to add to that, is even in the field, it feels like they're not being heard, when we have all this technology that's being inundated at us. And the challenge I see is that we have veterans and experienced veterans in the field being told that they should do it this way by people that just graduated college. So it's almost like an insult. Like, why are you telling me how to install and do it this way when you have no experience? So I just wanted to hear your guys' feedback on that.

ANDREW MAYO-SMITH: I've certainly heard we've been building buildings long before this existed, in terms of the technology.

GEOFF CAMP: Yeah, I think you have to have trust and credibility within your own teams. To your point, you can't-- I don't think you're going to-- you're not going to have success with a new technology implementation if you're going out to someone who's had success with the methodology that they've used.

This is a delicate thing to say. I don't always think that the bar should be as low as we've always done it this way. But I think you have to recognize that person's perspective and you have to come at it from a position of-- you have to build credibility and show solutions.

I was going to say, the contracts, like Design Build, I've been involved with a couple where I think we've actually had like less trust in those than-- or I should say, I've had better experiences where there it felt like there was more trust and more collaboration just in a traditional contracting structure, with the architect to the owner and us to the owner.

But yeah, I think it's a fair point, that we need to look at how those things, the contract structure enables us to collaborate at the right time and that people are resourced with the right-- the right ability to do the right thing at that point in the job. So it's a valid point.

ROBERT YORI: I think that that's where agreements-- I think that's where they're really useful. Because they do-- they are that proxy for trust. So you've had better experiences in some design to build than let's say, Design Build. So maybe it's because of the combination of people.

There are some other dynamics there, clearly. Lots of factors, right? So I think that there's ample reason for the reason agreements exist the way that they do. I think also there's, perhaps-- and I can say this from an architectural standpoint-- one of the reasons that the industry is the way that it is because it would be cost prohibitive to build any building if we were to fully simulate everything down to the n-th degree before it went out.

You take a look at a site, what do you do? I don't know, five, 10 test borings? You're just kind of like picking spots. What if you run into some subsurface condition in the spot that might have been the 11th one? And how many of them do you do? So there is an element of guesswork in that.

And if put together properly, I think there's a real distinction-- well, I'll put it this way. I think that when we talk about making building models there's always a tendency, a good one, to refer to manufacturing and sort of this precision level development. I think that there are-- and there are good lessons to be learned there, but I think the way that architectural projects are described is fundamentally different than how they're described for a product production.

So I used to work for a company that made curtain wall anchors. And we must have made, I don't know, a million of them a year. So I can spend the time amortizing the refinement over those million that I built. And I know this is an old argument, but there's an element of guesswork in the one-off, the design to realization.

And I think this is where trust comes in. Because the architect, of course, is responsible and has experience in a certain set of things, but not others. And this level of trust-- to trust your engineers, to trust your construction professionals, to know that they know a lot of things better than I did as an architect, and to be able to work collaboratively, trustfully, in a way that enhances everyone's expertise to that project, rather than combating it.

But I think it's hard to do. Because you've got schedules, and you've got budgets, and you've got people coming at you with timelines. And the contracts aren't always written to be friendly that way.

ANDREW MAYO-SMITH: We talked-- when we were prepping, one of the things we talked about specifically around contracts is also risk. It's impossible for me to think about contracts in the AEC industry without thinking about how those will help delegate the risk to the various project participants.

We'd love to see contract evolution, for sure. I think there are a number of things that would probably have to come into play, in terms of educating owners. You brought that up. I think letting them understand what the benefits of like increased collaboration could be. But I think part of it is a risk conversation.

GEOFF CAMP: I think a little bit of it too, is-- you were talking about it, Bob, but sometimes there's-- I want to say, like misaligned expectations. I think that's something like at Suffolk, we've been trying to rethink how we approach that. Like what is the role of the architect? What are they best equipped to do? What should we expect out of a document set? Like, what's unreasonable to expect? And trying to define that better, I think that's helped us maybe build-- fill a little bit of that reservoir of trust, by at least recognizing that.

Because I think there's definitely folks on the construction side with, I think, unreasonable expectations on what should be in there, especially if you don't have-- to your point, you don't have certain pieces of information that are critical to manifest the building. So why should we expect that the document should enable us to do that 100% without any other inputs? That's not-- to me, that's not reasonable to expect from the designers. And just recognizing that, sometimes is a step forward in enhancing the trust with the design team.

ROBERT YORI: One opportunity I think that exists-- tell me if you guys have experienced this, but I can't count the number of projects that I've worked on and that I've seen other folks worked on, where most people don't even have access to the contracts. Sure, blackout the numbers, do whatever you need to do from a project management standpoint.

But I think one of the reasons those expectations can be misaligned is because nobody knows what they are, except maybe the project manager, or the partner in the firm, or whatever, the head-- the construction lead. I think this idea of sharing those expectations, not just among the entities, but among the team members, so that you understand what you should expect from an architect or an engineer, and we understand what we should expect from you, and that role, and so forth. I think a little bit more transparency about those agreements across the project teams would do wonders.

GEOFF CAMP: Yeah, I would agree with that.

DAVID JOSLIN: This gentleman has been very patient.

ROBERT YORI: Oh, I'm sorry. I went off again.

AUDIENCE: No worries. Thanks, Robert, for fixing your mic. Something was going on where you were cutting in and out a little bit.

ROBERT YORI: I don't know.

AUDIENCE: It works now. But now thinking about it, I'd say trust is something built over what other people will do with your vulnerability. Like in a relationship, that's how you build trust. It's like, what are you going to do with this vulnerability that you just found out about me on this job site? Or me as the contractor, that I know I made a mistake? And those contracts have been built to try to eliminate that human side of it.

So it seems to be like the communication and collaboration, it's almost like you have to have a dual track. There might be the document stage of the BIM, where you have a 3D model, but there should be like a sidebar conversation of like, what made you do that? What made you change that? I drew it this way.

By the way, I'm an architect. I was a carpenter too for a long time. And I was in the army. And now I work for the army as an architect. So I'm kind of a terrible person because I'm my own owner too. So it's like, I've had to learn I have to have mercy. Because I have to be merciful, frankly. Because a lot of people don't read the EIA documents. They don't really know what they're on the hook for.

So there's a balance, but I've found it much better to play nice when somebody has a vulnerability, as much as I can within the contract, of course. I'm not going to violate the contract. I owe that to the taxpayers. And sometimes, you just can't play nice. But that goes a heck of a long way for the next time that we have to work together on a project, because there will be a next time.

I'm a low bid environment. So low bidders tend to get low bid jobs again, and again, if they're good. And if they're not, they basically go away. But that's my take-- vulnerability, what do you do with it? That's trust.

ANDREW MAYO-SMITH: But I think that's why you see high trust jobs being more successful, generally speaking. Because-- you used the example-- like, mistakes are going to happen on a project of any meaningful size. So like if there's trust there that you don't feel like the person is going to screw you when you open up that vulnerability that you made a mistake, then that issue is still there, whether it was communicated or not. And so the faster the team can work together to address something, a demonstration of a high trust environment, is why the projects see the success that they do.

AUDIENCE: It boils down to that honesty.

ANDREW MAYO-SMITH: Yeah.

ROBERT YORI: And perhaps, paradoxically, if you find yourself in that situation, and you are able to work through that nicely, professionally, collaboratively, that actually really reinforces the trust moving forward. Sorry to cut you off.

GEOFF CAMP: No, I was thinking of an example from a project. Like having pre OAC meetings, without the O, where those vulnerabilities or those issues could be discussed, agreed. There's solutions or some level of consensus where you're not going into those interactions like with gotcha moments, or to your point about taking advantage of that vulnerability to position your entity on the project. Those things are critical to enhancing that relationship.

I was going to say-- you also asked about, or you made a point about understanding decision making. I've tried to do this and I don't think contractors do it enough, just simply asking the question at the outset of a project or getting the design presentation. Like, show me the half hour concepts of the evolution of your design and what things are important to you.

Like, we don't ask that. We just rip the drawings open, what's wrong? Like that doesn't start the relationship from a good way. And just taking the time to understand that. And I think that shows respect, and engagement, and builds some of that trust.

DAVID JOSLIN: Yeah, go ahead.

AUDIENCE: I think you guys are missing one guy and that's the owner. I'm currently-- which is important, because you need to build the trust from the top down. You need to trust your owner and your owner needs to trust you. Because that's the one-- architect and contractor don't have a contractual relationship with each other, but both with the owner.

I'm sitting right now literally in a scenario where the electrical contractor wants to have a change order, claiming the specs are wrong. The owner's lawyer says, no, the specs are right. The owner does not want to pay the change order. And if he has to change it, pay the change order, he's going to file a claim against the architect. Even though his own lawyer says, no, you don't have a case against the architect, he still wants to file a claim. I have no idea.

And-- but that's part of the problem there, right? In the entire team, it only needs-- among all of the main players-- this is a multi prime contract, five prime contractors-- it only needs one guy to violate the trust and to be not trustworthy, and then everybody needs to start protecting themselves against the vulnerabilities. You should have had an owner here. What's your take on owner position? You said you're an owner, right?

GEOFF CAMP: Definitely, I think, generally the owners I've interacted with-- you're right, I don't have the answer to solve that problem. I think owners generally, they don't play up the idea of accentuating or amplifying. The differing nature of our roles on the project, like I think most owners want to encourage a-- that I've worked with, encourage that kind of trust relationship, and again, building that up.

But that is a tough question. Because you're right, one instance like that, everybody immediately-- that scenario can affect the whole rest of the project. Because everybody's going to go back into their corner. All that goodwill that's been built up is diminished very quickly.

ROBERT YORI: I think, maybe, and this is just off the top of my head here, so I don't know how valid it is, but I feel like from an owner's perspective, probably what's most valuable to them is that they trust that the architect and the contractor can get along to deliver what they need. It's important for the owner to trust the architect. It's important for the owner to trust the contractor. But I think, ultimately, the owner wants the project that they are paying for.

And I'm sure that they would like it without a lot of bickering among the parties that they hired to do that. So I think that there's a trust in the combination, let's say, of the design team and the construction team, contractual relationship or not. There's a level of trust, I think, that would be very, very valuable for the owner in that respect. And then, I suppose it's up to us to figure out how to do that.

GEOFF CAMP: Right.

AUDIENCE: Another chair that you probably want to have up there I think is the insurance companies.

[LAUGHTER]

AUDIENCE: So--

ROBERT YORI: Sorry, the stage is too crowded.

GEOFF CAMP: Not enough space.

DAVID JOSLIN: We need another platform.

AUDIENCE: They're actually, I think, a really big player in all of this. Because they're behind the scenes. And they're suggesting language that needs to be in contracts. They're setting the stage for-- like, if there's a problem, if somebody gets hurt, or there's a lawsuit, they will try to recover their costs. So they will go ahead and sue somebody even if the party they're insuring doesn't want to sue. Because they're trying to recover costs, recoup costs. So they will pass that down and sue everyone.

So that's-- a lot of the problem in our industry is that, is how we're set up as smaller companies that then have their own risk profiles. We all have insurance and we all are trying to protect ourselves. And all of that is not aligned. Like, they're all against each other trying to protect against all of that.

So I think that's where like IPD and Design Build tries to start to resolve that a little bit, in having a single entity with aligned goals and risks, and all that. So I just wanted to mention that.

ROBERT YORI: Phil Bernstein from Yale has some really cogent thoughts on that. I've heard him talk more than once about eras of collaboration, throughout the last 50 or 60 years. And I remember him bringing up the insurance companies at a particular point in time and what was driving a lot of the contractual relationships through different phases of trust and collaboration in the last 50, 60 years.

But I think you're right, for some period of time they were a significant driver and remain a significant driver. But the artifacts of that period are very much encoded into the standard agreements that we have.

AUDIENCE: This is a technology conference, so I'll bring some tech into it. A new chair for a robot.

ROBERT YORI: All right, yeah.

AUDIENCE: So, obviously, I think this discussion stems from the adversarial nature of AEC. And it stems from the fact that our instruments of service are drawn, they're 2D, they're incomplete. There's a lot of interpretation required. So that involves-- you're either going to be adversarial about it or trust each other that you're going to fill in the blanks.

But I know there's been other contracts, but a big deal happened on July 20th, and is that EIA released their digital document series. So now architects can deliver data as part of their deliverable package. So this data-- there's no such thing as a perfect model yet, but this data can certainly be much more targeted, like here's the roof slopes, here's the slab dimensions, here's this rain screen.

So you can deliver much more explicit data. We can show you the tile turning the corner. Before that, the E203 said, enjoy your data, but you can't trust it. And it basically said that, you can't trust it. But now we have a new E201 with the tier 3, that says, here's the data, trust it, we can be liable for it now. So that opens up a whole ton of opportunities.

It's one more explicit instruction, but you're also delivering human readable, as well as machine readable data. So now we're delivering data for the robots. How do we get the robots to trust the data? Can the robots trust the data? Is the data-- does it change the trust equation with what we're delivering as we move into a data context?

ROBERT YORI: I was going to say it's a really good question. I typically say that when I don't know what the answer is. But no, I'll put it a different way. That's a really thought provoking question. Because what it does is that it sort of takes that will figure it out abstraction, let's say, among humans and codifies it. So it's very clear whether something's working or not, whether-- but then we go back to trust.

Like, what sort of trust that? Is that a trust in the data format? Is that a trust in the data itself? Is that a trust in the translation from platform A to platform B? Is that a trust in whatever physical specifics or limitations the tool, the robot, has about how to realize that thing?

There are-- in some ways, it raises more questions than it solves. Because there are a number of other potential chokepoints or potential points of failure in that chain that are explicit, rather than this fog of we'll figure it out together, which I don't love, but that's what the industry is more used to. But now, you have seven things on your checklist-- or whatever the number is, you have a whole bunch more things to check on your checklist if something's not working out right.

Which is not to say that that's bad. In some ways, it's great. Because it's a little bit more explicit. You can go through them line by line and just begin to check. But it does open up the potential for more work in data validation than in the actual design process or the construction process.

GEOFF CAMP: Ensuring the fidelity, right? The automation tool doesn't need to trust it, but the input going into it, you have to know that it has fidelity. I like your point about-- and I think there's been some tools in the past. I haven't seen the new EIA documents, but think there's been some ways to enable and be specific about-- to your point of instead of just saying, here it is, don't trust any of it, and I wipe my hands.

Like, to at least have a conversation or to document what is trustable, what is trustable for what use of that information. I think that helps. And we've had some tools, I think, to do that.

ROBERT YORI: That raises the bar tremendously, like it really elevates it. Because I've brought this up a few times before. Like, if you have five key points that you want to make-- let's say, if I was doing a presentation here, and I had five key points that I wanted to make, and I was putting a slide deck together, how would I present those five points?

I would present them, maybe, not unlike the screen that we have here, like five clear, key, distinct points. I wouldn't bury them in a 300-slide slide deck. And I think the new documents give us the opportunity to contextualize this mountain of information-- well, not even information-- this mountain of data that we would be handing over in a model. And be like, here, everything's in the model. You figure it out from here.

And to say, no, look, here are the key points. Let me take your hand. Let me walk you through here. Pay attention to this. This, don't worry about. Pay attention to that. That, don't worry about. It's a really curated-- a more curated experience to the model that promotes human understanding of it.

AUDIENCE: I think the operational phrase is right of reliance.

ROBERT YORI: Yeah, right of reliance.

ANDREW MAYO-SMITH: From a software provider perspective, as I think about the question you raised, it's almost like what would it take for the industry to trust the technology? Because it feels like what you described to me, the solution would be something around machine learning. And what I find is that any time machine learning doesn't deliver on what it's trying to do, it's always said, oh, well, it's an iterative thing. It just needs more scenarios to get the answer right.