Bonus Episode: Redefining Client Trust with Warren and Mahoney

A Welcome to Practice Disrupted, a podcast exploring how architects can build better businesses, embrace emerging technology, and create more sustainable, fulfilling practices. I'm your host, Evelyn Lee, architect, angel investor, and founder of Practice of Architecture. Whether you're running a firm, starting your career, or reimagining what's possible, this podcast challenges you to think differently about the future of architecture. Hello, disruptors. Welcome to this week's episode of Practice Disrupted. Most of our conversations I have on this show are about the aspiration to show up earlier with clients, to be in the room before the brief is fixed and the budget is locked. Today, I want to talk about what that actually looks like when a firm does it and what it takes to get there. I'm joined by 2 people from Warren Marnie, the New Zealand practice named one of the 10 most innovative architecture firms in the world by Fast Company.

A Anton Shah is a technical lead and automation specialist who builds the internal systems that make new ways of working possible. Brad Serra is a principal and digital services lead who has spent 2 decades working across New Zealand, Australia, the UAE, Asia, and the US, and who has been speaking publicly about digital transformation in architecture for years. Together, they developed something called QuickStack, a feasibility playbook that puts the client in the room earlier, changes how the architect shows up in that conversation, and has helped Warren and Barney win work they wouldn't have won otherwise. It's made possible by Archl, a web-based design tool that embeds real-time costs and area data directly into the massing model. The moment a design changes, the numbers change with it. One environment, team and client looking at the same thing at the same time. We're going to explore how they built it, what Archl uniquely enables, and what it means for the architect's role in the room. Hi, Brad.

A Hi, Anton. Welcome to Practice Disrupted. I'm so glad to have both of you on.

B Thank you for having us.

A So, before we jump into it, because a lot of my audience is actually US-based, I don't know which one of you wants to take the lead on this, Brad or Anton, but I was hoping that you could tell us a little bit more about Warren Mahoney, otherwise known as WAM, for our listeners who might not know much about the firm and its long history.

C So, Warren Mahoney is a practice with a long history, over 70 years of operation in New Zealand and Australia. But I think the important thing is that we're not trying to operate like a traditional collection of offices. We're predominantly a New Zealand and Australian practice, but the ambition is that the best person for their problem can be involved regardless of where they sit. And that's what we mean by one studio. So, we often talk about one studio at Warren Mahoney. It's not a slogan about being connected on Teams. It means a project in Christchurch in New Zealand might benefit from workplace expertise that we have in Sydney, the cultural design leadership from Auckland, BIM leadership from Wellington, or sustainability thinking from Melbourne. The client should not have to care which studio the expertise comes from.

C For a firm like ours, scale is only useful if it makes it more agile. So, we're 350 people across Australia and New Zealand. If scale, if that scale makes us slower or more fragmented or harder for clients to engage with, then it becomes a liability rather than the strength that we want it to be.

A So, you mentioned 350 people. Can you help us understand the geography of where those 350 people sit?

C Sure. So, New Zealand is quite geographically spread, quite a long, skinny country. So, we have offices up the top in Auckland, which is New Zealand's largest city, in Tauranga, which is more like a satellite office, Wellington, our capital city. I'm working the way down the country. Then in the South Island, in Christchurch, Queenstown, and Wanaka. And then 5,000 kilometers away, which is what, over 2,000 miles, in Sydney and Melbourne, which are also separated by a large distance. So, geographically very separated. So, that one studio network and the ability to be connected through our operations is even more important.

A Well, it sounds like you're on your way because WAM was named one of the 10 most innovative architecture practices in the world by Fast Company. So, it sounds like you're trending in the right direction. Anton, anything else to add to that before we move on?

B I think I'll just talk about my experience and why I wanted to join Wham! maybe. So, I joined Wham! 6 years ago. I went to a conference, and I kind of saw how digital and BIM can influence projects. And I kind of saw how Wham! was very innovative and involved in these digital processes and kind of leading the charge a little bit. And that was something that I wanted to be part of. And so, that's kind of what made me want to join joined the practice and I kind of saw from the outside in a little bit of how we worked, but once being here and I think truly representing a one-studio approach where I'm interacting with people from all offices on almost a daily basis and our workloads are shared across all of those offices, I think it's a very incredible and powerful thing. And it's exciting to be part of because you can be part of projects that you traditionally might not have been a part of that sit in Sydney and Melbourne, even though I'm in Wellington in New Zealand.

