156: ‘Why Are We Doing This in the First Place?’, with Shane Burger

Member 155: ‘Why Are We Doing This in the First Place?’, with Shane Burger

[00:00:00]

Evan Troxel: Welcome to the TRXL podcast. I'm Evan Troxel. In this episode, I welcome Shane Burger back to the podcast. Uh, Shane is an internationally recognized leader in the advanced use of technology in design and experience for the built environment. And as a Principal at Woods Bagot, he directs a vision centered on technical innovation and leads a global team dedicated to researching, developing, and applying new models of design and delivery to projects.

He has lectured widely on a range of topics, including design computation, BIM. Digital fabrication, building performance, VR, and AR smart buildings and digital culture and experience.

Starting in the early two thousands, he was an early advocate and active developer of design computation methodologies in the AEC industry. Uh,

During that time, his built work at Grimshaw architects focused on the design of arts and cultural institutions. And used an array of computational processes [00:01:00] to synthesize geometry analysis and material fabrication. He also served for eight years as a director of the design computation and education non-profit smart geometry, firmly positioning it at the intersection of art design technology and the modern human experience. At smart geometry, he promoted the emergence of a new paradigm for digital designers and craftsmen where mathematics and algorithms are as natural as pen and paper.

In this episode, you'll hear that before I had the chance to formally welcome Shane back to the show, we were chatting about what we were going to talk about, and it was so good I just had to leave it in. So the setup here for Shane's launching point is a tweet thread. He posted about software licensing models in AEC, which I've linked to in the show notes. So anyway, if you're wondering why it sounds like I didn't welcome him to the show, like I usually do with my guests. Now you are prepared for the cold [00:02:00] open.

Today we talk about current and potential future impacts of AI and automation on architectural practice. The shift from perpetual to per user licensing in AEC project delivery software. License management difficulties

enhancing productivity and improving project delivery while maintaining a human centric approach re-evaluating business models towards valuing outcomes and performance, rethinking workflows, balancing technological advancements, and the essence of human intelligence and empathy. And more.

This once again was a fantastic conversation with Shane and I hope you'll not only find value in it for yourself, but that you'll help add value to the profession by sharing it with your network.

I'd love it. If you both subscribed to the podcast and to the YouTube channel or whichever is your preference for consuming the episodes, you can find all of the links from the conversation in the show notes at trxl.co, where you can. Also sign up to get an [00:03:00] email from me Each time new episodes are released with those show notes and links within.

So now without further ado, I bring you my conversation with Shane Berger.

​

Shane Burger: There's been more than one tweet thread I've put out there related to some frustrations that I've

had, um, with how the software industry deals with users, deals with pricing and things like that.

Um, I, I think, you know, to give a little bit of context to what the, where, what led to this and where this conversation basically came from is that, um, um, I have found that a lot of the software companies have been pricing their software based upon how they measure its use, what they consider to be valuable from a profit perspective, which I don't blame them because they, they're a profit making company.

They wouldn't exist if they weren't making a profit. Um, but what ends up, we run into an issue is that when these things butt heads with, um, [00:04:00] how we actually operate as a company. So some of the examples would be, there is a company that we have been. Uh, working with, and I will say things have gotten better and resolved better out of this, but there's a company I've been working with, uh, from an infrastructure perspective to build out a whole visualization analytics platform that we've been working on for a good, probably two or three years now, and unfortunately, they switched over to a per user based pricing system.

Uh, now that per user based pricing system was something that works well for other industries where. If someone's going to be using this particular platform, it's their full time job. They're going to be on it all the time,

and it will be what they do for 8 hours a day, 365 days a year, right? And for that, I would expect to be paying 5 to 10 thousand dollars a year per user for that type of thing, because it is, it makes up the totality of your job.

However, in other industries like ours, This is a platform that we would only use on an occasional basis. Um, it's something that is [00:05:00] most suited towards early concept and schematic design, which means from a phase perspective, you're only going to be using it for the first few months of what might be 12 to 18 to 24 month long project.

Um, so therefore, if you're going to be charging on a per user basis, Uh, for that type of thing, we are paying what is full price as if someone who's using 365 days a year for something that would actually be used off and on for a few months and perhaps only by a few users. And even within that set, it might only be that, you know, someone like me might jump into it a few days.

So I'm paying basically the same price at that point. And what happens then is when you start scaling that up across the practice, we are looking at something that was going to cost us you know, half to three quarters of a million dollars a year

for something that was of occasional use. So that sort of mismatch between the pricing model and what our industry does and how we operate was a, was a frustration.

Now, luckily in this sort of case, the conversations with this company, they understood that [00:06:00] better. And after a while, they were able to change the model that actually better accounted for how much the tool is actually being used. So a good example for me about this is the difference between per user pricing and consumption pricing.

Consumption pricing is, Um, so as opposed to per user pricing where you pay like 5, 000 per year for that user, consumption based pricing is if I use it a lot, I pay more. If I use it very little, I pay

Evan Troxel: yeah, it's like a utility, right? Or it's like putting gas in your

car. It's, it's, it's, yeah.

Shane Burger: I tend to prefer consumption based pricing, especially for an industry like ours where, you know, Besides the core tools of Rhino and Revit, where we have our staff using them all the time, Um, a lot of the other tools are occasional. You're going to use them a few days in a week, a few hours in a day, or even less than that.

So paying the exact same price, if it was your full time job versus if it's an occasional thing, it doesn't work out as well. So we've been trying to suggest when we're speaking with a lot of vendors about [00:07:00] something closer to a consumption based pricing as a utility, as you said, or, um, and we've done this with, uh, a couple of other companies as well.

Uh, we buy the licenses, they watch our use for three to six months, and they come back to us and say, okay, well you have, in our case, 800 users in the system. However, only 300 actually use it. on a very regular basis. So we're not going to make it hard for you to add users, but we're going to charge you 300 users.

And then we'll come back a year from now and we'll top it up if we need to. So that sort of pricing model works a lot better for larger companies where we don't want to have to spend a lot of money to manage the users. We don't have to hire people full time to manage those users. Um, at the same time, I feel it right sizes it based upon the kind of company and the size of the company and how much you're using it.

Evan Troxel: Okay. So I'm going to welcome you back to the podcast officially. I'm

still putting, I'm, that is still going to be in the episode right

there. We're just going to have jumped right into it. So welcome back. It's great to see you [00:08:00] again. I'm glad we got to see each other at AU and make this happen.

And you've been on a whirlwind, uh, tour of speaking gigs.

I don't know if that's true or not, but that's what I'm going to say. And you've been presenting a lot of topics around, um, Digital practice and design technology and how firms work. And this subject is near and dear to my heart. I want to give the tech side of our industry a look behind the curtain of what it's actually like to. work in a firm, manage operations, people, users, licenses, IT, digital technology, design technology, all these things. So this is, this is a great place to kick off this episode. And you said it's good for big firms. I think it's good for small firms too, because it's even worse in a small firm. you have way more roles.

Combined into a single person's daily, you know, set of tools that they're going to be using. They're going to be managing the project and designing the project and going to

construction administration. In a larger firm, [00:09:00] you do have more disparate roles for all of those things. But it still totally makes sense what you're saying because our projects last years,

we don't do the same thing day in, day out. I don't need a visualization license when I'm, or maybe I do nowadays, but I didn't, used to need a visualization license in certain phases of design. and so as an example, now, now I think we, we tend to use those quite more often in, in many more stages of design. So maybe that's the worst example I could have chosen at the, at this, at this moment.

But I think it's, it's. It's interesting. You said you're having these conversations with developers. How is it being received? And, and obviously you gave an example of where it's kind of working and you do this. annual reconciliation of what's actually been happening because you can measure all that.

Um, but, but how is it being received?

Because the, the per user, the named user license model, we've seen some big companies move back to that, like SketchUp. Recently, as, as

an example, you know, within the last few years moved back to [00:10:00] that model. And it was kind of shocking to firms who were like, we might have a designer jump in and jump out of SketchUp for a small portion of a project, and then they don't need it for quite a while.

And I don't want to pay for it the whole time. It's expensive. And we can't spend a lot of money on all the tools. It just doesn't work for our budgets. Right. So how are they receiving this message?

Shane Burger: I'd say it's, it's a bit hot and cold. It depends on the company. There's been some that we've spoken to. I would actually say the companies we've spoken to that are not as much in our industry. So the Miro's of the world and others who are doing things with us, but are not just a core AEC tool.

Evan Troxel: Yeah.

Shane Burger: Actually you're treating it quite well because it's, it's a bit of discovery for them. They're like, Oh, we didn't realize that we didn't know that's how you use it. And that's great. So it's been an open conversation and we've been very transparent and said, Hey, we'd love to show you what we do with it to help you out, to better understand what you can do to help our industry.

I'm having mixed luck, arguably with, uh, those who are closer [00:11:00] to the AEC industry. Um, You know, there are a few companies out there that have made that transition to the named users where, um, their answer and response, and I'm going to deliberately stay away from naming names in these cases, but, um, they would, they would basically say back to us, Okay, but this is what we're doing.

And that's kind of been their response. And it's frustrating because in some of these cases, the perpetual license model, Especially the one that allowed you to put the licenses into a queue and then anybody in the company can use them wherever we want

is the closest version to a consumption model without going to a consumption model because we would be watching after our license counts.