A Can you talk a little bit about the differentiation? Because your titles are kind of close, right? Brad, you're a Principal and Digital Services Lead. Anton, you're a Technical Lead and Automation Specialist. So, help me understand those 2 roles.

C I think the easiest way to describe it is we all sit within our digital team. And so, that digital team has a range of specialists. And so, as Anton's title suggests, one of his specialisms is automation. That digital team is 16 people at the moment, and that has a split between people that are internally focused and people that are externally focused. So, internal is about keeping the wheels and the cogs well-greased internally, the walk-up questions, the, I've got the blue spinning wheel of death, what do I do? And the troubleshooting on the floor. And then the externally focused is paid innovation on projects, you know, the BIM management, the implementation of technology for the betterment of the architecture that we do. So, I get to lead that team, which is both exciting and scary. Leadership of that team is more about I guess, overall direction and nudging than telling them what to do, because I cannot claim to do anything that anyone in the team does technically as well.

C But being able to, I think just because I am more experienced, being able to tie those specialist skills together, be across the large geographic and project spread that we have, and make sure those people are in the right place at the right time or connected to the right projects at the right time.

B From my perspective, like Brad described, our roles differ a little bit in the way that we work, in that Brad is kind of the leadership role in helping guide direction of this team, which is fantastic to have someone in that position because they can talk to the leadership level and describe what often people in my— myself and others in our team, we like a rabbit hole. We like to go down deep into the detail to be able to pull out of that and digest it and make it digestible by others is a very valuable thing. So my role is kind of sitting with the team and then understanding their challenges. And I don't know how it happens, but my mind kind of just does it, does its thing. And then we can kind of come back with, with solutions to some of the challenges they're experiencing on projects. And it could be a piece of automation, it could be just a different way of thinking about the problem, it could be Using a tool like Archol, as described as part of this podcast, using things that help people get to their destination to provide a better quality outcome is kind of what I would describe it as. It's not always predominantly about speed or a commercial thing and money. If we get to a better quality outcome, but we do it faster, like, that's just an overall positive thing.

A That's a great leadway into my next question about how Wham! identifies themselves as a strategic partner to clients. I worked at a firm where that's where I like to position myself with clients as well. And I know, Brad, you and I were talking a little bit just as we were prepping a few minutes ago about how you're looking at even expanding what the traditional services that architects tend to deliver. So, when you look at how the firm actually operates day to day, how much of your time does that aspiration, that partnership hold?

B Yeah.

A And, you know, where do you see kind of the biggest breakdowns happening, whether it be collaborative tools or how you work with those partners, especially as you work across different geographies?

C I think strategically, it always sits at the core of what we do. An architect without strong client relationships is a struggling artist in an attic somewhere, I think.

A Although I know a lot of architects that would identify purely as starving artists.

C But I do think that most good architects do want those strategic partners and partnerships. But the problem is that the industry often engages us too late to behave that way. And so, finding strategic opportunities to swim upstream, as we describe it, or downstream, depending where we are in the pathway of the project, to have longer meaningful engagements that mean that we don't have to bid to win. The huge win for us is a non-compete offer where a partner or a client will come to us and say, we know you, you know us, we just need to work together and we'll make it work for both of us as we go. So, if we don't have that, by the time we get into the room properly, often the site's already selected, a pro forma has been tested, the budget's probably got a life of its own and a cost controller associated with that, and the brief's been too far set. You know, the analogy of a cake, you've got everything there, but the icing and the fondant to go around it. And that's often where the architect's left to come to play. And at that point, we can still add value, but we're not solving it within a frame.

C We are solving it within a frame that someone else has already drawn. So, we have this real aspiration to be strategic partners. And our best projects have those relationships at the core of them.

A I think there's also the relationships and how you interact with those strategic partners have changed, right? Especially as new tools have come on board. So, Anton, can you talk to us about life before Archule and what your feasibility workflow looked like? I imagine maybe even start with the struggles of the average architecture firm and how that works, and then walk us through literally the fragmentation or the technology debt costs when it came to sitting across from a principal or a client at a meeting that were like demanding answers that you knew were somewhere but you didn't have access to?

B Yeah, so I guess what, like, my, my background predominantly has come from a technical background. So, I've sat usually in the later phases of a project. I've been there to try and work out how we deliver this building technically and coordinate it all. But this kind of automation lens or the way that I kind of approach the challenges and projects, I started to see some challenges like earlier on in the phases of a project. And some of those challenges are around, yeah, like the amount of tools that get used to produce like a feasibility study or a concept report. So, you know, I think this is a pretty common tech stack that is used by a lot of architects globally, but they'll use something like SketchUp or Rhino as a 3D modeling and massing tool to try and get some rough areas and shape of the building. They then might try and produce an Excel spreadsheet. Maybe there's some automation thrown in the mix to try and help extract from these tools out to an Excel spreadsheet.