We've got our own systems internally able to actually track how we're using these licenses over time. So we'd be able to look at and say, you know what? We've got 150 licenses. We've been hitting 145 consistently and that number is going up. Let's top it off with another 10 and we buy another 10 so that we never run out because [00:12:00] larger company like us, you don't want to run out.

You start getting emails and text messages from people.

Um, so that model worked well for us. Um, but it also probably wasn't. an area of, uh, increased profitability for those who are selling the licenses. So I think a lot of the companies who changed to a named license model looked at that and said, well, here's a way that we can increase profits by selling more licenses, just by switching to a named user model.

And, uh, frustratingly it's often sold as something that they think we would like. And I think in my case, it's, it's often. I've said, I understand how you want that, but this is absolutely not something that we actually want. Um, and we've had an increasing number of companies switch over to that sort of model, which now means that I have to start pricing it very differently, uh, as to how we do this.

I don't want to be restricting the amount of people who use the licenses, um, but by going to a named license model, it forces me to either restrict it, to cap it at, say, 50 or 100 or [00:13:00] whatever we have, and then we have to internally shuffle licenses around, or we have to manage. buying new licenses every few months to just top it up and keep going that direction.

Um, it doesn't reflect the realities of how a business like ours actually operates.

Evan Troxel: And the managerial aspect of that, just to open the window to give people an idea of what that is like, this is a big deal. Like just to have the staff in place to constantly be monitoring and managing and potentially purchasing and getting approvals to do all this. It's a nightmare. It's a literal nightmare

with all the different software.

And, and just, so paint that picture. What does it actually look like for you guys to have to deal with that?

Shane Burger: I think the first thing is if I think about it from a user perspective, um, I've got a job I've got to do. I, I'm working on a project. I need to either access a particular file or do a piece of work. Got a deadline coming up in three days. Um, and I try to open the piece software and I don't have access to it.

What am I going to do for that afternoon? [00:14:00] So from a user perspective, it's incredibly frustrating because then they have to put in an IT support ticket or text somebody that they know who might be able to help them out. Um, usually that involves including a principal on the chat. So hoping that the principal can weigh in on it and say, please let us get that,

make it happen, right?

Um, in some cases that principal will bypass us and purchase it with a company card, which is something we don't want to have happen. Because whenever that happens, we start ending up with licenses just spread and

Evan Troxel: Just

Shane Burger: proliferating, right? And we don't, and all of a sudden we'll get a message from some company we've never heard of saying, are you going to renew this?

It becomes difficult to manage. Um, It's the ad hoc license purchases and spreading around with different accounts and everything is just a significant amount of work to manage just from a logistics point of view. How do you actually deal with that? Um, and then when it gets to, say, the I. T. staff. they'll get it and they'll ask the question, well, what do they need it for?

Um, [00:15:00] is this actually necessary? So a judgment's call has system start to come into play. You know, they've been maybe told that we're supposed to cap it at 50 licenses. So we either need to contact someone else in the company and say, do you need your license anymore? Do we look at our dashboards and see who hasn't used it in the last 60 to 90 days and say, we're going to remove it for that user.

That's not a good experience because they may need it next week. So we ended up having to shuffle licenses around and have a lot of. Uncomfortable conversations with staff who are rightly frustrated, who don't want to have to deal with this sort of thing. Um, then when it comes to the process of, you know, when we do need to make a judgment call, there's a lot of back and forth conversations.

Can you use the free version if it's commercially viable? uh, someone else on your team already has a license. There's all these things that come into play when you have to deal with a per user license or you're capped in some sort of frustrating way. All of this creates an experience, I think, for the end user.

That is, uh, understandable frustration towards the technology teams. But those technology [00:16:00] teams have a hand tied behind their back, either by the licensing system, by the software vendor, or perhaps from a budget perspective. But then, arguably, the staff also has a sort of bad taste in their mouth, perhaps even towards the vendor who put this situation in play in the first place.

And we'll have to communicate with those staff and say, listen, we're doing what we can, but the way that the vendor has the system set up, it's not easy to manage users. There's one vendor that we work with where, um, We actually have to, if a staff member was to leave the company or stop using the software, they, before they uninstall the software or leave the company, they have to, disconnect the license from the license manager system in the software.

So, say you're leaving the company, I'm going to have to go up to you and say, please launch this program, log into here, disconnect your license, and move onward. Say their computer crashes and they have to rebuild the computer. That license is lost for a year and we've had that happen enough times. It's not to say our computers [00:17:00] crash all the time, but it happens.

Thousand person company, it happens. Um, there's lots of circumstances that actually prevent you from being able to do that. Because there's no central management interface, I have the email address of the person I have to shoot an email off to to get them to add licenses to top us up, because I can say, this user, uh, Either is no longer at the company, um, or, uh, they had an issue with their computer.

So you see two versions, two licenses. They don't, they just have one. That's a lot of headaches that nobody should have to deal with. And it creates a sort of bad experience for everybody that's involved. Whereas very simple changes to how these licensee systems work, give people the opportunity to use the tools.

They don't have to ask for permission. They don't have to fight to, you know, have one person release their license if someone else can use it. Um, I don't understand why any company would want to prevent people from using their software by actually making additional headaches from a management perspective.

Evan Troxel: There's so much in there [00:18:00] and I'm glad you brought up the staff leaving aspect to it because turnover happens and it happens quite often in architecture firms. I mean, they staff up, they staff down. There's

certain firms that do that a lot. There's other firms that try to hang on to people as long as possible and maybe it's less of an issue. But other things in life happen too

things change all the time or just getting new computers or whatever, right? And, and so. There's, there's so much nuance to this and I think what it all comes back to is like not caring about the actual users and it's

more about looking like it, it, it's going to be more efficient because maybe, maybe that's the expectation is that it is going to be more efficient, but it's more efficient for the vendor.

It's not more efficient for the firm itself to do all this. And, and who actually is monitoring email. Like a hawk all the time, because that's the expectation too, right? If I send in a support ticket that I need this thing right now, the expectation is [00:19:00] I need this thing right now.

And if you're in a 1000 person firm, that's not going to happen either.

Right. And so like the, the, just the queuing times that are going to happen because of this. Uh, predicament. And, and I want to, I just want to double down on what you said. Maybe the, the staff gets a bad taste in their mouth towards the vendor. I think that is less the case than getting a bad taste in your mouth about your own IT department, your

own DT department,

because they're the ones telling you, no, you can't get into all the nuance of why this is happening like this, that it's actually the vendor that's forcing us to do it this way. And again, I think it's about the vendor not caring about the actual end user. of the software by creating these systems. And so, uh, it does suck to hear that they're, receiving this in a cold way for, you know, for the most part.

Shane Burger: I have, um, I even had a conversation just over the last two days with, um, A company that provides, uh, generative AI image creation services, [00:20:00] uh, uh, services that doesn't offer an enterprise approach. So their answer was, well, just set up individual accounts for every single person. Well, we've got between 75 to 90 people in the company who are playing around with these things, and that is now 75 to 90 people, individual accounts linked to my Work Amex card.

And just, that's not how this is going to work. So, you know, and I've, I've had this with lots of different companies that you could create the most amazing piece of software in the world. People could absolutely love the features. If you make it a nightmare for IT and design technology staff to manage this system, I'm likely just going to say no because we don't want to put ourselves in the position of being the people that's having to tell staff, no, you can't have it because the licensing is preventing us from doing this in this way.

Um, It makes it really hard for a company like ours ultimately to be able to manage this type of stuff. staff members shouldn't have to even know anything about licensing systems.

They should not have to care.[00:21:00]

They just want to do their job. Right. They just want to do their jobs. They want to be able to open what they need, and get access to what they want, and use it. And then they shouldn't have to be doing, Oh, I have to release my license, or Who do I need to talk to whether we've hit our quota in the studio for such and such license.

That should never be a conversation for them. And I, and ideally then you should make the lives of the technology staff and the company easier such that we're not having to then explain that or have to be the bad guys to tell people no in that situation because you've made the whole situation more difficult.

So I do very much steer away from a company that's going to increase our management overhead. if we have to start adding staff, whose entire job is to just managing users and data in these systems. You start building up enough of that, it gets to be incredibly frustrating and difficult to deal with.

Yeah.

Evan Troxel: weird version of the consumption slash prepaid, you know, it's weird, right? You don't want to have a staff member like running out of [00:22:00] tokens. Right when they're in the,

on a deadline, for example. So that's not a good solution either.

Shane Burger: Yeah, I, well, tokens for a few cases is, yeah, buying them in advance and topping them up versus, true consumption systems, just, you're going to pay for it after you've actually used it.

I, I would say there's some there's some difficult parts about, um, consumption systems. It's harder to budget for them.

But budgeting and restricting should not be the same thing. You don't budget in advance and then stop people from using things. A budget should be an estimate of where you think you're going to go. In any consumption based system, you should be able to watch the analytics to see you ultimately where they get to.

The other frustrating thing about token based systems is, I'm generally not a fan of abstract, currencies in order to to pay for these things.

How much is that? One token is a 1. 90 US dollars. Like, what does that actually mean? And what does it mean to consume those tokens?

Again, this seems to be adding a layer of abstraction to something where in the gray [00:23:00] areas and the gaps in between, it will inevitably be more profitable for the software company versus just paying for actual consumption.

Evan Troxel: Yeah. Like just defining the value and how much it costs to achieve that value, I think is a reckoning that really needs to happen and, I guess we could continue to flog this, but do you want to. Talk about who, who's doing this right. Like, you don't, we don't want to name who's doing it wrong, but is there anybody

that like springs to the, to mind that, that you are enjoying their licensing model that you want to give a shout out to?

Yeah.

Shane Burger: to what happened for us with Miro, and Miro was a case of where it started off on a per user basis, um, and it was going down the direction of the named user approach, but then what we were able to show them is, uh, first of all, they gave us some room. They said, All right, we're gonna do a quarterly update top up agreement with you. You have a certain number of licenses, and every quarter we're gonna have a conversation to look at your use. And we [00:24:00] won't restrict with how many users you have, but we're going to look at it. Ultimately, we end up signing a three year agreement with them based upon that sort of model, but it's a yearly kind of update.

The thing I appreciate about them was, they, uh, used the data to inform the decision. They looked at how we were actually using their tool, frequency at which people were using it, how they were using it, even down to the point of understanding the difference between Uh, what a viewer license was versus a creator license, someone who's actually making boards and editing them versus who's just looking at them.

They had the backend analytics to actually answer that question to which they were like, Oh, Okay, yes, you do want to have all 1, 000 people in. They listened to us when we said, we don't want, have to have one IT staff member sitting in there constantly adding and removing people all the time. And I, we did it for a few months to show them what the effort looked like and how it was kind of ridiculous that this was happening.

Even to the point of pointing out to them that even our [00:25:00] CEO and some of our global design leadership were viewer staff, which weren't really counting as full licenses, but they were going to get paid. Pulled out of the cutoff because of the frequency at which they did what was called, I think, a paid action or something.

They were mostly viewers engaging in design reviews, not creating their own boards. So we explained to them, you're putting us in a scenario where, um, arguably if we follow our rules, our design leadership would not always be given full licenses. They understood what that meant. And they came back to us and said, all right, here's a pricing model that we're going to put together for you.

That is, um, based upon. how much you actually use the tools. So we're going to open it up. we'll use single sign on, allow you to add all the users that you need in the system, but what you're going to pay for is people who are actively using it. And that was a, that ended up working out a lot better.

I would say though, that that is likely a scenario that's only going to work for a large company because it does require a direct engagement with a sales representative to be part of reviewing and kind of a customer success manager sort [00:26:00] of system. So that's something that I think you would definitely need is it would benefit from being a larger company to be able to negotiate that sort of relationship with them.

I have been finding there's other companies out there that do similar types of models. Well, we haven't done it yet, but our work with Atlassian, my team uses JIRA. The IT team uses JIRA as well. We have increasing numbers of people in our operations team using it. When we pass a certain threshold, they do the same type of thing.

We haven't really passed that threshold, but the conversations have gone really well with that. Um, there are other companies out there that I think do a relatively good job of it, even if I have some of my frustrations. I do fundamentally like Autodesk's model it's a token based system.

However, it is a consumption based system and there are things I like about how they do it and it puts us in a position where it does right size it based upon how much we actually use the tool. Now, granted, it's, you know, it's not, recorded hourly. It's if you use it during the day, you pay for the whole day's worth.

I can maybe understand that sort of [00:27:00] scenario, but I do appreciate their approach on that because that is closer to actually paying for our real use. Um, other companies like McNeel have kept to the traditional perpetual license model. Um, and in that sort of case, we, I think we own something like 150, 160 licenses and it covers our whole company globally that actually use it.

Our peak use period is pretty much when we get to New York City evenings and West Coast afternoons and Australian mornings. I think that's typically our peak use or a little bit further when China starts to come online, but we have purchased it based upon that amount and we're able to watch. Using their analytics to see when we're peaking up to that particular level.

So that's the traditional older style perpetual license model, but it works really well and we keep buying licenses and nobody loses their chance at a license. There's other companies that have done perpetual license models though, that have not provided analytics. So one in particular, I won't mention, but around some visualization tools we've run into [00:28:00] where, uh, it is a perpetual license model, which is great, But they don't provide any insight into how much we're actually using.

And we're having trouble internally recording how much it's actually used because it's a plugin to a tool. So it's not easy to actually get insight into it. So that's one of those ones where we have run into issues where, um, we don't end up topping up licenses until we run out and someone starts talking to us about it.

But we also don't know if we can downscale licenses. Visualization market is really competitive. There's lots of competing tools. We have people trying more than once. We might actually be able to. shift the balance of licenses between them. But unfortunately we don't have enough insights into how much is actually being used.

Evan Troxel: And you can deploy kind of insight machines on your side of the

pond as well. Right. But again, more to manage, more to watch, more to track, a lot more conversations with users.

Shane Burger: Right. a lot of these companies have their own tools. Sometimes they will allow you access to those analytics. Um, so that is, uh, [00:29:00] that is great. A good example, actually, also on the positive side is, um, the company Avail that makes the Revit content management system, which is our preferred choice for a system.

Um, they have provided us with, um, Uh, Power BI. I think it's Power BI. I could be wrong. But dashboards that gives us insight into the actual use. There are another company that also has given us open access or unlimited access, but we top it up every year. We have conversation with them to say, this is how much we're using and how much we pay.

So they watch what our numbers are, and they provide access to all the analytics for us to actually understand, is it being effective? Is that good for us? It's something I would like to see more of from other companies. So either access, they either provide the dashboards or give us access to dashboards to pull data in.

If those aren't the case, we end up having to use some of our own tools. So we're in the process now of consolidating our tracking systems on all of our various tools. And that's everything from commercially purchased software, where they sometimes provide analytics [00:30:00] to platforms, which we have no analytics and we're having to.

You know, use systems built into Windows to be able to keep an eye on how much people are using the tool, down to some of our own tools, um, that, uh, are plugins, automation tools, so we can track how much people are using them.

Really, for us, it's, it's a combination of, um, Wanting to know, are we investing our money in the right place?

Do we need to buy more licenses so people don't run out, but also ensuring we're providing the right balance of support. So if we start seeing significant amount of use in one tool versus another, it might highlight to us to say, we should be investing more energy and keeping that up to date. If it's a tool we've built, maybe providing updates to it, but also making sure we can support the users.

So our analytics work is going to become pretty important, I think, over the next six months to try to pull all those dashboards together.

Evan Troxel: That was a really nice unplanned, unscripted, high five to Avail, who's also sponsoring this

Shane Burger: Oh yeah, there you go. That's great. Now it's, um, I appreciate [00:31:00] when. Companies, uh, understand the needs of what an architecture practice is looking for and do something that suits and balances without it is how, how those companies operate. Avail's been one of them. There's, as I said, Miro, not from our industry has learned and has helped with it.

There's others that are out there that I'm probably not remembering at this moment, but, um, I do appreciate when it's a, uh, a more reasonable conversation about, uh, how the tool is actually being used.

Evan Troxel: I feel like that's more of a partnership, like they, they have a genuine interest in the value you're deriving from their tool to do your work, right? It's not

just to have this relationship with them. Like you're not buying their software just so that you get to talk to each other, right? you're employing it for a purpose.

And if they're genuinely interested in what people are getting out of that and what you're doing with it, that partnership, I think does lead to the kind of relationship that you're talking about rather than the other way around. Yeah,

Shane Burger: I think we've had some [00:32:00] successes with that. We've had some frustrations. I think that most of the frustrations have occurred when this is a company that provides the same software to multiple parts of your industry that may be used in different ways.

So an example would be a software that is used by contractors and architects. Well, which one do you price it for?

Do you price it based on what the contractor is going to look for, which they tend to have, um, you know, uh, a larger ability to spend money on software than an architecture practice, or what the architecture practice is, is going for?

And when we have imbalances or differences like that, we usually run into some, uh, differences of opinion about how we should price it.

Evan Troxel: And in contrast to manufacturing where you're making widgets or you have an assembly line where somebody does a specific thing day after day to your point much earlier in the conversation. This is not that this is your we're An architecture firm is not a company that makes the same, the same person makes the same thing day

after day after day.

It just doesn't work like that. Project teams disband, come back together in a different amalgamation to tackle a new [00:33:00] project at a different phase in a different part of the world with all these differences amongst multiple years throughout the phases of a project. And, and that I think is something that is difficult. I don't know if it's unique about architecture, but it's definitely different than, like when Miro comes to you and they're working with somebody like GE, let's say, who's making jet engines. Like, that's going to be very different from what an architecture firm does, right? So really interesting to me to hear that they were interested in finding that out and not just sticking to like, this is how we do it, which is the answer that you also showed as a contrasting answer.

It's like, Nope, this is how we're doing it. Um, and not willing to listen, not willing to maybe care about what the users actually need. And so just, just maybe to wrap this part of the conversation up, um. Have you actually gone through, and I assume the answer is yes, but I want to hear it from you, to just say, okay, that tool's gone.

Like we can't use that tool, at least [00:34:00] until we come back and revisit it at some other time.

Shane Burger: yes, it's hard to do. And I, I would say I'm not

Evan Troxel: People love their tools, man.

Shane Burger: They, they do and I get it and I understand because it's, it's, it's what you've been using for years or a decade or more and it is the, it's the instrument that you are used to expressing the work that you're doing. Um, you're efficient at it.

It's like learning any instrument. Um, you know, you're going to say, Nope, you're not going to play violin anymore. Here's a trumpet. I, you know, when am I supposed to do that? I, I have lost my ability to. you know, to execute on the work that I'm used to doing. So it's disruptive, uh, for what is already a stressful, high pace sort of profession.