B Then there's a manipulation layer in Excel, and then that then gets translated to an InDesign report. And there's a lot of changing hands. So, if you then have, like, your project architect come up and say, oh, actually, I want to add another level, or Could we push that wall out by 2 meters? You then have to reiterate this whole tech stack again to actually get the answer you need at the end of it. So having tools that react live and have rules-based workflows all in one platform give you a much more comprehensive answer and a quick answer to test things and actually test things live. We've heard from some clients that they kind of work where they know the decision they want to go for, but they have to prove up other ways to say like a high and a low range of what they're doing. And that's not really iterative design. That's kind of, they've chosen their design, and they're trying to say that this is the one we're going to go for with these other options being the side pieces. Truly testing things to actually make sure it's going to work, I think, is where, like, real value sits in that process.

B And to have it as an instant answer is really valuable to the team. It is also, like, this is where my technical background comes in. It's also a massive risk reduction to me. So you're not having to manually manipulate all of this data by hand as it goes through these different platforms. It's kind of seamless. There's no extra zero added. And a lot of people are usually making quite large decisions with, like, potentially millions of dollars involved about these projects. So, having that reduced, I think, is very powerful.

A Is that something— I mean, I think a lot of our listeners would say, like, that is, yes, one, that is my tech stack and that is how I do everything. But is that actually something that Oracle brings together? Correct.

B So going back to when I first saw Archol, it was probably about a year and a half ago. I had been sitting with the team, listening to their challenges, seeing a lot of single-player environments being used. So people were copying these files, copy, copy 1, et cetera. It's a laughable joke. Everyone laughs at it, but it is so common. It's not actually that funny.

A Final, final 1, final 2, final 3 for real. Yeah. Uh-huh.

B Yeah. And so All of those things I was watching happen on a project, and I was seeing how they were working, and they just work at such pace to try and get this initial work out early that that's just what they're doing. There's no real alternative in the moment. And then I saw a LinkedIn post from Paul, and he stretched a wall, some metrics updated, and it was a report that was live. And it just blew my mind. It was like a 30-second video, and I was like, a platform that has those things connected, feels like so valuable. And so, that's when Brad and I pinged them, reached out, and we've kind of had this ongoing relationship and working with them around how the tool can be used by us in general architecture practice because that kind of live reaction and risk reduction through pull my shape out 2 meters and tell me what the numbers look like is so powerful, and then hit print on my report. When I first done a project here with a project architect in Wellington, she was like, can you add 2 levels and can we change this wall? I just did it while she was standing next to me, and that kind of blew her mind.

B She was keen to see more, basically, after that.

A Anton, you touched a little bit on risk. Brad, can you put on your business hat and talk about the risk of the fragmentation of that data and the workflow? I mean, even I'm thinking, because I used to lead a strategy studio. Copy-paste doesn't always make coffee, for whatever reason. Those numbers could change between the copy and the paste. So, talk a little bit more about the business risk of that workflow changing numbers and the multiple iterations.

C I think the multiple iterations and understanding a design workflow, if we can call it that, is where this risk happens. We know that design is not linear. It's really a crazy scribble on a page, and that scribble changes every time you do a different project. So, from a leadership perspective, the risk was slightly different to what Anton was talking about. So, Anton saw a workflow risk, and I saw a trust risk. So, if a client is making a land acquisition decision at maximum yield of GFA or a funding decision, they need confidence that the advice we're giving them, the data that we're providing them, is current and is correct and is getting to them as quickly as possible. We know that our clients are making these decisions, hundreds of millions of dollars decisions, very quickly and providing it through to funders and investors. So, if the model's saying one thing, the spreadsheet says another, and the presentation is a day behind that with iterations that occur through that day, we might get the right answer eventually.

C but we've weakened our confidence and the confidence in which we present that in the process. So, often, this occurs most in the early stages of projects. And that's where we can create the biggest value with partnerships like Archol. But it's also where our clients are most cautious about paying for architectural input. So, if we turn up with a slow or fragmented process, we reinforce the idea that we are not essential at this stage and the clients can go about it like they always have.

A You're talking about trust on the client side, and I appreciate that. You have to have a lot of trust in the data, right, that is contained within Arcle to say like, these are the correct numbers. So, what was your kind of first reaction to Arcle, the 30-second video, but also as you dug deeper into the project or the product itself so you could have that trust in the product?