When you are removing people's access to the tools and systems that they're using, that they're used to using to do their job, it's a significant stress. It's a high level of frustration. Um, But yeah, we've had situations where we've had to basically say, well, we no longer use this particular tool. I'd say it's [00:35:00] more common that we limited its use.

So, you know, one of the modeling tools that we've limited use on is a case of where we have selected particular sectors or subsets or studios that have access to it because It may be necessary based on the market that they're working in that particular region. It's the most common tool that people used to share models back and forth.

So, okay, I get that. Or, um, there's a particular set of features or workflows that are essential for this and they need to use it quickly for this work. It's short, you know, a short turnaround sort of work and it is the most effective one to do that. I get that. I understand it. that desire to have an individual choice of the tools that you use runs up against not just things from a cost perspective, but also from a collaboration perspective. Uh, if we don't try to unify around a small set of tools, when you start sharing projects from studio to studio, it becomes next to impossible to actually be effective on that.

So if one person is using a completely different tool, Then everybody else is, then that [00:36:00] person is kind of separated from how the rest of the group is actually going to operate. And you have immediately some built in inefficiencies.

Evan Troxel: And people say, Oh, just, just export your 3d model. And you lose something every single time you lose

stuff every time that happens. Right. That's, that's the biggest downside to that. So,

Shane Burger: It's not just that you've lost things from a. technology standpoint, it's lost from a workflow standpoint. You have now decoupled the work of one person in the team from the rest of the team.

Um, it effectively just turns into, okay, I see what you have over there. I'm going to look at that while I'm working on what is our main tool that we work within.

And when you decouple those sort of processes, uh, in delivery, you have inherent inefficiencies even beyond, um, issues of file formats.

Evan Troxel: Yeah, for sure. I want to shift now to maybe the future of the profession, but I want to kind of couch that, at least get into it with tools. And so you mentioned AI earlier, right? And

so we're we're seeing changes happen. We're seeing disruption happening. And you also [00:37:00] talked about kind of the limiting factors of licensing for enterprise and things like that.

But let's start to talk about AI and the future of the profession as a, as a lead in, because obviously the future of the profession. does not equal AI, right? So I want to talk about that in a, in a bigger scale, um, but in a way to get there. Let's just talk about kind of the emergence of AI and what that's meant at Woods Bagot and, and for you and your teams,

Shane Burger: Yeah, I think, um, we've been keeping an eye on what were the potential opportunities for us for many years now, but it wasn't until, and this is probably the same for a lot of architecture practices,

um, tools like mid journey and stable diffusion and DALL-E coming out in combination with chat GPT. And I think for us, it was initially catching up to what the conversations that everybody was having around those tools where we think they would be a value to the practice, where we think there are some concerns and limitations for each of them, but at the same time, actually trying to project forward.

Well, what's next after this? [00:38:00] We didn't want to be in a position where we're always running to catch up. And every three months there's something new. Uh, when I presented to our shareholders conference just two weeks ago, I ran a two hour afternoon workshop on AI and architecture and design. Um, wasn't just two hours of presentation, but a lot of back and forth and debate and discussion about what this means for us as a practice and, and how does this fit with our, our credo, how we approach our work.

Um, one of the key things to point out was that just the week before, it was when OpenAI's Sora, Came out the video creation tool.

Uh, not something I had in my presentation, but of course I added it right in there and just basically explained to everybody these sort of innovations are happening on a regular basis.

So what are the fundamental trends? What are some of the things that sit underneath this that gives you a sense of what direction these things might actually be going? Um, and that was where we kind of ended on a series of topics that should be discussed. Um, and we should be considering how they affect our practice.

One of the [00:39:00] biggest and first ones is the fundamental change about how we access knowledge. And we started asking questions of, we've got 150, 160 years of practice, 18 studios around the globe, multiple sectors, a thousand people. What happens when you have access to that kind of information in the context, in a context relevant way, uh, to answer things that you need to know, you know, what happens in this sort of scenarios?

And that became, beyond the excitement, I think, about the image creation, which we can talk about and get into, I got more interested into what it means to tap into and harness knowledge, not just within our practice, but within potentially the broader industry. Yeah.

Evan Troxel: that we had a conversation on the podcast. What you were, we were talking about second brain, Roam Research, right? The interconnectedness potential of notes. Like just

talking about like, where do you take your notes?

Where do you take your notes? How do you, how do you. link between notes. Is there a way to get [00:40:00] insight out of then all the notes you've taken, right? And now you're talking about that at scale. You're talking

about that in an organization and it's a very, it's, it's the same conversation, but it's just at a way larger scale.

And so I'm, I'm interested in, hearing it from, from that side, but I'm also interested in hearing about like the pursuit of creativity as well, because

I think that's kind of the existential Crisis that we see going on in firms as well. Not only from a, like, where does creativity come from?

Is it going to take our jobs, but also ethics, governance, things like that too. Right. There, there's a lot going on here in, in the whole

AI sphere, but, but let's, let's continue to go down the, the knowledge side of the graph. And, and I I'm curious to hear what, what you guys have come up with. Mm hmm.

Shane Burger: Yeah. So, um, we have a set of documents in the company called design intelligence documents. I may or may not have talked about them in the previous podcast. It's effectively a, an overview of all the major decisions around a project. Um, it's a way that [00:41:00] if you're a new member of the team or want to know about what happened on a previous project and go back, you'll say, well, this is the site.

This is the client. This is what they asked for. Here's some of the early concept designs. This is how we got to where we were, the decisions that we made, the major concepts behind this. Um, and one of the questions that I started asking when things like ChatGPT came out was, Alright, well, they are large language models trained on the internet, so yes, they speak English and understand English, and they can work with us that way.

Um, what happens when we can train it on a particular subset of documents and ask questions of those documents? And this is something that I had seen others do. You know, a year or so ago, come out and say, well, what happens when I feed my favorite book into a chat engine? And now I can basically have a conversation with the book.

Ask things about it, query it, and have it bring up information for me. So we thought, why not try this out? So we actually used some of OpenAI's tools via our Microsoft kind of enterprise agreement to [00:42:00] build a version of a chatbot that was a design intelligence knowledge chatbot. We just vetted 50 of them to start off with.

We had to do some work. I would say that it's not the easiest thing in the world. You can't just put any formatted document into a system like this. And I think we realize that sometimes our documents are more, uh, human readable than machine readable. So there's some differences with how it would be good to, to put into these systems to, to deal with potential hallucinations, but we fed 50 into this and we're able to ask questions like, you know, tell me about, uh, any of the projects that have, uh, timber structures.

What are common characteristics or what were the core concepts behind them? And we started thinking about this to say, okay, well, if I'm wanting to know, if I, if I'm guessing that someone within our practice or some project has encountered the problem that I'm encountering on my project right now, what's the best way for me to find that information?

Uh, a standard search will pick up. topic [00:43:00] names, uh, maybe even headings of particular chapters, but not really dig into the insights that are within these documents. It also won't be able to draw correlations between a concept in this project and a concept over here. Um, and often we found that while we create these documents, we've got something like you know, 300 or 400 of these now, um, if not more, um, usually it's just principles and people who worked on the projects who actually are aware that they exist and not even knowing, however, unless they worked on it, the insights that sit within them.

So for us, this became a potential rich opportunity for us to train up a knowledge bot that would be able to Um, understand the history of our projects, and that could come in play in a few different places. One would be for business development. So for chasing after new work, we're having to answer to an RFP.

Um, I, rather than just going to my standard five projects I know that had a strong sustainability, story along with them, I now have access to all the projects that have that information, and I can [00:44:00] query them, and it will bring them up, and perhaps even help me author content. for listening. Not always the best authoring of the content, but it's going to surface things and insights that I may not have gotten unless I had actually read all 300 to 400 of those and internalized all the knowledge within.

It might help during project design, during concepts. putting in queries, asking questions of this. Um, it might even help in later phases, especially when we're getting down into some material selections and later decisions, what projects have used this material. So we then started to extend this to say, well, how about not just design intelligence documents?

What about some of our technical guidance material? Best practices for Revit, our global standards, so that when you're in Revit, you've got a little chat bot, you can ask it a question. Um, maybe it's the second coming of Microsoft Clippy, I don't know,

but it's some version of that, right? And then it went further to say, and this is where we, we haven't gotten here yet, but we started to talk about it.

Um, why can't we be querying our library of, [00:45:00] uh, BIM models in our system? Why can't we create something that's able to crawl through that and ask questions of all of our projects?

Um, and be able to bring certain project metrics out or different things about the execution of that work. So, this is where we saw the very beginnings of saying, All right, we've seen some companies teach or GPT like system.

on a particular subset of documents. There's one, for example, in scientific journals. There's a few, there are up codes has done this obviously for code review in North America. What can we do when we do that? And then what are the next logical steps? Well, it need not necessarily be documents. What if it's other kinds of information that we have, for example, model content.

So that's one example where that initial insight led us down the path into multiple potential opportunities for creating, basically surfacing context relevant knowledge about our work.

Evan Troxel: I think that's what's so interesting about it is like, once you start going in a direction, [00:46:00] light bulbs start turning on,

you're like, Oh, what if we try this? Or, and I find like really surprising results when I try something like I'll feed it images and just say, transcribe these. And it,

Shane Burger: Yeah.

Evan Troxel: I didn't know if it could do that or not.

Right.

But it can, it turns out and, or, or I'll just feed it a webpage that I didn't, and I said, pull all the names. Cause I, I have pictures. Like when we were at AU, we took a picture. I put it, it's Evan and Shane. Here's a link to our previous episode. And I just grabbed that whole page and I said, just make me a list of all the names on this page.