C Yeah, so the first reaction I think was when Anton pointed it out to me. It had come through my feed a few times on various social medias. It stood out as slightly different, but there are a lot of people selling a lot of things at the moment to change the way that architects are working or designers are working. I'd say the first reaction that mattered to me was meeting the team, meeting Paul and the others, and understanding that they're a great group of people with a great background. And a group of people that we could have fun with from the first chat. My secondary reaction, which is probably the one you're really wanting me to talk about, was more a mix of excitement and caution. So excitement because I could, I could see the client value, but caution because the tool's only part of that. So the bigger question for us is, can we build a repeatable Warren Mahoney way of using this tool? So it becomes more than just Anton doing something cool on a project.

C and becomes a repeatable deliverable for our clients in these trusted relationships. And Archol gave us this capability. It gave us the ability to build our own playbook, to have a repeatable, fast response when it's needed most.

A You mentioned this idea too, of you want to build beyond traditional services, right? Architects don't get to the table. as early as they would like, but also they talk about how do we even position ourselves and where's our value there and how do we charge for those services. In a way then, I see Archol as a capability that has allowed you to expand those services into a new space. Can you talk a little bit about that?

C Yeah, I think our use of Archol, we've kind of framed internally, and occasionally we speak about it externally, as rapid feasibility. So, it's the ability to take, before we've got a building with form, often while we might be exploring multiple sites, we have a whole lot of data. And it's the ability to bring that data into a single place and analyze it through multiple iterations of the design. So, before we were using ArchiCAD, early feasibility on a project often felt like a sequence of prepared answers for us. So, we would do the analysis, you'd prepare the options, you'd present the recommendation, you'd probably use a presentation format that we'd used again and again. We'd take feedback from that presentation in front of a client, we'd go away, we'd update it, and we'd come back. And we might go through multiple iterations of that. After integrating Archall into our workflow, this conversation's become a whole lot more live.

C So, the client can sit with us and understand the relationship between the design moves and the commercial consequences. And if we change the height, the mix, the floor plate, or the yield, they could see that effect immediately. They have the numbers in their head, or they can give those numbers to us, and we can put it in, and we can see it immediately change on the screen. And it's a live conversation, a live design environment. And that changes the role of us as an architect in the room. So, we're no longer just presenting a preferred option. We're helping our clients to think. We're becoming integral to their process.

C It's a very different kind of value. It's not a pay us to draw something, and then we present. It's a bring us into the decision-making process, get us to understand your business better, because we can help you test the right questions before that project gets locked in.

A I think there might be some architects that are listening and saying like, that's great, but we carry a certain level of aesthetic in our office and we wouldn't want to put that aesthetic in front of our clients during a client presentation. What do you say to those architects about how Arch Hall has enabled you to work?

C I would question why not, because if you want a truly trusted relationship with someone that's about to spend hundreds of millions of dollars, you kind of need an open book process. You need to, you know, share your dirty laundry, share the bits you're happy with, the bits you're not happy. And through that sharing in a live environment where you can step your client or the developer you're working with through your thought process, they will buy into that process more. It's just about having the confidence that you are really good in that room. And if you've got all of the tools to help prove it, Even if it's someone else driving it in the room, because we know not all architects can use every tool, and no one expects that, it really does become a much more seamless conversation that allows you to build trust, build that relationship, and the amount of information that we now understand about our client's process from a position of before we usually get in the room, and the way that allows us to approach a future bid or a future opportunity, or now bring opportunities to those clients. We had another conversation with client X over here. They're talking about this property and the fact that they can't make it work, but we know the way that you build up your business cases and we know you can make this site work. Let's go together.

C It switches business development completely.

A I would also argue though, because I happen to know that some of the engineers from Oracle's team come from Figma too, it's actually a pretty beautiful product to be working in. I don't know, Anton, if you wanted to talk a little bit about that at all.

B Yeah, well, what definitely stood out was a platform that has been really considered where everything is. They, working with the team, Mike, Aaron, Paul, they really care about how the user uses the platform. They care about the little details. They care about the quality of life features. I think a lot of software often gets developed with the big feature in mind, because then we can get another whole group of people on the hook and we can have like a wider audience. Whereas talking to the Archol group, I can be like, this is really painful to click this button and it doesn't do these small things. And then like, I've— it's blown my mind because there has been things that I have found, I've let them know, and then later that afternoon they've been like, oh, we've fixed it, have another look. And like, I don't think I've ever heard of that kind of turnaround before from a software provider.

B So I don't know if that— if they appreciate me sharing that, but I think it's a very awesome thing.

C I'm just recalling some of the early conversations we had when we were on these calls of what we needed the tool to do. And as Anton said, the responsiveness from the team, not just around the UI/UX, the interface of using the tool, but ensuring that the geometries that we needed to build could be built, that curved facades could be built, Quickly, and the calculations would still work. And the ability to generate a GFA off a box is pretty easy, but the ability to generate a GFA with accuracy off a curved building, I understand the work that must have had to go on behind the scenes to make that happen. And to be able to then push and pull that curved facade live in a room so that you can get, start to get true design in front of a client rather than just I guess, yield metrics early is a true strength of Archol.

B And I think another part to just add as well is Archol has a modeling portion of the platform, they have a metrics portion of the platform, and they have like a kind of boards or reporting area in the platform. And I know InDesign is a very comprehensive platform for producing great visuals and great reports and things like that. What you can kind of do in the Archol boards There's only a thin slice of InDesign, but how far you can actually go at recreating your own reports in there is actually pretty amazing too. So while you might not be able to get a full beautiful report like you would have always had out of InDesign, you can actually get something that is still really nice looking out of the board still, and it's just reframing what's important to have on the page. And I sat with some of our marketing team and showed them what it could do, and are InDesign-only converts, and they were already pretty excited by what a technician— and I always feel pretty proud when I can make someone who's a visual person be like, oh, that's cool— what I could show them that I've done in the background as a reporting piece and how good it could actually look, and it updates live as part of this platform. I think that architects and people in general, we're visual creatures, we're visual people, We are naturally attracted to things that look good or look prettier. So, if we can make our report more engaging, that then in turn gets more buy-in, and more buy-in from people is a good thing for a better quality project outcome.

A I'm always fascinated by new tools and the ability that they have to enable new products and new services to be delivered. You guys kind of played around a little bit with this, and I just want to be clear about the breadth that Archicad as a product covers. So, literally, it puts massing, area calculations, cost data, zoning metrics, and client-facing presentations in one environment where if you update one thing, all of those things collectively get updated at the same time. There's no exporting, there's no relinking to Xrefs, there's no version drift. That enables you guys to produce or think about what a potential quick stack might look like internally, which was, for all intents and purposes, a whole new product or service that Wham! could have been delivering. Anton, did you want to talk a little bit about that?

B Yeah, I guess in a BD phase, or in a phase where there isn't a project yet, I live in Wellington. Wellington, New Zealand has a fault line running directly below it, and we're due a very, very large earthquake at some point. That can sound quite scary. I try not to think about it too much.

A I live in San Francisco Bay Area. I'm right there with you. Yes.

B Yeah. There's a lot of very old buildings in Wellington as well. It was one of the most— one of the first most established cities in New Zealand, I'd say. So, there's a lot of heritage projects, a lot of heritage buildings, a lot of older ways of working, a lot of structural techniques which are performing as well as that you would want them to be performing these days by modern standards. Trying to come up with a system that we can approach clients with to say, have you considered using your building in a different way or with a different function? Or how are you going to go about seismically upgrading your building so that it can continue to function in the city as a piece of the city? Wellington has a lot of empty buildings, which can be quite sad sometimes. So, it's about how can you get re-engagement with these people and get these kinds of buildings and assets activating the city again. And going to a client with something that we can peer pair a bit more quicker, as a very high-level example, is a lot easier to do rather than an onerous and costly exercise internally. If we can pull something together quickly that gets enough engagement that they see value in it, and then we can start an engagement with them, that's kind of how we've approached the Quick Stack tool.

A I want to move back towards this ability to put all of that data in front of the client. So, our call is multiplayer, right? You can bring your client in virtually or live. We talked about how you guys, your reactions when you first saw the product. What were some of the conversations that you were, and the reactions that you were getting from clients?

C Very much the same. We know that our clients have access to analyze all of their databases a whole lot. A whole lot quicker and a whole lot more robustly than what they ever have. So, AI and all of the tools that have come with that offer the ability to take years' worth of development data and do stuff with it. And so, if we can bring a client into a design process and allow them to directly input that information into that process, it's way more powerful for us. It lets us analyze that data at the same time and understand the client and the opportunities more. So we've had, and the speed at which we can move with Archicad, I think, has impressed our clients as well. So, you know, especially when you are working with a developer client, it's all about getting off the ground before their competitor, getting into the ground and then up off the ground before their competitor.