I didn't tell it what to do. What format those names are

in, and it just made a list. And I'm, I'm surprised by that because like that would have taken me a lot of copying and pasting and a lot of time to do, but with a simple prompt, it's just like, pull all the names out.

Boom. There, there they are. I'm, I'm so happy that that worked.

And I think that's what's kind of fun about this. It's kind of like when you learned how to start 3D modeling. It's like, I don't know how to build all the geometry. I'm just going to try [00:47:00] something and see if it works. And if it works, it's great. And if it doesn't, okay, I'll try something else. It's a lot like building a piece of code or something, right?

You're just constantly. Trying things and just being curious about it, I think is one of the best positions to be in because Then it's really non committal, right? You don't have to worry about it performing Explicitly so that you get the outcome you're looking for But of course that will happen over time because you will get actually get good at it,

Shane Burger: I think we're in a spot where the technology is quite advanced and can get super detailed in certain areas, but we haven't really looked at what the broader potentialities across our practice is. It's very easy to look right in front of you and say, well, yes, we want to have a chat bot that looks at our projects.

And yes, we want to be able to do lots of image creation. And at some point, maybe it'll become model creation. I can see those sorts of things. Um, but the issue with this is that this is. I was about to say immature. I mean, it's been, you know, it's been talked about since the [00:48:00] late fifties. So, you know, it's not immature,

but

um,

it's early days for these types of things.

Um, I think every practice needs to be in a position of experimentation. And I think they need to be in a spot where the experimentation is happening broadly across the practice. One of the things that we've discussed with our company is to, to have a group of people, sort of a catalyst for conversations about AI and the broad potential application on their projects.

But then that group is supported by those who can take a deep dive from a technology and implementation perspective. So if someone sees an opportunity with a client to say, All right, well, we have a bunch of data from the client about their, um, about their workplace. We want to work with that information to then drive some auto layout features.

Okay, they have the idea, they have the potential application on our project, but they don't necessarily have the, the technology muscle or the infrastructure or systems to then really take a deep dive to implement that system. So what I think we [00:49:00] need to be doing as an industry is allowing that experimentation, especially at the face of projects, but then giving significant muscle and support behind those people.

They themselves shouldn't be on off alone doing this, but there should be people who are then back within the kind of core of the company who are looking at these opportunities. Some software developers within that group who are building out these systems and supporting them, maybe data scientists or data analysts, some combination of this group, um, who then also looks at what that person's doing and that person and that person and says, well, her work over there actually has an interesting overtone to the work that he's doing over there.

So here's something now, some commonality. And now this suggests we should be building systems that connect these together. We're in a spot with AI where. If you're just looking for the solutions that are right in front of your face, by the time you implement them, the industry would have already gone three or four iterations down the road,

right? So you need to be in a spot where, yes, you are [00:50:00] doing those. That's just to keep up with the Joneses. I think you also need to have some experimentation within your practice to be asking the big questions. How is this relevant for us? It's not just about automating things. It's not just going to speed things up, but where does it provide increased value to your practice?

Um, and not just in a generic way to architecture and interiors or urban design in general, but specifically how you do your work. How does this fit to how you work? So there needs to be conversations at a, at a technical implementation standpoint. But also from a strategic and vision standpoint, what does this mean for my company based on all those experiments that I'm seeing out there?

Evan Troxel: And I think what's interesting about the tools that we're seeing is you mentioned up codes, you mentioned your design intelligence chat bot, right? You've got these really specific tools and that's how they work, right? We've,

Shane Burger: Yeah.

Evan Troxel: that's exactly how they work. They're super specific, but now we're starting to see like this idea of an AI agent that then [00:51:00] connects these APIs together so that This one can go talk to that one and bring information back and they can talk to a third one and they can all connect and kind of huddle and bring back information that pulls a little bit out of each one of them. And to do what you're talking about, like you, you basically described your AI team of, of what

would be a firm's AI team. They have to have that big picture. They have to be tied into the business side and talking about strategies and the culture of the firm and what the. the. values of the firm and the specific roles and tasks that people have to do on a day to day basis and start to link up what problems and challenges do we actually have and then pick the right tools for the job. But have a really great understanding of all the tools on offer, and going back to like the budgeting and the user license thing, I think this is, it's making things actually way more complicated because we're seeing a boom in all of these tools, right? Just AI tools alone, if you just [00:52:00] kept it in that bucket.

There's hundreds and hundreds and hundreds of them all of a sudden, and they're all going straight to the users. They're not going through the traditional channels of how you would implement technology in a firm, if I worked at a firm and they didn't offer access to open AI, like I, I would go get my own license of it

so that I could play around with it, but because I can, because open AI is talking directly to me or making me able to do that, so Talk about a nightmare for a firm, right?

Like to go back to our earlier and budgeting and figuring out like crystal balling, how much we're going to spend in different categories over the year. There's, it's, it's just a big, giant guess, right? Like we don't know what tools we're going to be using because we don't even know the projects we're going to have this year.

Right. So

I think there's always going to be some of the usual suspects that of course, we're going to use this and that on this project because we always use this and that, but there's all these other things now too, that. are proving to be incredibly [00:53:00] useful or we're experimenting, right? We're trying to find that out if they're going to be useful or not.

And then we have to keep our fingers on the pulse constantly over time because they're also changing and updating and they're pivoting quickly as well. We see that happening all the time. So from a DT, IT perspective, bigger nightmare, bigger team, like what do you have to do to actually keep abreast of what's going on?

Shane Burger: Right. I, I mean, unfortunately it does end up needing to have a bigger team to cover this amount of, of, um, Spread between different tools that are out there.

I mean, we don't, you know, the, the work happening on, uh, image diffusion is mostly, mostly myself with another member of my team who have been experimenting with it for, you know, a good year or more.

Um, but even then there's a number of the tools that we haven't had a chance to, to properly try out or really to push ourselves through. Um, I can think of at least three, three, [00:54:00] diffusion right now. Um, at some point we'd like to get it to one would be the ideal scenario. Um, and we're talking with companies about, uh, which one we end up going with.

Um, but there's, you know, strong preferences and experience with each of these. And every two months, another one comes out with a different model or a new feature and they leapfrog each other. And everybody rightly and understandably has preferences as to which one that they like to work with. But as a company, we need to, at some point.

What is the primary tool that we're going to be using when it comes to the chatbots you add on top of this, and this is arguably so in the image section to the concerns about intellectual property. They all have different rules about what information that you could submit to them that won't be training their model.

I've appreciated that. Things like, uh, you know, the, the chatbot, the copilots that Microsoft is releasing based upon chat GPT 4, uh, do have protections for a company like ours if you have an enterprise agreement. Uh, [00:55:00] things that you submit into it will not be going to train the model. Uh, so I do appreciate that that sort of thing is happening.

But, um, a lot of this is going direct to the consumers, direct to the staff. They're experimenting with this at home. They've got, you know, the apps on their phone that they're popping in queries and stuff. Don't blame them. It's like it's right in front of them. It's easy to use. Sometimes it's completely free.

But we have to be very aware that if there's project information, Or staff information that are going into these systems, we have to start thinking about, uh, privacy rights, intellectual property, copyright, all those types of things have to come into play. So, unfortunately, um, just around the time as we started creating some forms that would help us better understand the full list of things we need to consider for new platforms, there was a huge explosion of the amount of those platforms of which we need to answer those same questions.

So, it's getting harder to manage that significant increase that's out there. I really do appreciate, though, the significant competition that's out there. I [00:56:00] think a lot of these companies started off by saying, Well, we know how to do this with AI, so let's find the market that will work with it. And now they're starting to get feedback from customers like ourselves, who are saying, Hey, that's cool and all, but we really needed to do this, this, and this.

Um, a good example, just with the, the image tools, is, uh, the first versions that were out there were, Very much a, um, we know how to create this sort of technology, throw it out there, see what people are doing with it. Now, the next sets of features that are showing up are based upon feedback that people are giving it.

We've given similar types of feedback to AI tools that have been built into Rhino and Revit. Saying, Hey, that's great, but it actually would help everybody if you, you know, if it understood the materials that it was looking at, or the three dimensionality of the object in order to inform the image creation.

So, um, I, at one point, I'm excited.

I love seeing all the new tools. I love seeing the companies leapfrog over each other. I love seeing all the innovation. Um, but then if I, I put [00:57:00] my, my, um, IT, you know, management sort of hat back on my head again, I start getting scared of the amount of things that we have to cover at the same time.

And again, we don't want to be in a spot where we're telling people no, but as a company that has clients with confidential information and there's issues of intellectual property ownership. And there's costs associated with all of that, as well as buying licenses. Um, we have to be on the conservative side.

Evan Troxel: Yeah There's a subject that I've been kind of knocking around in my head, which is unrelated So we're gonna take a turn here but I'm curious what your feedback would be on it because I you know if we talk about the future of the profession one one of the things that We are mired in, and we're not alone.

This is, this seems to be everybody is this idea of like pseudo productivity. it's very hard to measure productivity in architecture. And, and now we're talking about tools that we're encouraging people to play with from a creative sense, [00:58:00] but also from an efficiency sense. We've seen tools come along in the past that have promised efficiency and productivity, but it really hasn't led to that, right?