C It's about getting your local approvals for permits before someone else, raising the land value. So, the faster you can analyze all of this information, get it together in a way that explains it to the next step in your design process, the better. And that's where Archolve has allowed us to, I guess, co-design with our clients in those really early phases of a project.

A Who do you see filling that role if architects don't get there? Because I see, you know, as technology comes online, you just said your clients have access to all this data already. So, you know, how big of a threat— if architects always complain about the services they give away and they can't ever get back, I rarely actually see them take action to reclaim that territory. How do you value Wham!'s investments in these type of tech stacks as you think about where you want to be in that client service delivery model? And how you want to continue to grow WAM going forward?

C Yeah, I think diversification of service is critical to our growth. And if we aren't growing and a business stagnates, then it can die pretty quickly. And so, pushing into new areas, which typically are upstream, so earlier than a typical concept design, or downstream, so into operations and that full lifecycle of a project. are critical to our success. And, as you say, if we don't do it, someone will plug the gap, whether for a short time, that's a specialist service, or whether it's the developers who have access to larger funds than ultimately a consulting company, which is what an architecture firm is. They can go and procure a company that might have that service and internalize it. One of the reasons that we are leaning into this is the ability to swim further upstream, get in before concept design, and offer a service that in years gone by, and they are quite a few years ago, and I'll start to show my age if I talk about it too much, we would've done that as architects, probably on paper, probably sitting around an instant cup of coffee, but we would've sat with a developer, with a contractor, and thought through these processes. It would've taken 1 or 2 weeks.

C We can now do that in days. We can work in, as you say, Evelyn, in a live environment with our clients and developers.

A And it's actually helped you win work. Can you tell us a little bit about the Henrietta project?

B I was just wanting to add one part to what you said before, Brad. I think for me, the tools are valuable and what the tools do, but it's what you do with the tools that's valuable, if that makes sense. And that's still human-driven. And that's still whatever that person is using the tool to do to create an outcome at the end of it. That's where the value sits in my mind. So, while tools are exciting and they are very powerful and we can see cool things happening with them, it's still usually a person doing something that they're thinking about with that tool to get the right outcome alongside others. And it's how you collaborate and use the technology together to get the right outcome. Yeah.

C Yeah, and I can speak briefly to the Henrietta House and what the win for us was there. And it wasn't just that we used ArchiCAD to produce a better diagram. It was that the client experienced us as a more valuable partner earlier than they expected. So, we surprised them with the ability to come back with cost and area data before the design was really evolved. And we built a level of trust in a very practical way.

B Yeah.

C They could see that we understand their commercial drivers, not just the spatial ones. They could see that we were not precious about a fixed idea and that we were actively helping them to find the best pathway to a development. And that really helped us win work with this client. It changed the conversation, the regular conversation from us of, here is our design capability, to, here is how we can help you make a better decision before the project exists. Because we were further in the upstream of this project rather than coming in at a concept design.

A I want to dig a little bit deeper on that. There are versions of these stories happening in architecture firms where they adopt Archule, but it's primarily internal. I think it takes a certain type of entrepreneurial mindset to, one, bring the client in, but two, and maybe even a little risk. And we talked a little bit about the messiness of it all in front Can you really talk about the fundamental, like how that's fundamentally changed your relationship with the clients in building that trust earlier and the speed with which that trust happens too?

C Yeah, I think at the core of our best client relationships in Warren Mahoney, they are enduring relationships. And at the core of enduring relationships is understanding and trust. And I have used that word trust a lot, but if we take it out of a business relationship, we take it into a dating relationship or a marriage, it's the same, right? Without the core of that relationship being trust and an understanding of how partner 1 operates with partner 2, it's going to fail at some point. And it's very much the same with clients. And so getting in Earlier, pre-site selection, or very early on once a site has been selected, to understand what those business drivers are from a client. Not the design drivers, not the level of design that they want. Do they want a World Architecture Award, or are they— do they just need to sell these apartments or this typology of building as quickly as possible? Understanding where their successes have been in the past, where their failures have been in the past. their lessons learned, our lessons learned, and documenting that together, coming together in, you know, simple things like GFA and yield, and having absolute trust in that data.

C Because, as Anton's described, as you were pushing and pulling in walls or various blocks of a development, all of that is updating live. In some instances, having the cost controller, or the quantity surveyors, as we call them, in the room as well, building that level of trust and doing calculations on the side that just verify what they're seeing on screen.