Like our main production pipeline has enabled us to put more into projects, but it hasn't really enabled us to spend less time doing that, but email, Slack, Teams, Zoom, that's what I'm talking about when I'm talking about pseudoproductivity. And when we're talking about a thousand people at a firm who spend a lot of time in email and in tracking all of the, and in conversations, and what's your general sense about how much time people spend doing that versus actually doing the job?

Because what, what I kind of feel like a reckoning that needs to happen is. Actual valuable output of architecture. And that doesn't even necessarily mean creating drawings, right? That is a. a thing that we have to do to get the [00:59:00] permits to build the building to satisfy the contract documents. And something that Clifton Harness said on a podcast a long time ago was like, if you want to really change architecture, change the OAC agreement, right?

Like actually go to the root of where a lot of this is. And that's where the big fundamental changes. And I feel like we've been boiling the frog with email and with, it's like, okay, this is just the way that it is, but everybody is spending an Unending amount of time being on call for anybody who dips into your inbox. unwelcomed, right? It's never, it's never like the other way around. It's not like you invited them in. No, they just dumped something onto your to do list for today. What's your sense in a firm like yours? That big, I mean, it's just got to be an enormous, like, you probably don't even want to know, but at the same time, like this is the stuff that people are actually doing every day.

And you want to say, we're architects, we're building, we're designing the world of the future. Right. And, and at the same time we're doing email and we're on Slack all day long.

Shane Burger: Yeah, I, [01:00:00] I, some of this is probably predating me by a number of years. Although I think when I started into, uh, started working for architecture practices, I started doing my first internships in the late nineties. And I would see this at this point as well, because not, not You know, not everybody in the in the practice at that point had an email address associated with material.

As an intern, I didn't have an email address. So people came up to talk to me and I did what I was told to do. Um, and as part of that, The teams were structured in a way, were more formally structured to have people who are kind of document and communication controllers. So they were basically holding back the floodgates of the information that was coming from clients and consultants who were there in charge of communicating the material that was out there.

Even when I started off at Grimshaw, my job as a job captain was I was primarily responsible for dealing with Issuing the updated drawing sets for backgrounds to our consultants to work with, receiving their information, coordinating, making sure that [01:01:00] was all set. No one else in the team got involved in that conversation.

Um, if there were particular flows of communication coming in, they had a particular person that they were associated with. Uh, at some point, it started turning into, uh, why don't we just create a, uh, project number email address? Everything goes through that. Well then everybody has access to that. And then after a while it becomes, no, just everybody gets all the emails.

That's too much work to deal with the project control email.

Evan Troxel: And this was back in the

days when email was pop, right? And so

it was like, if, if one person logged into that email address, they were the only person going to download that email because it was going to get deleted off the server. We weren't even dealing with IMAP at that point.

Shane Burger: right. And so this was, this is a case of where, um, we had limitations with the technology, but they, in a way, weren't too far off from how we were kind of managing projects and controlling those projects. Um, we now have, uh, project management systems. We use A Connects for a lot of our work. People, we use all sorts of things that the contractors bring to the table.

Um, But we [01:02:00] haven't necessarily picked up, you know, returned too much of the idea of document control or particular flows of communication

because, um, email made it, uh, effectively democratized access to communication and access to information. So then it meant, well, why don't I just go and ask the person that I know has the answer rather than going through, I would like the answer to my question, so I'm going to email you, Evan, like you're the person I know that has it, doesn't matter if you're not the, you know, don't have time to answer this right, I'm going to ask you or I'm going to text you in Teams.

Right? When we opened up the flood of communication to be as ubiquitous across the entire project team, um, we lost control of the moments at which we can keep ourselves separated from that. And, and you end up having this sort of constant multitasking where there's always communications happening, um, about a project that's interrupting my workflow and what I'm doing.

I tend to be a person that works with headphones on because I get easily distracted, and I cut out everything I possibly can. We can because I'll shut off notifications. I'll shut off everything because it's [01:03:00] too easy to just say, Oh, there's a little drip feed of things that are going on. I think it's it's beyond just our profession.

It's just made it very easy to be distracted about these things. The other thing about this, though, is that even when we attend meetings, especially post pandemic. We're distracted. Um, not telling on anybody in particular, and I'm sure this is the case across every architecture practice. But when you walk through a studio and people are on video conferences with others, they have other programs that are up.

They're doing drawing sets, they're doing other work.

Evan Troxel: Totally.

Shane Burger: Only half their attention is in the meeting at that point. They're catching up other things, because they're busy. They've been handed way too many things to do, and there's no separation between what you, you know, what you're doing. Um, how you communicate and when you work in these things, so it's a divided attention, so it's a, it's a, it's a constant issue about distractions in terms of communications and these things have not provided greater value to the work that they've done, we've done, it's just made us a lot, a lot busier, um, I have mixed [01:04:00] feelings about automation, about how we use automation and what the point of automation is, but ultimately for me, the, the real point around automation is, I'll back up for a second and then hopefully this isn't necessarily changing topics, but, um, automation for me, uh, you could say, uh, it's the client that benefits from automation.

Well, if that's the case, then, you know, the client should have to pay less money for your project because you were able to automate, you know, a third of your construction document set. So I'm going to pay you less money for that. Okay, that's not necessarily going to benefit us. If I go and say, okay, it should be the owners and shareholders that benefit from this.

All right. Um, fine, that's possible, right? So we still charge the client the same amount of money, but we get increased profit from that side. The third option would be to say, it's the staff who benefit from automation. And the reason why I focus on that is because ultimately, any tool that we use, I want it to create, A better quality [01:05:00] of experience, a better value of experience for the people sitting at their desks.

If we can automate away something that was a mundane or repetitive tasks and giving them agency to then choose what they do in replacement of that, whether it's investing in the project in a different way, or God forbid, going to home to have dinner with their family, right? Like, or not working a weekend and getting good sleep.

All of those things. Significantly benefit their life and their project, um, their experience working for you, which is better for, you know, talent retention. Um, they then contribute better to the project. They're well rested. They've appreciated the work that they've done. They haven't had to sit there for eight hours working on a door schedule, which they think is of low value to what they think they could provide to a project.

Which then means, The project is higher quality, delivered more efficiently, so the shareholders of the company and principals benefit from that, and ultimately the client benefits from it as well. So, the, because they get a higher quality project, [01:06:00] uh, or product out of that work. So for me, If I look at any selection of tool that we're purchasing, anything that promises greater efficiencies, um, better, you know, um, better communication, speeding things up, automating things, or a tool that we built, the question I keep coming back to every single time is, Is it creating a better quality experience for the staff who are actively working on the project?

If it's not doing that, then it's less likely we're going to go that sort of direction. That's my measure, is, uh, will people actually, not just necessarily that they need to enjoy it, but will it give them more agency over their time, and give them an ability to provide greater value to the work that they do in the studios?

Evan Troxel: My fear is that, and I don't think that that is disconnected from, from the topic at all. I think it's right, it's right in, right in there. It's just a different way of looking at it. Because I don't think anybody goes to work and says they're planning on doing a bad job. And I think

that's [01:07:00] why BIM has led us down the path that we're on, which is, it's, it enabled us to put more data into the project.

And, and there is a thinking that more data is higher quality. It's a

better project. It hasn't taken away how much time it takes to do it. And in some cases, in many cases, it actually takes more time to do it the right way. And so that's my fear is that like. Tools will be sold under the guise of efficiency, productivity, um, deeper, higher quality work, but we will be spending more time because it's additive.

Like all of these other communication tools that are swimming around us and distracting us and we're forced to use them because my supervisor sent me an email and now I have to respond to it, um, even though I wasn't planning on doing that today. Because I need this software license back to the earlier part in our, in

our conversation.

Like there's all of these things pulling at us and, and they're all additive. Like there, there's never part of the conversation [01:08:00] is like, okay, what do I deprioritize now? because there's this new thing on my plate all of a sudden. And so that, that's where my fear is. And I, I, I love how you kind of bring it back to quality.

My fear is that it's just more quality. It's just more. And, and

that, because I, we, we've seen this before. Um, I think that there's like a reckoning that needs to happen at the highest levels of leadership in a company, which, which says like, we have to change the way we work. We have to, we have to be productive in the right ways with the kind of output.

Like, why do we exist? We do not exist to process email. We do not

exist to be on call for everyone all the time. And you're a global company. You have workers in Australia. There's a new bill that just passed the Senate. They are the right to disconnect. Have you seen this?

Shane Burger: I heard about it briefly, but yeah,

Evan Troxel: I mean, the idea of it is, is kind of insane and also totally expected, right?

It's

like, I don't have to answer emails or text messages after work hours. And, and what's [01:09:00] crazy is, is like, we're, we're, we're at that point. Architecture has been at this point forever, right? So this is nothing new for architecture, but it's, it's like, After hours is when I actually get work done because I'm so distracted all day long,

right? So, I mean, you have a, you have an Australian studio, right? And, and so I, I don't know if this affects you guys or not. I'm sure it does in some ways, but it's like, it's, it's, this is kind of a, again, like a boiling the frog, like this is just the way it is and we expect it. And, and I also feel like a reckoning needs to happen to say like, no, we're, We do creative, world changing work.

We are creators of the built environment. That's why we exist. And people hire us because Woods Bagot is going to come up with ideas that we've never dreamed of. And, and that's why we chose to, and, and it's like, Yeah, but you, we're spending most of our time processing email and replying to Slack messages,

Shane Burger: and to go back to a little bit of the AI conversation, a lot of that stuff is the, is the sort of [01:10:00] material that I would rather we focus more energy on as an industry to automate or to deal with to get that stuff away. I mean, number one, I have to say, we have always have to ask the question, are we spending time developing automation tools for processes we should never do in the first place?

That's always the first thing, Right.

Should you even be doing that? But for the things that we're doing, are there better ways of us actually providing access to the answers to the question, getting you to the outcomes that you're actually looking for. It's not just that you say you need this big report.

What's the outcome you're looking for? I can probably provide that in a better way,

or I can build in systems or work with tools to help me kind of achieve that sort of goal. Instead, we've gotten excited about, uh, uh, interjecting AI into the creative work. The thing that we, a lot of us love and value and that we think we provide additional value to.

What I'm really appreciating about these conversations that we're having within our practice right now is, uh, in addition to looking at what we automate and where there's [01:11:00] inefficiencies and problems and, you know, any of our processes that we think we can be better at and do better at, we're also asking some real questions.

What is the human intelligence value? Where do we combine it? an AI and an HI or human intelligence component. And what does this help us revalue about what we, as designers, as architects, interior designers, urban designers, consultants, um, uh, value about our work? What, what's unique about what we provide to our clients.

So it's actually turned into a really. Interesting, empathetic conversation, you know, how does empathy come back into it? Understanding what others are thinking, how others are working. I think, I think we're going to get to this point where, um, my reference for this is, uh, the, uh, MIT researcher, Marvin Minsky's concept of society of the mind.

We're going to get to this point. We're going to have. a collection of AIs around us, this sort of society of the mind of AIs that help us automate portions of our processes and the work that we do. [01:12:00] Um, but my hope is that the end result of that is we become much more empathetic designers and people out of that, because we can get rid of more and more of these things that are less necessary for our work and actually bring those qualities, those uniquely human qualities, to the How we design, how we work with our partners here in the studio, how we work with our partners outside, and how we work with our clients.

So I, I think it's, we've hit this real point of tension of where our industry feels like it's not as efficient as it could be, but we're overloaded with things that we think aren't of as great value. I would hope it brings about real questions about what outcomes we're looking for, but also what value we bring to the table.

Evan Troxel: there's a lot there. And you talked earlier about kind of automating away, maybe potentially having to do less, but, but having a higher quality, more valuable experience as well as. I'm curious what you think about the idea [01:13:00] with when AI gets involved in the creative process.

So you just talked about kind of augmenting people, kind of co designing human intelligence, artificial intelligence, augmented intelligence. I don't know. There's a lot of ways we could

play with those words. But what kinds of things are you seeing there that, you know, You said you're playing with this.

You've got a couple other people in the, in the firm playing with this. What potentials are you seeing here and what potential impact do you see it having on the architectural profession? Right.

Shane Burger: So I think the way that I this came up in a conversation with our principals a few weeks ago, and I gave a presentation or global studio just last week about this. We're asking the question. Can AI's be creative? Um, and a lot of this came back to we. presented to the group. What is machine learning?

How does it work? You know, statistical model, uh, that effectively generative AI is just an upgraded version of autocomplete. That seems like I'm dismissing it, but it's actually, that's an incredibly powerful concept. [01:14:00] So it led to discussions about where it can make mistakes, things that can and cannot do.

Um, for example, uh, it doesn't have a mental model of the world. It doesn't have a, a concept of mind, of, um, of how other people think. I know you as a human, so I look at you and I can make some assumptions about your method of judgment and your reasoning that gives me trust in what you're doing. And we can also speak a certain language with each other and understand that there's some similarities in the sort of backgrounds.

But the things that we're looking at were, um, I talked about three different kinds of creativity, um, and I'm blanking on the author that this came from at the moment. Don't have my notes in front of me, but, um, one was called combinatorial creativity. Another was exploratory creativity. And then there's transformational creativity and combinatorial creativity.

Actually, I'll hit the second first. Exploratory creativity is taking the context of a single style and exploring all the potential opportunities that sit within it. Um, and I've seen some examples of this out here when I looked at presentations, for [01:15:00] example, by um, Patrik Schumacher for Zaha Hadid's office.

They were showing how they fed in, Images of Zaha Hadid's work into DALL-E and explored all the potential opportunities that were sitting within that by giving just different descriptions. Um, at one point I can see how maybe that would yield some new and interesting ideas. However, I had to back up for a moment and think to myself.

Those are not Zaha Hadid projects. Those are professional photographs of Zaha Hadid projects. You are not pulling out of them the sort of essences that are really possible with these types of things. it's not that you want to mimic a style. You actually, through looking at the work of other people, want to get your head into the thinking of the artist and architect that created it.

And this system is not permitting you to do that. Um, uh, it is stopping you at a certain point. So that really frustrated me to see that. So then I started to think, okay, well, hold on. There's other methods that are out there. And that's when I get into combinatorial creativity. So with [01:16:00] combinatorial creativity, there might be, ways at which I mash up two styles with each other.

You see this all the time. Um, I saw some great work from some, um, architecture professors at university that were looking at skyscrapers and designs influenced by billowing fabric, and it was gorgeous. It was amazing. And it, it, the ideas that started to pop up for you because it was combining something you knew, maybe it was something that you didn't know.

So it's opening up the wide array of possibilities. And in those sorts of cases, we were also, uh, In our practice, looking at the opportunities for narrative to influence that, so we'd almost tell a story or we describe an experience and see what images and things would come up. And it wouldn't be architecture, but it would be something evocative of a concept, something that got you excited and got you thinking.

So never something you would show a client except maybe if it was like a mood board. It's not architecture. It's a feeling. It's a mood. And there might be. Colors, textures, shapes, things that pop up that [01:17:00] are representative of that mood, that influence your thinking. So that was a spot where we had some level of excitement, but then we get to the third level of creativity, which is transformational creativity.

And that is honestly where you take core concepts that might exist in other professions. Um, it might be, um, allegory. It might be, um, meaning that's derived from particular historic contexts, things that are beyond what you can see just within an image, um, shapes and colors and textures and, and types of movement that have particular kinds of meaning combined with what we experience with our, our bodies.

You know, our, our cognition is embodied cognition. So we have a different kind of experience. That is where transformational creativity comes into play because you've got to take things from other disciplines. That are abstract concepts and apply it to your work. Um, that might be taken from music or dance.

It might be taken from a scientific context or a historic event that happened on the site. [01:18:00] That is where I've seen a lot more interesting innovations and architectures that get to that level of transformational creativity. Those are the things that move our cultural needle ahead, right? Culture is not stagnant.

Language is not stagnant. Style is not stagnant. Those transformational moments really move things forward. We don't get that out of an A. I. system because it's based upon the particular two dimensional representation of what we have seen in the past. So I think what we need to understand is that there are absolutely possibilities to explore ideas and extend our thinking and how we approach work.

But we have to absolutely understand what those limitations are. Um, those, I almost, you know, the way that I've referred to it with our, our staff is, um, Treat it like it's a, uh, junior member of your team that comes from, you know, you know, didn't go to school with you, went to some other sort of school, has crazy, whacked out ideas that they're throwing under the table, and one out of every 50 is going to be worth looking at and [01:19:00] considering.

They're not realistic, they're not the answer, but they create a new space to explore. They prompt your thinking, they get something happening, and that's a value, but it's not the answer. It's not a solution, it's a, it's a space to explore.

Evan Troxel: I did an episode with Ben Guler from Evolve Lab, and they make the rendering application Veras, which is an AI rendering

application for Rhino, and Revit, and Vectorworks, and now Forma, um, and ArchiCAD, and SketchUp. So the, the, the idea that, that we talked about in there was that it's prompting us, and that's why

I bring it up. It's, it's like, it is a feedback loop, right? And so one out of 50 isn't bad when you're in the design exploration,

Shane Burger: Yeah.

Evan Troxel: Because I mean, that's, this is what designers do. Like, it's all a training model. We are

constantly taking input from all over the place, filing it away. You don't know when you're going to use it. And then the opportunity presents itself. You and creativity doesn't happen when you want it to. It just

happens, right? We can't explain that, but [01:20:00] it's like, we're connecting dots. That's what we do as designers. I love talking to you about this, Shane, because, and maybe this is, That's a total aside, but I think it is so important for somebody in your position to come from the practice side. I think that is so key because the things that you're talking about and, and then you get into implementation and licensing and, and

application and all of these things, but, but you're coming at it from a really pure place of like the pursuit of our craft.

And that to me is so important. And there's, there's a lot of people out there. Like you, who are in positions, and I just think like it is a huge advantage for firms to have somebody come from that perspective or that approach or that way of thinking about it, because It's about architecture, and you're constantly

bringing it back to architecture. You're not just trying to solve this very narrow problem. Sometimes that may be a narrow solution to a much larger [01:21:00] piece of the puzzle, um, but you're looking at it puzzle scale, right? And, and I think that that's, that's really cool. It's really interesting to think about the hit rate. of, of interesting things. And that,

that, but that's what creativity is. Like it's, it's funny that people want to throw up a red flag and be like, it makes mistakes.

It's like, okay, I make mistakes, you make mistakes, we all make mistakes. And sometimes

the mistakes lead to unexpected outcomes, surprising things that all of a sudden that's a new path that wasn't available to us before.

Like Bob Ross, the painter said, happy little accidents, right? It's

totally true when it comes to creativity.

Shane Burger: there's an aspect of cultural transformation that comes out of mistakes. There was a debate that we had about six months ago, a playful debate that I was organized in as part of the World City Conference. And it was a two teams pitted against each other around the role of the architect in urban design in a city.