A We've been talking a lot about trust, but I think so much of the conversation when it comes to even what leadership is these days and what those relationships are with our client is built around trust. I want to circle back a little bit to what it means to use a tool like this, though, inside a firm. Anton, I think a lot of people struggle with these exciting new tools but you have project managers that are heads down, you're interrupting their workflow, adoption rate really struggles. So, what has that looked like for you all on the Wham! side when it comes to integrating Archol into your workflows?

B Yeah, I guess, like, we haven't done, like, a massive rollout of Archol at the company, if that makes sense. It's usually been more targeted projects or it's projects where we've been involved in this early stuff upfront. And it's been with pretty key people upfront as well, I'd say, like people who are curious, people that want to experiment, and people that want to explore new ways of working. We don't want people to be jaded by a platform because it's a lot harder. So we want to make sure that we're enabling the team to do something either faster or have a better outcome ultimately. a more smoother workflow. So it's grown relatively organically from that. Once someone has heard how this tool works, how much easier it made a few workflows, other people have generally wanted to hear more or get more buy-in from that.

B So we can start to expand. A company, once you start scaling, that doesn't have like standards or ways of working in place can obviously be quite a challenge. So you're, you're widening how people use a tool and then wrangling how potentially hundreds of users use a tool can be quite challenging. So, I think early on, letting people explore the tool and use it in a way that they need to be using it, and then pulling out those key pieces, those key wins, and then trying to share those amongst people. And then working with the team at Archol to share how we're using it, where we've seen the win, and where we can see potential for future wins. So, particularly at scale, I can see a platform like Archol having, like, templates in it, and a project principal or a project architect can jump in and be like, I have a project in Sydney. You click on that, and all of this information is automatically pre-populated. You've got the bones of a WAM report that we can start feeding in our imagery to.

B You've got a whole bunch of the Sydney rules around the zones on a site that you can and can't build in. You've got the metrics that are important. You've got a whole color scheme that we like as Wham! And those templates then become very important for how quickly our teams can work. So rather than having to do— in my eyes, I kind of look at it, let the computers do things computers are good at and let people do the things people are good at, right? And so trying to remove those barriers and remove the tasks that— and let the computers do the things they're good at ultimately and setting up projects and copying stuff from, like, 4 different projects into one, that doesn't really feel like it should be an essential human task. Having a project that, you know, has all the information you need inside of it, and the computer has kind of gathered that for you and told you, here you go, I think is way more valuable to our project teams.

C So, I was just going to add that I think the cultural part of what Anton's talking about is the hardest, especially when we're talking about a large-scale practice of over 300 people. So, it's not, you're not going to get adoption and buy-in to a new tool by applying a license that's downloaded through Software Center and then running a lunch and learn session where you hope that people turn up because there's some food on the table.

A But that's how most architecture firms do it.

C Right. But understanding the cultural reasons that software implementation might fail. So, There are people that have built careers around being very good at existing workflows. So, when you introduce a new way of working, you're not just changing the software, you're challenging their habits, their confidence, sometimes their identity, and sometimes even power structures, which is where it can become very complicated. So, we often get resistance in a few forms. Some people are worried about quality. Some are worried about losing control. Some simply do not have the time to learn another tool or can't carve off the time to learn another tool.

C Some are right to be skeptical because not every new platform deserves their attention. But that's where that digital team that we talked about that we have at Warren Mahoney comes in as the— I often describe it as a combine harvester for these new tools. So, it takes away all of the bad parts of the wheat that you don't need or that don't produce food. Leaves those out on the field, gives the good wheat back to the rest of the team. And so, as Anton said, what moved it from evidence of a good tool to true buy-in is the ability to show a win. And that win comes at different levels. So, for a principal, it's wowing a client, getting the job, you know, the little bit of free work you do upfront, maybe early in feasibility to get an engagement and a contract and a fee out of it.

B Yeah.

C Sometimes it's a win in showing a client response. A client that walks out of the room, felt part of the design, smile on their face, talks about the next meeting before they've left your building. Showing the time saved for some people, and then also showing how the design conversation got better. Not thinner because we did it quicker, but had a better outcome for ourselves as well as the client.

B There's a part that I don't know if it fits in here that I would like to add to that. And I think it's from my perspective with technology and the team and when you're working on these tools and the wins, the first project that we kind of delivered in Archold as a fee piece of work, I actually did it alongside the project architect. And I think there is real value in that because it's just not the digital guy and the team being like, here's a new tool, go and use it, it's amazing. It's kind of like I've understood where the barriers are, and I'm talking with Arch Hall about those barriers, and I'm also talking with our team about where the wins are. So I know what I'm about to tell them to do in the tool, and I know how they're going to do it in the tool ahead of time. It's not like I don't know what's going on and the team are just exploring. There is time and value in the teams doing that, but I'm aware generally of how they can use this tool and where they can get wins on it for future projects.