And one group, not necessarily that they actually agreed with this perspective, but three people were picked to be, yes, it's [01:22:00] AI is going to replace the architect. I was on the, no, AI isn't going to replace the architect side. One of the arguments that we made was, this presentation was in New York City, um, a, a, an AI would want to create a city that was hyper efficient, you know, as pure and as clean and as simple as possible,

but it would become,

Evan Troxel: gotta start over. You can't, you can't make a New York City.

Shane Burger: Right.

It would be completely devoid of culture. It wouldn't have any depth. It wouldn't have meaning. There are all sorts of happy accidents, to quote Bob Ross, that have happened in the urban planning of New York City. Now, granted, a lot weren't happy accidents. They were very angry accidents in terms of, um, you know, bulldozing over portions of the Bronx and Brooklyn and disadvantaged neighborhoods.

But there were other things that happened that were in the gaps, in the gray areas, in the mistakes, in the overlaps, in the oddities. Um, it's in the movement from one neighborhood to another, encountering one cultural group butting up against another cultural group. Things that an AI would want to make more efficient and organized and [01:23:00] more productive with a different, completely different set of goals, where we have actually appreciated those accidents and differences and what happens in a temporal quality over time, what changes over time.

Those cultural changes do, uh, are things that, um, do happen in those gray spaces and I think we as humans are very good at operating them. We're also very good at, because we're not a black box, people can have a, again, a theory mind about what others are thinking about. We can work with each other and make our way through these changes and make compromises and come up with solutions together.

Um, those again are some of these unique qualities as humans we have. Uh, and I, I also just keep coming back to, there's, you know, there's multiple types of intelligence that humans have. And those are the things that we have to end up bringing to the table. I do, AI will absolutely be part of our work. Um, Um, and it will be in multiple aspects of our work going forward, but we have to come back and ask the question.

Why are we doing this in the first place? What's the role of our practice? What's the role of our profession in the industry? Um, what's our role in [01:24:00] society and how we interface with the people who are ultimately going to inhabit the spaces that we create? And it's their experience that we should be aiming for.

So if there is a way for AI to help provide a more positive experience for them by helping us do some of our work. By maybe automating portions of work so we can focus on that end user in the end, then absolutely we should do it. And my hope would be anybody leading strategy in a technology practice has to look at it from that kind of perspective because that's ultimately your goal.

It's not just to save money on your next contract with a large software vendor. We have to do that. Yes. But in the end, the reason why you were there. It's to ultimately help the designers in that practice create transformational experiences for the people who live out in the built environment. That's, that's your goal.

If you help them get there, then you're successful.

Evan Troxel: I kind of want to end the episode right there, but I get, I'm not going to, I want to just say

that like it's through failure that learning happens, right?

[01:25:00] And you cannot learn without failure. You're just going to be regurgitating the same old crap. I mean, that's one of my concerns with AI is that we're just going to keep regurgitating the same crap because it was trained on the internet and there's a lot of crap.

There's a lot of garbage in and garbage out. So I, I'm, I'm concerned about that. But, but the idea of. The imperfections in New York City, to your example, like there's something also to be said about it, that it is exactly perfect in all of its imperfections, right?

There's something amazing and beautiful.

And there's these moments. that could have never, you could have never planned for those, right? And, and there's something really special about that. And that is what makes it incredibly human. Like to get back to the whole, why we do what we do part of this, it's, it's for the people and to create experiences and to make their lives better so that they can better contribute back to society and their community and their families and all these things like architecture elevates. The built environment, and it has the ability to do that. We literally, it's so weird that this has come up three times in this episode, but we [01:26:00] literally can change the world, right? And we're concerned about so many things, the, the environmental impact. And there, there's just so many layers to that, the building code and health, safety and welfare and the human experience and all of these things that it's, it's just an incredible profession to work within. And at the same time, like we're so run down. By all of this stuff that happens on the day-to-day basis on the distractions, doing so much email, worrying about licensing and like all that's just getting in the way of

us doing the thing that we're supposed to be doing, that we actually can contribute to the world.

And, uh, I mean, this has been a wonderful conversation to have with you. I, I really appreciate you taking the time to hang out with us today.

I'm really enjoying where things are going right now in the industry. And I, I really appreciate that at least for us in our practice, but this is happening lots of places is the buzz around AI has focused the attention back on human experience and what we do as [01:27:00] architects and what our role is.

Shane Burger: And I, I, in a way, I think people wanted that to happen when BIM came along and it didn't.

Evan Troxel: Mm hmm.

Shane Burger: BIM kind of kicked the can down the road. It automated some things for us, but it didn't necessarily, uh, necessarily increase the Maybe the quality of what was being delivered or the value which we are providing society, if anything, it kind of pointed towards how dependent we are on technology to actually deliver on parts of our work, all those additional drawing sets that we now had to create.

Um, this is actually starting to ask the question, what is our value? What are we supposed to be providing? Um, I don't agree with some of the heads of technology companies who seem to think that on five years, Architects are gonna disappear. It's, they don't understand what we actually provide. But I do think we as an industry have to step up and advocate for ourselves, but also really point out, you know, uh, where there are opportunities to use AI to then provide that kind of unique human value that we do, uh, provide to the built in built environment.[01:28:00]

Evan Troxel: I guess this prompts me to ask you, you know, maybe, maybe a final question, but at Woods Bagot, or maybe just in your head, have you started to think about changes in business model that are going to need to happen?

Shane Burger: Yeah, I think, uh. A few things that have come up for us as we've been asking, okay, if we're, if it's no longer just fee for services, we're not just counting the amount of hours that we're doing for the work and it's not going to be the model of, uh, oh, the fee for that project is, well, I know it's going to take this many drawing sets.

So, okay, that thick of a drawing set costs this amount of money, right? Those sort of models have to continue to disappear. It's not where our value is. They were an easy way for us. Maybe it's similar to what we said at the previous conversation, uh, at the beginning about licensing. It's the easiest way for us to just have an answer of how much to charge, but it's not the value we're actually providing to the end product.

Um, some of the things that come up, um, have more to do with, uh, building performance. So, are there performance incentives? I know Phil Bernstein has talked [01:29:00] about this, a handful of others. If your building performs 10 or 20 percent better than the metric. On particular metrics that were agreed upon in advance with the client, is there an incentive for us that we, you know, get more money associated out of that?

Um, some of this comes down to then proving that through evidence based design. So we've had increased amount of conversations about both, Environmental and building performance, but also social performance, getting into the social sciences and understanding how our spaces are performing and showing that value to clients.

Um, it has caused us to talk a lot more about what our value is and how we might be. partnering with our clients to effectively get paid for what value we're actually bringing to them, their end product, where they want to have an amazing space for their employees or for the public or whatever it is. Um, I don't know that I necessarily have an answer, but it's something we're absolutely like very actively looking after right now.

And there's some real questions as to whether It might be a multitude of answers, depending on the kind of service and the kind of sector [01:30:00] that we're working with. What works for retail might be different from workplace and might be different from residential versus transport.

Evan Troxel: But your leadership is open to having those conversations. And it's not like, this is definitely something that just keeps, the can keeps getting kicked down the road. Right. It's like, maybe someday we'll have to think about that. it's literally happening right now where the

value proposition has to be stated for what, where we add value to the process.

And I like what you're talking about, extending that into building performance over time. You talked about the temporal nature of like that projects don't stop when we, The occupancy happens, right? It continues. And therefore I think there is a huge opportunity for us to continue to have a relationship with a client to ensure that that happens because the prototypical nature of buildings is just that, like we, you have to prove it. once the

building is built, so this starts to lead into ideas about having a real research arm of a company as well, because you can't just ask dumb [01:31:00] questions. You're gonna get dumb answers at the end, and, and truly taking the time to understand. Empathetically, like what clients are experiencing in spaces.

Cause if, if you just send a form over the fence, they're just going to check boxes, they're, they're going to take the least path of resistance to get that form done because they're just being forced to do it, but actually sitting with those users, experiencing space, talking about operations, maintenance of facilities, all of these things that happen after occupancy is where now you're shifting the conversation to a later phase of service and relationship with clients potentially as well.

Shane Burger: we've had good luck with those conversations with a lot of repeat clients, clients that we've done lots of work for. That's definitely happened in workplace, um, and, uh, some of our retail work. Um, but increasingly having those conversations with new clients coming in to say, you know, we don't, we're not just there to build you one space.

Um, we'd like to have an ongoing relationship with you. And our goal is through things like post occupancy analysis, [01:32:00] through building and spatial simulation, all these things is to Uh, take, um, critical insights and turn them into thoughtful outputs. So the answers that we're providing, the directions that we're providing are based upon data and our constant learning of our work as we go from project to project.

Evan Troxel: Yeah.

And that's where this feedback loop with your GPT and your design intelligence could really benefit your firm over time, because you're, if you're continually putting in high quality insights and things you're pulling from clients of projects, and that is generating the feedback loop for what's coming next. You could really see this stepping up over time.

Shane Burger: Absolutely. Yeah.

Evan Troxel: Yeah. Well, again, Shane, thank you so much for taking the time. This has been a fantastic conversation. I'll put links to where everybody can follow you online in the show notes. And, uh, I appreciate it, man. It's been fun.

Shane Burger: Hey. Yeah, thank you so much. I appreciate you reaching out to me again.

Evan Troxel: All right. Until next time,

​[01:33:00]