A Have you guys, just out of curiosity, been ever been able to quantify the time saved by using our tool against what the previous workflow was?

C I don't think we've needed to. No one's asked that question internally. Certainly for other tools, it's been asked. The story we should tell there is that we are able to tailor our fees to better respond to what developers need upfront. So before a developer knows or has framed up what their real opportunity is, They are always very nervous about shelling out money. And so, it is often, in the past, it's been really hard for architects to get money for early feasibility, pre-concept work. And often, it's been seen as business development. But, when you can show real value to a developer very early on in a project, when you can take their data and feed it back to them with a design, And with, I guess, good calculations of that data that can be trusted— there's that word again— then we have been able to generate fees where we haven't been able to before.

A So, when you think about the future of the profession and where you hope to take WAM going forward, what is your hope for architects and what does WAM get By expanding the services that they're delivering?

C I think my primary hope is that we, that we keep existing, right? I guess that's not a hope. It's an absolute desire and a need. When we don't respond to what clients need, when we don't adapt and adopt new technology with the frame of mind that in a service that ultimately is still valued at an hourly rate, We cannot continue to take on endless amounts of new technology without some of that technology replacing previous tools. We need to be able to fight all of that and still enjoy what we do. And the enjoyment of what we do comes from the engagement we get with our clients, particularly in this early phase, by the outcomes that we can generate, that we can create projects where we didn't know there was a project. By, you know, sitting down with the client and understanding their data, that we can expand our services back towards— there'll be some historians listening in that will probably correct me, but back to, you know, Egyptian times and master masons and get the true value of the architect across projects again.

A We become the master builders again.

C Potentially not master builders. But an architect that is seen as valuable by contractors and by builders. Because we are able to take in so much information, so much data, and present that in a way that everyone understands and trusts. So, reduction of errors, an understanding of just how complex it is, the job that we do. I think we constantly undersell the service that we offer as not just as architects, but as mechanical, electrical, plumbing, structural engineers in design, creating a building from nothing is incredibly hard. You look at how complex our buildings are becoming now, even multi-residential buildings, the amount of technology and infrastructure and the demands that people expect when they buy an apartment these days. It's putting more and more demands on design, introduces more and more risk. How do you combat risk? You combat it with trust and with well-defined data that can be shown at every stage and interrogated.

C It's one of the things that Archol lets us do from early on. And as we work with them more and more to develop the tool out, I can see it pushing further and further downstream.

B Using the tools and data to create transparency and trust and relationships at all levels of a project, I think, is very valuable. The fact that I can show my knowledge and share my value to someone else on the other side of a fence in another discipline, to a point that we both now have a lot of trust in each other, that we want to get to a common goal, it allows us to have a lot more honest and frank conversations. If I need them to do something that may be a little bit outside of the scope, But it's going to get us a large win in the future. People are happy to do that when they know they can do the same thing back to you. And overall, some of these wins aren't huge in the amount of time or commercial space or sense. They are small, but they can create large outcomes at the end for the project. So, if we can rely on each other in the project team and trust each other in the project team and work towards a collective goal together, that overall delivers a better project outcome.

A If I'm a firm leader, what would you say to them about using Archicad and why tools like this are so important going forward?

C Yeah. So, I think rather than just a tool, there's a bigger point for the entire profession of architecture here. So, architects don't need to become developers. They don't need to become cost consultants or software companies. But, We do need to become more fluent in the decisions our clients are making before that project becomes a project. That's where tools like Archall help us, because they let us bring architectural judgment into that moment with the speed and the clarity and the evidence that we need. So, the opportunity is not to defend the traditional role of the architect, but as you've been saying, Evelyn, it's to expand it. It's to show up early, to contribute more meaningfully, and to help shape shape the decisions that ultimately shape the project that we can then take through into reality.

A Hi, disruptors. Thank you for joining us today on an episode of Practice Disrupted. If you like the content for today's show, you can find all of our past episodes over on practiceofarchitecture.com/podcast. Be a part of the conversation by joining me, our speakers, and other disruptors in our community at practiceofarchitecture.com/community. Our social media handle is @practiceofarch. That's practice of A-R-C-H. We'd love to hear from you, so feel free to drop us a DM and say hello. Tune in next week for a new conversation on change in the profession.