163: ‘Confusing Evolution With Innovation’, with Nirva Fereshetian

TRXL 163: ‘Confusing Evolution With Innovation’, with Nirva Fereshetian
[00:00:00]
Evan Troxel: Welcome to the Troxel podcast. I'm Evan Troxel. And in this episode, I welcome Nirva Fereshetian. Nirva is a Principal and Chief Information Officer at CBT Architects, which is a Boston based award winning design firm providing services nationally and internationally in architecture, interior design, and urban design.
Nirva holds an undergraduate degree in architecture and a master's degree in architecture and computation from UCLA. At CBT, she leads multiple teams within the digital practice group, including design technology, business technology, and computational design. And in her day to day role as CBT's CIO, she was also named one of the Top Women in Tech in Boston this year.
In this episode, Nirva and I explore the complexities of implementing and managing digital practice within an architecture firm, including the challenges posed by tool [00:01:00] fatigue, the importance of understanding business problems, and the intricacies of vetting and adopting new technologies. Our discussion covers the evolving role of technology in architectural practice, the benefits of collaboration between firms within the AEC industry, and the importance of building a continuous learning culture.
Nirva also shares her insights on integrating technology seamlessly into architectural practice and fostering innovation through effective communication and relationship building. As always, my ask of you is to help the show by subscribing to Troxel on YouTube and in your favorite podcast app to let me know that you're a fan.
If you're watching this video on YouTube right now, please click that like button, and if you'd like to get an email when episodes are published with all the links and other information from the episode, you can sign up at trxl.co. You can also directly support the show by becoming a member at that site as well.
Again, that's [00:02:00] trxl.co. So, thank you for listening, and now, without further ado, I bring you my conversation with Nirva Fereshetian.
​
Evan Troxel: to the podcast. Great to have you and see you again. It hasn't been that long, but it's always a pleasure to
speak with you.
Nirva Fereshetian: Well, thank you for having me, Evan. Um, I have certainly been the beneficiary of listening to so many great conversations you've had with other guests. So, I'm hoping that, uh, this conversation will be a good one for others.
Evan Troxel: I'm sure it will be. I, you know, I want to focus on the practice side and definitely give voice to that part of it. part of AEC tech, right? Because the practice side has to implement, we have to train people, we have to vet the software and the tech and we have to roll it out. And I know that you know how difficult that is, but I want to give voice to that and what [00:03:00] digital practice leaders are dealing with out there in the real world, not just kind of the fantasy world where everything works perfectly because. Turns out it doesn't, doesn't really go that, it's not smooth sailing like everybody
hopes it could be, right? So give us an idea of, of your, what your role is at CBT. I mean, we've, let's assume that I've already read your bio because people listening to this will have already heard it, but introduce what, what you're actually doing because there's, there's a title, but then there's what you actually do at a firm and, and give us an idea of the size of CBT and, and where your
practice is located.
Okay.
Nirva Fereshetian: Right. Um, sure. Um, so the title is chief information officer, but as you said, uh, title is, uh, one thing, but what we actually do in different firms, depending on size of firms or the practice culture, it's a lot, a little different. Um, for me, um, um, for the, due to our size, um, it's everything digital. But my main interest [00:04:00] is that I have an undergraduate degree and a graduate degree in architecture.
So my main difference is, um, the intersection of technology and architecture. But firms our size, I also have to take care of everything else. That is the framework. So, um, a lot of learning that has happened on that end. So, um, we have a business technology group. Uh, Design technology group, computational technology group, and a couple of years before, I've added a knowledge manager and a training, um, um, team member who is attached to our digital practice, um, and not to, um, HR, or, um, so it has been really, um, a journey, sort of, and my responsibilities have grown as the culture and the tech and the, um, implementation of things have changed, um, um, Recently, and more, you know, in the last 10 years, but more recently, right after COVID, um, I think the [00:05:00] opportunity to connect with the business, the opportunity to solve the business problems is what me and the rest of the group are really interested in.
Evan Troxel: and so maybe you could give, paint a picture of what it, that evolution has looked like and, and maybe not every step along the way, but, but what, what do you traditionally see as, as this kind of a role in a firm and what you used to do versus what you're doing now? Kind of paint, paint a picture of
what that looks like.
Nirva Fereshetian: I think the phenomenal difference has been that, um, A lot of, uh, you know, a lot of people have started similar to me, where they have an architecture background and somehow got involved to technology. Um, and, uh, but the major difference I see from now than it was before is that, um, technology has gained, um, to be not really in the forefront still, but to be on the table of the discussion.
Before [00:06:00] used to be, can you make something work? Or are we using the right version? Or can we get on Revit? We're on AutoCAD. But I think now the difference is, um, do we understand what the business does? Can we solve their problems? Can we enhance the, the, the strategy? Um, and so it's a very different role.
Um, especially firms our size. Um, I think if you are in the much larger and you still have a lot of segregation of, you know, infrastructure technology and other, um, things versus digital practice, uh, for our size, um, it's really or interdependent. And I think the main purpose of our existence is to show that it's not about the software, it's about the people and it's about how we implement and how we.
Um, PR it inside our firms. I mean, certainly none of these skills were things [00:07:00] that I learned neither at school nor at graduate school, or so seems a lot of the skill sets that are necessary, um, to, um, implement things is less technical, more, um, I'm not going to call it soft skills, but a lot of understanding, um, and a business acumen, um, uh, Relationship Acumen, PR, everything.
Everything that comes in that,
um, scope. Um, it's one thing to be good at the technology, um, but it's another thing to have those skill sets, and not just for me, but even the team members. Um, they have to have that convincing aptitude, um, and the psychology behind the scenes to make something happen.
Evan Troxel: feel like that's kind of a role of something, at least an outcome that I would like to see come out of episodes like this is giving people the tools to be able to have those conversations because by hearing [00:08:00] us talk about these things, it kind of sets the table for how we talk about technology and the practice of architecture and the merging of those things to give people I don't want to necessarily say the arguments.
It's not like you're trying to win an argument, but at least present these things in a way that, to your point, drives business forward, solves business problems. And that is a great approach to getting technology implemented in firms. It's not just, here's the latest thing that we should be using, but here's why we should be using it or why we should be testing it and trying to find out if this is the right tool to use.
Because the end goal is why do we practice architecture at all? Why do we do things the way that we do them? It's not the tools that we actually use, right? You, you want to define the goals and then backfill that with potential ways to accomplish those goals. That could be any number of technology. It could be any number of people, teams, training, [00:09:00] coaches, all kinds of things to get to that end goal.
But you have to kind of state what that end goal is and then reverse engineer it. And, and to your point, like, Why do we do what we do? What that, that is the real driver and how do we do business? And then how are we gonna achieve those are much more secondary to all that.
Nirva Fereshetian: Uh, to understand the goal is certainly the first, um, Requirement and a lot of team members when they, I always recommend them to go and sit to different presentations, different lunch sessions, even though it's not involving technology, because that's how you understand the business. And you could see their side of the story.
Um, so just set up standards and say, you need to follow them or, or set up things. It's just doesn't work. So the goal is the very primary, but I think moving. Um, Achieving that goal is, um, the key element is how to talk about it, how to present it, how to, not just [00:10:00] internally, but even working with the technology companies, even working with the startups, um, it's how you present and how you receive.
that makes a success. Sometimes, um, they don't understand what the workflow is, although some of them claim to be, have had past architectural experience or, um, not claim, but they really have had it and then moved on to work, um, at a startup. And some do not really understand why are things not working.
And essentially a lot of it is about how you present it and how you talk about it. Um, Technology is factual, you know, does it work or does it not work, or, but a lot of others, the, that, that part you can fix, what you cannot fix is if you've accidentally messed up the implementation, you know, so, um, sometimes you can never have those people back, um, to use the same tool.
So, [00:11:00] um, some things that work in other offices don't work in, um, Our office and vice versa. I think to understand the culture to understand sort of to be in their shoes Is how you can implement? You can't just say well, this is our stamp And why are you not following it or this is the tool we use and therefore we're not going to give you the other tool So it doesn't work that way So
Evan Troxel: how you learned how to do that. If it was just kind of how you're wired already as a person, or if these are techniques that you developed along your journey to get to where you are now, because When I, when I was leading digital practice at my firm, I felt like my success in that role was very much dependent on my career as an architect, getting to that point, working with client groups, learning how to, as a designer, I had to synthesize ideas [00:12:00] from 30 to 50 people on a project into a single, into a real project, right?
And actually implement their ideas and design. And that happens through building consensus, communicating clearly, taking people through a step by step process to get from A to Z, not just starting at the end, right? And so I developed those skills over two decades to learn how to do that effectively. And then when I stepped into digital practice. I could actually do that inside the firm. I didn't have to go outside the firm anymore, right, to do that. But there's various stakeholders of all different levels inside the firm that you need to build consensus, get everybody on the same page, talk about a, a strategy that, that encompasses all of those aspects of training and PR and communication and implementation and support and all of those things. I'm curious how that worked for you to get to, to where you
are.
Nirva Fereshetian: I certainly wasn't [00:13:00] wired like that, so I think it's a and And I think it's, um, the status is always learning and in, in process, you know, so I don't think there is a place you can achieve that you could say, oh, well, I'm perfect at this. I can, I can do any implementation or I can communicate. It's, um, it's personal relationship building inside the firm.
Um, we, I have tried to rely on, um, the team. Storytelling the way our designers, I've tried, I've aspired to do the storytelling that our designers do on a daily basis when they present to their clients. Um, it is about that and it's hard to explain to younger staff who are very savvy in tools and very savvy in coding and computational design and very frustrated when they cannot find the right words.
That, um, communication with the parties that they're trying to [00:14:00] work with. And, um, and I always think that there is a, it's all about human relationships, how we can make, we can understand each other and it's less about technology and it's more about trying to relay, um, my position to them and their position to us.
Um, so how can we bridge the gap, uh, where You know, typical problems are like, we want to, we don't want everyone to do whatever they want, but at the same time, we want to have the leeway for people to experiment. So it's a very fine balance, and I think every day is a new day to figure out how to do it better.
With who? Depends on who is on the other side. Personalities are different. People's experiences are different. There's always, well, we did this in another office or something. You know, so, there's always that challenge that comes by. And, um, yes, it might [00:15:00] be different with clients, with different team members.
And we just have to learn to adjust. But we also have to relay properly why are we as technologists saying that these things are important. So, it's, it's, you know, it's a very collaborative and yet very fractured process to me. Like, the designers at the front end produce things, um, and, um, without really, um, I'm not going to use the word caring, without really thinking through of how downstream.
that might or might not affect, um, other people's work. And then the kind of, the ball is passed forward and other team members take the, uh, model. And then it's passed forward and other team members take the CA process and pass forward to the owner or, so my take has been like, how can we make sure that all of us care about the same thing?
Because everything is connected and it's not just, you know, do my task [00:16:00] and throw it. Over the fence and send it to somebody else and the success of a firm I think is about understanding that and then carrying that success on a project level outside of our firm It's highly corroborative, but very much not caring about the transitional aspects And once those pieces come together, um, you are have a successful project It shouldn't be that hard to convince at each stage that there is something to think about when you move forward Move the baton.
Evan Troxel: You have not once said, and I congratulate you, you never said the word handoff. And this gets back to that communication thing, right? It's like, what words do you use? And, and you're using like, Words that are building, you're using, moving the ball forward, you know, progressing, you're talking about this in a, handing the baton, like it's a progression to the next, who's going to take this and build upon it, right?
Instead of, [00:17:00] The idea of handing off has always been kind of a dirty word in practice, right? It's like the designers hand it off to production, then the production people just grumble, grumble, grumble, hate the designers for all these things that they, no, it's a, how can we smoothly transition and get the most without having to redo work, without having to guess at what somebody was trying to do, without, You know, screwing it up. They did it wrong, and now we have to build, we garbage in, garbage out. Like, there's a, there's definitely a completely different approach. And that, to me, I think, is one of the, one of the really cool things that digital practice enables. And to your point earlier, where earlier in practice, technology was very much kind of an add on menu item.
It was like, well, do you want renderings? And then you're going to pay for those, and you're going to get them at these milestones. And it was really, It really was because it was so hard and it was so time consuming. It really was an add on, but now it's not like renderings are free, right? That's just part of the design process. And that has really evolved. [00:18:00] And that's just one example of this kind of integration, uh, and not only integration, but it's like, Technology is the backbone, right? It no longer is an add on. It is the way that we deliver projects and getting everybody on board with, with that process and how it can be utilized in a very efficient and positive way to enable success at every step along the path of project delivery is really where digital practice is.
And early on when you were just talking about digital practice at CBT, you mentioned off four or five groups. Can you mention what those are again to kind of give everybody a holistic picture of what digital practice is? Because I'm sure it
didn't start off like that.
Like it probably started off as
IT, like that's right.
And, but now it's
evolved into something
Nirva Fereshetian: Right. So, it started as IG T and I was the component of computer aided design or taking care of the um, um, [00:19:00] specific tools for this vertical. But, I have tried very hard the last ten, more than ten years to remove that word word. Um, and not talk about IT, but talk about digital practice being, encompassing all of that.
Um, so there is the business technology, um, which is just, um, basic, um, need for, uh, things to work. You know, um, whether that is internet access, your devices, your communication, and, uh, Um, design technologists who are, um, individuals with architectural background, passionate with technology, try to, try to stay, um, 5 or 10 steps ahead of everybody and, um, do the research.
And then computational design is, um, something we have tried to, um, Plan and do for the last, uh, last 4 or 5 years and now has taken off in terms of the necessity as being part of the design technology. [00:20:00] Colleagues and then, um, the last 1 was, um, something we added right before coven and because I thought that, um, Just parading these technologies without proper training with proper monitoring of those training.
So that's a knowledge manager that we have that manages our learning programs or our individual set up programs. Um, and, uh, lunch and learns, or, you know, I think a lot of it comes from, um, seeing, um, so. The ticketing system is a database of everything, Evan. I feel like if you look at it, you can figure out what is the pulse of the company, where are we lacking, why are they asking so many questions, something is broken, we haven't set it up correctly, or we haven't taught them or trained them.
So a lot of the training ideas come from that. So if it's repeatedly asking the same thing or repeatedly we're having [00:21:00] issues, um, in, um, um, setting up a model or whatever that means that I always say it's not them, it's us. And I want to make sure that there is no them and us. I shouldn't even have used that word.
I've tried to make it feel like we are embedded in their teams, that we are the partnership and not, hey, call them and something's wrong. And, um, so. That is the entire effort. Are we successful a hundred percent of the time? No. Like I said, it's always a new day and a new way of working, but we want to be considered as part of their embedded teams, be part of them, be part of the business.
And even on the business technology side, which is a little bit further out than all the others architecturally, I always tell them that if you don't understand what we're doing, you can't fix our devices. Because you have to understand what the outcome of the business is and what they're trying to do to give any [00:22:00] kind of support.
Evan Troxel: Yeah. That, that's a great point. And so when you said ticketing system, obviously
you're talking about help
Nirva Fereshetian: Helpdesk, yeah.
Yeah, but all these, all these three, four groups look at that ticketing system, you know? So, yeah, so it's one common system. If the, whether there's a computational design issue or a design technology issue or a knowledge issue or some training issue, everybody looks at it. And You know, it's kind of, to me, it's the psychology of the firm, you know, you could really detect there what is the pulse of the firm, what is our, um, uh, support structure, um, how many people are having problems, and so it's, it's a lot of help for decision making, just, just in general.
Evan Troxel: Mm hmm.
Nirva Fereshetian: Are people even, Evan, are people In the right groups, you know, uh, in the right teams with their skill sets, you know, sometimes, as you know, scheduling happens, um, on the [00:23:00] fly in all of our offices. Well, let's grab this person and that person because they're not, they're available. Um, so we can detect that immediately that the person might not be, um, available.
In the right role or might need something to be in help of or training of some kind to be in the right role. So I, I feel like, um, we're trying to connect technology, the right technology with the right people constantly, whether it's inside or outside.
Evan Troxel: Yeah. That, that's interesting. How, how large is CBT?
How many
Nirva Fereshetian: Oh, we're between 200 and 250. Depends when you ask us. Yeah.
Evan Troxel: Okay. I'm just curious because I think, you know, there's smaller firms
that don't have help
desks implemented. Right. And so at some point it becomes like, this is how we manage the flow of information in these ways, like for support or for information, right. That you're talking about. So, uh, smaller firms probably struggle with that a little bit more and they don't have the data to look at.
But I think [00:24:00] this kind of makes an argument for a system like this, because if you want insight into the pulse of. And, and it has to be a thing where people get results out of, or else they're not going to use it. Right. So if you have a help desk and you're just collecting information, you're never acting on it, like
that doesn't work either.
Right.
So people just won't use it. And then you still won't have insight into the pulse of what's actually going on on the floor of your office. So this is, these all go together. And I think what's so interesting about kind of what the structure that you just laid out as far as digital practice goes and how, Yeah. It operates as one unit, but you have several different special roles within that or groups that it really is a holistic, strategic endeavor. And you have to think about it that way, or else it's just not going to be effective in
your organization.
Nirva Fereshetian: right. And I see it like, um, A practice unit, you know, like, you know, interior design is a practice unit and then urban design is a practice unit. And it's a practice unit. That kind of, [00:25:00] um, is the center of all of the practice units to try to help as, you know, it's not only just. One size doesn't fit all outside of our firms, but one size doesn't fit all even inside of our firms, depending on the scale of a project or, um, the typology of a project and, um, the people that are involved in the project.
Evan Troxel: When I used to present the structure of digital practice and how it would be comma thing at the firm that I was at, first I thought about it as like we have these different practice groups and digital practice was a layer that kind of ran on top of all of those. But later on, I switched the diagram to be more like what you just said,
where it's a hub
in the middle. And all of these pieces come off of, but also feed back into. That hub, because it really is, like I said earlier, like the backbone of how we deliver projects. We're not going to do, we're not going to deliver projects any other way. We're not going to deliver Vellum, we're not going to, [00:26:00] right, we're not going to do Blueprints, we're not going to make, we don't have the Ammonia machines.
We're not doing it like that anymore, so we actually have to reconfigure the way that we think about this, so that everybody can use it to its fullest potential. Because if you, if you can't get out of your old way of thinking about the way that technology was implemented as a separate layer, if you can't think about it the new way, it's not going to actually reach its potential in the, in the
organization.
Nirva Fereshetian: Right, and I think it's the hub that, and the success of the hub is how far the extensions are and that relationship. To the surrounding,
um, I don't know what you, whatever you call it, either typologies or studios or whatever you have in terms of structure of an office or practice units, other practice units.
So, if you have, and I've tried to establish that on different levels of communication. So I have a group of people that I've picked from those practice units [00:27:00] as I call them like, um, technology allies, you know, so to kind of run some of our ideas with them. Um, first. Um, to say, hey, is this right? And then also get information from them as the inner workings of their practices and what their, what their experience has been.
Why are people complaining? Uh, what is it that not, what is it that, um, truly not working? Not the technology, you know? So those are, like, not the fix and break things, but what, what is the process? And in some instances it, the solution is ha might not have anything to do with technology, but it might have something to do with the way the process is set up or the, the way client demands are different from other, uh, projects.
So
there is so many factors and essentially, um, I think that we have changed processes. Yes, we don't use vellum and we don't use other things, but in some instances we haven't changed the way [00:28:00] we think. So. We, there, there is this, uh, you know, I think I can give the analogy of if your native language is not English, you kind of end up thinking or counting or whatever in your head with your native language, although you are saying it in English, right?
So I feel that that's the analogy. A lot of people are so much, um, um, rooted in the old way of doing things, even though the technology has changed and it's a PDF now, but, uh, and not a piece of paper. but their thinking hasn't changed.
and, and and that's fundamentally an obstruction in moving forward. And, and that goes outside of our firm into, you know, uh, not change contractual agreements.
Now, I feel in some ways, the technology is a little bit ahead of the game always and kind of retracts a little to support this types of, um, Thought [00:29:00] processes that are not changing. So it's funny because last week someone told me and on a projects like, Oh, you know that, you know, what do you mean the RFIs will be less?
Well, then that party that is benefiting from Making money out of the RFIs is not happy. So, Evan, how, how can you solve that problem when technology is out there?
Yeah, technology is out there to solve that, but we don't want to solve it because certain people were out of business for that, right? So, the same goes to, internally, when we show all these tools about, um, clash detections or other ways of figuring out things and solving problems before it gets to site, then these They ask us, well, are we contractually supposed to deliver these things?
Why are we doing these things? Well, wait a minute. You know, we're,
that's what, yeah. Which is why I said
that it says it's a collaborative firm, uh, collaborative ecosystem. But it's not [00:30:00] actually a collaborative ecosystem because, Um, we have, we're still thinking the old ways, we're delivering in new technologies and I can't wait to see what that AI thing is going to do in terms of that type of process, right?
So,
um, we, the tools have changed but mine, it's hard to change mindsets.
Evan Troxel: Yeah. Yeah. I, for the longest time I said behavior and I found out that people don't like their behavior to change. They don't like that idea, right? So mindset's a better word to use there because it's not so offensive to people. Uh, but, but your, your point is absolutely correct. It's, there's this, picture that gets painted of an ideal future scenario. And the only thing we can actually disrupt is ourselves and our processes, because there are so many hard constraints just outside of the organization, whether it's who's doing plan check or how they're accepting submittals or what's in the [00:31:00] contract, who wrote that contract? How has that ever been updated?
Like there's so many
things that we're kind of butting up against all the time. Like Clifton Harness from TestFit said, if you want to change things. The industry changed the
owner architect contract
like that. The agreement is where you need, you need to start there, not in the digital twin that you deliver, right?
Because like that, that to me is like, you're, you're aiming at the wrong thing. You have to start at the fundamentals that are actually going to have. the ability to ripple throughout the ecosystem to actually create change if you want to see change happen. But so many times we're focused on the shiny thing that looks like it's going to do something when in fact it's just, it's never going to make it because we can't get past the other barriers that are really hard to disrupt because that's somebody's That's where they're making their money, right? There's no incentive there to get rid of that for them, and so why would they? And we fight up against that all the time, and I think it's important for [00:32:00] technology companies to understand that ecosystem approach that we have to operate within as architects and engineers because we don't have control over the changes that are happening over there.
We have to work within the system that exists. It is evolving slowly, um, but it's very slow. Like, let's be honest about that.
Mm hmm.
Nirva Fereshetian: Yeah. And I think, uh, you know, I always, um, you know, there is all these things about innovate and what firms are innovating. And I've spoken in places where the titles of the conferences are innovate, and it's hard to see that a lot of things a lot of us are doing can be labeled as innovate. Um, I think innovate means to me that a fundamental change of the practice overall.
The entire ecosystem, we can only innovate when we get there using different tools and kind of solving internal problems or evolving to better practices. [00:33:00] Yes, it gets better. You know, we get better at it. It gets
less. Yeah, it's not. Yes, it's absolutely evolution. And, you know, I know the reputation is that change doesn't come easily.
Um, to specifically, it doesn't come easily to any humans, but specifically to this industry largely because we are chained to all these mindsets and not until those are collectively worked on and changed. I don't see innovation. I see gradual evolving of things to get a little bit better than yesterday, but I can't see innovate.
You know, there's some examples of, you know. Um, there's always that Uber innovating, you know, the whole process of, uh, the taxi, um, situation. Um, I, I think that's a, like a, um, a complete change of how we do things, um, that can be called, you know, beginning of innovation. But [00:34:00] Swapping some tools for others or creating some automations, which are necessary, um, to avoid waste of time or redundancies or things like that are good things, definitely, but not necessarily innovating.
Evan Troxel: There's confusion around those words because the confusion even comes from within our firms themselves, right? Our marketing departments in our firms want to. Pat ourselves on the back in front of our clients and say, look,
we're innovating. Right. And so there's, there's confusion because a lot of times it's like, well, we're doing AI in our firms and here's some, maybe some different ways that we're doing AI, right?
So that at least we look like we're. Um, but the fact is like, a lot of times that's, that's like innovation theater being put out there and it's not actually taking a foothold in the offices themselves. And, and it becomes this [00:35:00] game that we play with words to position ourselves to get the right perspective, like to, to, I shouldn't say get the right perspective, but to, to tailor the perspective that others
have about
us, right?
And so then we start using those words inside the firms, and then there's confusion, like what's actually happening here? Is it really innovation or is it just evolution? And, and, and words do matter, but at the same time, getting back to kind of, people's interests, like where the incentives are. The incentive is to show that we're leaders.
And how are we doing that? We're doing it through innovation. But how are we really doing that? By automating parking layout. Like, not really, right? So, we are
at odds with these
Nirva Fereshetian: Alright, I, I, I, but I think I've learned, um, you know, like I said, there is a lot of things that I learned along the process of skills that, um, not that I, I, that skills that I should be interested in improving, not that I am there, but perception is everything, Evan, you know, so, [00:36:00] yeah, so, even in technology, perception is everything, even though it is, you know, Technology to me is just black and white.
Does it work or does it not work? You know, so I, I can never be a salesperson because when those people start, they can embellish everything. Yeah.
So, so,
but still perception is everything. Like, I'm going to come back to what I said in terms of how you. How you, uh, present it, how you say it, how you talk about it, and I think, uh, you know, we work with dozens of startups.
It's something that I am very, very passionate about. That it is anybody in this ecosystem needs to contribute to those, all those people that are trying hard to innovate, you know? Do something very different, or go up against incumbents that never Had, had, was not a real reality in the last decade. So I think by contributing [00:37:00] whatever, you know, I think we're a beneficiary of others who've contributed and worked with the, um, startups.
And so we need to put in some things to our share of it. So I feel very, um, passionate about that. And we have worked with lots of them. Um, but I feel like, Them and us, it's all about perception, and sometimes they're not good at showing, you know, um, they're not good at presenting, they're not good at, um, although their product is good.
And sometimes they're so good at presenting, but their product is not good. You know, so, yeah, so, and the same goes for us internally, um, it's how good are we, um, to communicate with all and with all those other practice units and, um, collaborate. I think it's all about how we're perceived. And once we're, you know, we're, once with a bad perception is broken, Evan, it's, it's [00:38:00] like trust.
It's hard to get it back. Right.
Evan Troxel: Yeah, I was speaking with a building product manufacturer just yesterday, actually, and innovation is happening. Evolution, I'll say, is happening in their, in their category of product, but maybe an old version of that project, of that product. didn't fly with architects, right? And therefore the category has been written off.
And it's very hard to reestablish yourself as, well, we fixed all those problems and now
you can count on
us. That's a super hard barrier to overcome. And so you're talking about that from like technology standpoint, right? It's the same. It's, this is a human condition. Like this, it happens in all categories.
It's like, Oh, I don't trust that brand of vacuum
because.
Nirva Fereshetian: You've had one
Evan Troxel: me after a week. It doesn't, yeah, it's, it's all based on experience and it is very hard to, to reestablish, um, maybe a new
version of that in the market once you've already created [00:39:00] a, a bad situation. I want to talk about these startups that you're working with, not necessarily by name, but just in implementation, because something that you've talked about
is tool fatigue.
I've I've categorized it as digital fatigue or app fatigue. It's like more and more of our time is consumed sitting in front of a screen, whether it's a desktop or a tablet or a phone, right? It's just more and more screens. And there's so, we're being inundated with with the tool explosion that's going on in AEC, but everywhere else as well, right?
So they, these do bleed into each other for sure. And you talked about the different groups that operate under digital practice. And I'm interested from an implementation standpoint, because we're getting the fire hose of new tools, especially right now, it feels like more than ever now with, with AI and everything's AI, and there's all these different. Really specific AI tools, not to really
go down the AI lane here, but just tools in [00:40:00] general in AEC. I'm, I'm interested in vetting and implementation and support and training. And just for you to kind of tell a story about how you go about trying to accomplish that. And the reason why I want to talk about this is because these tech companies come to you like they are the only thing that you need to pay attention to right now. Because that's their world, right? It makes sense, but at the same time, they don't really look around and have the bigger picture perception that you have to have as a digital practice leader, CIO of CBT architects to say, we have to look at everything and how everything works together and how we would roll this out to 200 plus people across this many offices, and then we have to support it and we have to train. Like all of that responsibility falls on you. All they have to do is sell you the subscription. Right. And get you to buy into that subscription. But talk about the real world challenges with all of those things. Once it actually gets through the wall and maybe even step before that, how do you, how do you even go about vetting [00:41:00] or trying out or getting excited about these tools that are
on offer?
Nirva Fereshetian: Yeah, I think, I think, um, the, you know, I don't know, there are lists, AEC hub everywhere, over a thousand tools to look at, and,
Evan Troxel: Only a
Nirva Fereshetian: yeah, I don't know, over a thousand or whatever, but also the entire other ecosystem of non AEC tools that there is also, uh, a thousand of them to look at, and I think that, um, It's very much for me that I'm, one of the other skill sets is, uh, uh, I now investigate how they're backed up and what's their VC funding, things that I never looked at before, Evan, like, uh,
Evan Troxel: Because of longevity
Nirva Fereshetian: right.
Oh, because things that, you know, I always say that we're putting bets on the table. Um, and sometimes the company is disappearing. Like, uh, we never attested one, but like, I think the company's named co design or something like after four or five years, they just. Disappeared.
Right. They closed for good. And, [00:42:00] and that doesn't only happen with startups.
It happens with, uh, established companies, you know, like, um, Autodesk decided that they're not going to support Formit anymore, although they, they
really hard pushed it for a few years before that. So it's, it's, um, there is certainly risks. Um, but I think part of it is that I kind of categorize tools. Um, it's very important to look at them as to what process they belong to.
So, for the front end, and which is why everybody, you know, when you ask, does an office use AI, and mostly they talk about the image generation part of AI, because, you know, I think not only that is the most, you know, design seems to be the king of our, you know, it's always the flashiest, uh, role in our offices, you know, so, but beyond [00:43:00] that, it's more of a one to one relationship with the tool.
So. if it's an individual workflow, it's relatively easy to say, well, we can test all of these things. And it's just personal preference to say yes or no. So the examples are that if, if, um, they want to use Verus because they used it a couple of times and they think it's good, or even on a basic level, the, you know, we have designers who want Enscape, others want Twinmotion, others want something else, but those are relatively easy to say, well, we can test it.
And even if we don't. You know, if there's personal prefaces, we can, uh, kind of consent to that, right? So, this designer uses that and not that. Um, but when it moves beyond that, it becomes extremely critical to make, um, try to make good decisions. Um, and kind of pass it through, it says, uh, a couple of things.
Does, is this, uh, uh, solving a problem? Is this better [00:44:00] than what we, is it replacing another tool we have? Is it an adding to another tool we have? Um, definitely. Is it providing some, um, service that we can, um, do now that we weren't able to do before because we didn't have the tool? It has to kind of comply to one of these things.
Is it faster than what we have? So we, Kind of, I divide it to parts. It's some things the design technology team looks at some products as a replacement to an existing product that is not working or people in the teams have heard it or tried something and they think that it solves a problem they have.
So our initial step is to actually create a small, um, testing, uh, group, whether it's inside our teams or, uh, the design technology and kind of validate that before we move on. And in many instances, it's real hard conversations with the [00:45:00] startups to explain to them if that fits or does not fit in our workflow.
So, even established products is hard, uh, to implement if it doesn't fit. So, sometimes there's so many overlaps, um, the product builds a 3D model, but our designers don't want to use anything but Rhino. So, how does that work out? Because then they ask for the plug in to Rhino to that product and not build it there.
So, if you don't understand, um, the workflow, Um, if you're trying to build something, um, where there is a industry accepted, uh, sort of industry accepted product, if you're replacing that, you need to at least be as good as that. Don't come before that. You know? Don't come before that because we're not replacing it.
So there is so many things to look at as barriers [00:46:00] to move, and then there are things that are really expert products, like, I give the example of Upcodes and, um, it just services a small group of people, you know, our code experts use it. But then we proliferated that to say, okay, it's also kind of a training and education for people who are up and, up and coming and trying to learn that.
But that's sliver of a, you know, it's not, it's not really everybody. Um, so the last thing is, the most challenging thing is to implement platform products, which are supposed to be used by everyone. Otherwise it doesn't make sense.
So, and those decisions are really hard to revert. So if we made a mistake, and we don't want to use that, or we want to transition to another product like that, it takes a long time, because all that data sets are there, we have to move them to the new place, we have to train everybody, um, so the having the training [00:47:00] person attached to our department certainly helps, but, um, really looking at all of the implementations in their own context is what we try to do.
We try to make sure that we're not inundating people. So for example, a lot of things are now possible and available in Construction Cloud, including marking up drawings or whatever. So the question is, do we really need these other extra tools? But they're used to it, Evan, you know, so like, it takes a, it takes a, a whole training session to say, well, you could stay in this one product and do some of the things that you're doing with parts and pieces of other tools.
Evan Troxel: Yeah. I think the, the, what you're, what you're saying about implementing at the platform level is it is very difficult because of the reasons it plus, plus cost, right? It's, it's also a very expensive endeavor plus training and all of [00:48:00] the things that you have to do to bring people up to speed and keep them up to speed as it evolves. But then those platforms naturally leave holes, like they can't do everything perfectly well. So we see startups coming in with really specific things that they do and Now we're feeling like okay Well, I need to use this for the feasibility
study then I need to
use this for the programming I need to use this for the Conceptual design, then I need to use this for the design development and construction documents, and I need all these other plug ins to do all the little holes that those platforms leave, and all of a sudden we've just, we've gotta know a lot about a lot of apps out there.
And this is, and then you have to manage that. Your group manages all of the, all of the help desk tickets that come in for all those different apps. And I, and I just, it's worth saying all this because this is what firms are dealing with every single day. And then there's the cloud, and then there's where are the files, and then there's the governance and [00:49:00] the ethics around the AI stuff.
And there's. There's all these other pieces to that puzzle, and it is incredibly complex to manage all that, and have happy users, and get great outcomes, and all of those things, and that's what, that's what you're in charge
of at your firm,
Nirva Fereshetian: Right.
I, I think that we have to learn, um, um, celebrate small victories in order to get the,
the, to kind of have the bigger victories. So sometimes the, these tools plug holes, but you have to really think about, um, was it really worth the time and effort to learn something totally new because it plugged a temporary hole.
Some of them are plugging real holes. and really worthwhile to give it an effort. And the other thing is like, um, the, the, the way some of the startups are progressing is incredible. You know, something that did not work a couple of [00:50:00] weeks ago, they can make it work in two weeks. So you can't just leave them and say, well, it didn't work.
So in some of our instances, um, it's so refreshing to talk to owners and, um, Um, directly or developers directly on the issue, um, and immediately get response and fix it. And those are really, um, great experiences we're having in terms of using products that, you know, develop that fast or change that fast.
Um,
Evan Troxel: Versus the ones that
Nirva Fereshetian: that's right. That's versus the ones that, you know, people have been complacent about, right? So it's not going to work. That's it. We're set where we have 10 different workarounds and that's how we're going to live. Uh, because we know that nobody's going to do anything about it. Yeah.
Evan Troxel: Yeah. Yeah, so, so how do you keep, uh, a, or how do you develop and And just keep a [00:51:00] continued, um, like learning environment going, because there's probably all kinds of experiences around that. There's the, like, oh, I'm just going to keep doing it the way I've always done it because I know it works, and I'm okay with the holes because I know the ten workarounds that I need to do, versus, you know, vetting through a myriad of options of, of promises to fill those holes and finding the one needle in the haystack that actually works. Like, okay, that could be fatiguing just going through that process. Right. And that, that leaves, you could get a lot of different outcomes there. I'm just curious about how you keep this culture of continuous learning going and create. time for people to actually try new products because that's, I think, another thing a lot of firms struggle with, right?
It's like, we have deadlines. We don't have time to figure out if this new tool is going to do something for us. And so
can you talk about that side of
Nirva Fereshetian: Yeah. I mean, time, time is essentially the root of the challenge. [00:52:00] Actually, it's not the cost of the products. It's actually time, uh, to you. Um, implement it properly, test it properly. Some of the startups don't understand that things can't happen in 30 days. You know, so, oh, yeah, you're going to have to give, I'd rather pay, um, and have a paid trial.
So we all can sanely think about it, you know, rather than 30 days and so and so had the deadline and all we good intentions. We want to try it and they'll have a lot of eager people who want to try it. But, um, you know, how the deadline driven are we and how last minute projects change and then people get pulled from those.
So I think. Time is really a challenge. And, um, a lot of times it's the person's enthusiasm that has made a mark, Evan. And people have gone, if the product is good, have gone above and beyond, uh, to test it, even outside of our working hours to make it work. Um, so, but that, I'm not advocating that at all. But what I'm, [00:53:00] what I have tried to do is present the successes through Through, um, others, not through our team members.
So, uh, we want to, uh, showcase in our presentations, them, not us. Is, they trust each other more than they trust someone
saying that, Hey, you know, we think this is better than that, or you need to use this tool and that. So, let's show them. It's all by example. If we haven't been able to successfully make a team use it, make a few people test it, and share the outcomes, then there's nothing to talk about, Evan.
Absolutely
Evan Troxel: like, That's great framing. And I think that's a great way to think about it because it may, and it makes so much sense because it actually makes, it puts the impetus on the information coming from them to you rather than the other way around, which like now you're in a mode
of supporting for success.
Right. But you're not going to go out and find the [00:54:00] things and then
force them to use
Nirva Fereshetian: Right, and it's, it's, if the, we always want, we're always in search of success stories, whether it's computationally, we've helped someone, uh, automate something, or we've helped someone to use a different tool, um, to figure out something, or we asked a, a group of people, like I said, we do have, um, what I call our technology allies inside different practices.
And we rely on them. Um, and some of them have gone above and beyond to test something to a way that sometimes we, we don't have a real project to test on, so we go back and use an old project, uh, that has that scenario and say, can we, can we, if we had this tool, then would it have made a difference? Um, but these are real, but these are real commitments of time and effort and enthusiasm, um, that not, it's not like everybody has it.
So, you, [00:55:00] you kind of have to pick and choose and, uh, accommodate people's schedule, which is kind of hard to explain to our startups. Like, they, once we start, they keep emailing me. So. What happens next? Are we doing it? So, are we going to buy it? And unfortunately, I understand their predicament because they have a certain amount of money and a certain amount of time to prove themselves.
And I think that's the, that's the challenge we have together to minimize. So, understand each other to minimize that. So, it's a beneficiary, we're, we both are a beneficiary of the process. So, which is why I think that this ecosystem needs to collaborate, really collaborate with the big C. You know, so, sometimes, um, for example, I have found it refreshing that, um, some startups have set up calls where many of the people who have tried, like us, other firms, are sharing in the conversation.
It's not just us and the [00:56:00] startup. But we're getting the outcomes of others who have tested, because we cannot do this alone. And so you, lots of people have made lists of some kinds, and I've commented on the list, and like, don't put things in there that you've never, have never touched or know about, you know?
And, and so, or make us contribute and say, we've tested this, and I don't mean in a, In a negative way necessarily, you know, but sharing of our experiences and sharing why it worked in some place and did not work in another or contributing on how they continue to develop the product is really important.
So, one of the other factors is that there remains big name products that are, um, uh, like Rhino and Revit that are the dominant tools and everything else kind of has to talk to them. And if they don't talk to them in the beginning, it's just not going to work. [00:57:00] So,
Evan Troxel: seems like the strategy is, is it has to talk to them before
it can replace
them, right?
Because, because of the, there's so much already invested by the firms into those platforms. It's going to be very tough to switch to something at, at some point anyway, right? So it has to work its way.
The Trojan horse
has to work its
way into the
Nirva Fereshetian: Yeah, and even if it's not replacing them, Evan, it still has to work with them.
Evan Troxel: Absolutely.
Yeah.
Nirva Fereshetian: And, and there's a lack of understanding that and then A lot of overlap, you know, so like I said, so if you're developing your startup and there is a tool out there that is doing some part of your thing very well that I don't see why you're building it.
Evan Troxel: Yeah,
Nirva Fereshetian: I don't see why you're building it. Yep.
Evan Troxel: I want to talk more about your, this, the refreshing change in practice of this, this outward sharing, because I don't, I think that's kind of a, lots of firms have kept things to themselves and they're developing ideas and they're, they want to, they [00:58:00] think it's their IP and they want to keep it to themselves and, and there is much more of a sharing culture developing there.
Before we go there though, I just wanted to ask, how do you, Spotlight these success stories that you talked about with the people who are doing interesting, useful, valuable things with technology in your firm. Do you, do you have an intranet? Do you post those on there? Do you do it outside of the firm as well?
Like, how do you approach that and how do you
actually communicate those
Nirva Fereshetian: We, um, we internally have, uh, sessions every other week or at least, um, at least two or three times a month that something is profiled, something that has been done. And, uh. Mostly, we try to encourage others to present or co present with them. Um, we developed recently, um, a platform called Employee Experience Platform, uh, which is purely based on, um, communication.
It's a communication site. And, uh, Not an intranet. I don't want to use that [00:59:00] word, uh, is that as that is like a documentation and a depository of things and this one, so we just Deployed that about a month ago, month and a half ago, and we're trying to use that also as a way and means of internally sharing that information.
Part of the stuff is like sometimes people complain Oh, I didn't know we knew that or I didn't know we were using that so that's, that's a Equally. So I have tried very hard to pr that externally. Like I said, I've learned a lot and still need to learn a lot to move some of that engagement outside of our firm.
Um, even
I've organized things with our clients, with our internally, uh, with our clients and collaborators to have sessions inside to talk about things. How could we have done something better or how could have we collaborated? It starts small. I think the personal relationships are key. We can put things out there, but it's very hard, [01:00:00] Evan, to make them read, to make them see, and even in the communication site that we're trying to push information to, my take has been like, say short things, put an image so they can, yeah, so they can see like something changed, you know, maybe I should, yes, the attention is
and truthfully, I'm, always worried at the amount of information we're pushing or amount of tools and training we're pushing and I always say that Well, they roll they need to have time to spend to live to live and learn their professional expertise Evan, you know, they're interior designers and architects and urban designers who need to learn and learn Uh, educate, you know, keep, keep, uh, their professional growth, you know, for their topics.
On top of it, there is an avalanche of tools and technology and things like that. And in some instances, some people can't keep up with it.[01:01:00]
Evan Troxel: Yeah. Yeah, the outward communication also I'm sure helps with recruitment and just, just getting eyeballs on the types of work, the kind of things that you're doing, the way that you're going about doing it to attract talent to the firm, which otherwise is kind of a black box, right? It's like they see a job posting on LinkedIn or wherever, and they, they get to read what their roles and responsibilities would be because they're just like everybody else's roles and responsibilities for that job profile.
But, but then there's like, To me, it seems like there's this opportunity for these channels to be presented out there for people to tune into and, and get more insight into the practice of architecture at CBT, as an example, and the kinds of user profiles and wins and success stories that you're talking about, that to me is a great way to get the word out about the culture at CBT and the, and so like the audience there is, you know, people who are interested in that content, but [01:02:00] also people who are job hunting, right?
And looking for a fit for them and their, the kind of culture they want to work for.
So I could see that being
Nirva Fereshetian: Yeah, I think that social media in general, specifically Instagram type things, are mostly translate, you know, um, Mostly they are presenting our culture, mostly it's for recruitment, mostly it's to have an idea of what kind of a firm are we. Um,
really the, uh, I think it's rare that people have found us and even given us a project because they've seen us, uh, um, on an Instagram feed or something.
It's, it helps. After they know about us, or after they talk to us to check out all of those things, uh, to figure out what kind of a firm are we and what are we posting and what are we talking about and what our thought leadership is. So, I have, I think that part of it is that, [01:03:00] uh, learning internal PR is 1 thing also learning how to do external PR and, but also making that as, um.
Not just about technology, not, it can't be about technology, it has to be about the business and our technology things should be incorporated in the project examples or what did it do for the project or what did it do for the team building or because the story is not about the tool, it's the story is about the outcomes.
And technology is just a facilitator to make some outcome better. or create an outcome that we couldn't have created without it. But it's, the story is about the end result. It's not about technology.
Evan Troxel: Yeah. It's why, why
do we do what we do,
right?
If you're, if you're into architecture, if you've chosen this as your career path, it should be to, change the built environment to make a better built [01:04:00] environment to affect, like I did schools, right? It's, it's like to create the best learning environments possible for,
for children,
right?
And tools that help us get there are, are exactly that. They're leveraged to get there faster, better, cheaper. more beautiful. Like there's so many different ways that we could go about doing that. But, but that those aren't why we do what we do, right? Those are how we do what we do and what we use. But the clients often even don't care how you get there.
It's like, just create the outcome. That's the value in it for them. And that's what matters for our
businesses to survive.
Nirva Fereshetian: And absolutely don't care about the tool. Why should they care? All they should care is about the outcome. And even internally, you know, at the end of the day, when there is this discussion about this tool or the other, I always say like, stop and let's go back and ask why are we doing this again?
Why are we doing this? Is it because we're going to change the outcome? So the [01:05:00] basic example is, you know, Enscape has taken off like fire and, um, as in many firms and when other things come into play, um, there's always this workflow issue, you know, like, um, somebody can't pick up somebody else's work if you do it in a lot of different formats, right?
Which, which is an efficiency issue. But, so when, when, Another product comes into play, then we always ask that, yeah, you can use that product, but is it doing something that this other product is not doing? And you, if it's an outcome based, and that you want to put motion that the other one isn't doing well, or you want to put some, um, you know, um, uh, different, um, analysis that the other, then it is rightfully so the tool to use.
But the client doesn't care whether we use A or B, all they care is they ask for something and they got it.
Evan Troxel: It's always interesting to me when a client does kind of prescriptively say we want this to be used on this project and you're like, okay, now, now,
we have to talk about [01:06:00]
Nirva Fereshetian: Yes, yes.
Well, that was a long time ago, decades ago when people wrote in the, in the project RFPs, uh, BIM and Revit, and really didn't know what they were asking for.
Evan Troxel: They didn't
have any
Nirva Fereshetian: they had no clue. Yeah,
they had no clue. And I'm not,
Evan Troxel: hadn't trained
anybody how to use
it. And yeah, any of those things that actually come along with that request. Let's get back to the, that collaboration or, you know, the, the sharing that's going on within the industry that you were talking about seeing on some of these panels that are put together or these, these zoom meetings or whatever they are, but also at the large firm round table that, that you're a part of that I used to be a part of. That was definitely a shift that's been happening is there's been a lot more sharing, and there's a lot more acknowledgement that these tools and these workflows are not IP for a firm, right? They're, it's like, are you having this problem? Raise your hand. Everybody raises their hand. Okay, it's not just us, right?
Let's talk about [01:07:00] this, right? It makes it easier to talk about things when, when we acknowledge like, oh, I thought it was just us. No, it's actually everybody. talk about the culture of sharing the evolution that you've seen there and, and why that's important for the industry to do more of. Because it's,
it's leading to something.
Nirva Fereshetian: Yeah, so at least from that end, you know, in terms of the A, you know, the large form round taper is mostly A's. You know, although some of the firms are, have, um, um, easy, uh, with them, um, there is a considerable effort to, um, share. And as you know, the large firm roundtable from the large firm roundtable, um, a group has developed called innovation design consortium, where it's officially sharing information and being a member of that.
Um, there's, um, It's, it's really, um, not very hard to think that many of us are doing the same things, um, and that could benefit [01:08:00] of making, sharing those, uh, resources or doing it once and sharing it all and not seeing it as a competitive advantage because they're not. Um, so, I feel, so that has started about a year ago and, um, certainly they're making progress.
They have, uh, um, uh, they're trying, they have, it's outside of the large firm roundtable. It started from there, but, uh, it's an independent organization now. And, um, hopefully it gives a voice also to develop things, um, together. Or have a voice to talk to, um, um, with the larger numbers, you know, because, uh, not every firm is two, three thousand people and has the leverage, um, to, um, make a change or request a change.
So, um, but there is certainly common things, uh, computational things or, uh, things that every firm is doing on their own. And we hope that we share that and do it once [01:09:00] and share it. And, uh, so that's, that's moving along. But I feel like, um, The first success of the ecosystem, something has to be developed that kind of goes across, uh, the entire chain, um, all the way to, um, the people who are operating the building.
Um, like I said, you know, before, um, the, it is born in our offices, the data sets as designers, but how we move that downstream and make it at least partially, um, Beneficial down and without recreating it at every phase and rehiring people to It's a very big disconnect. So The same similar way where we all are trying on the A side Share and give a boost to our ecosystem.
And in terms of just time, we share a lot of information about who has [01:10:00] tested what, and that information is valuable when you have a thousand things to look at, you know? So, and, and, um,
if that framework can move downstream, um, and also on every Every process need to be re examined, you know, contractual things, uh, relationships as we move from one phase to the other.
Um, if that becomes more and more thought about and those are the things that give us a heads up how to innovate, how to change us completely. And, you know, I think that, um, in this, um, I'm not sure we can evolve in AI. It's a drastic, drastic change. Um, the fact that we use small tools, uh, um, you know, render, rendering tools, or code tools, or anything, um, is not necessarily, in my opinion, make any difference.
A big use of [01:11:00] the AI ecosystem yet, you know, once the data sets are coming in, once we're making real conclusions, once we have shared, um, data sets where we're making some, um, Deductions from our previous projects, collectively experiences, so that we can project, um, you know, Potential predictions for how should we move ahead with the next project?
And what is the learning that's going to happen across that platform? Those are AI things, uh, which we are still pretty far from.
Evan Troxel: Yeah. Where's the standardized, structured
data between all
Nirva Fereshetian: That's right.
Evan Troxel: How, how's that gonna
Nirva Fereshetian: That's right. We can't even structure our own data in one firm. But I think those are the things that would let us innovate and that's actually the term that we can legitimately use if we do collaborate on that level and, and change the way we think. We still are, we [01:12:00] still are in the old mindsets of how things should be.
Evan Troxel: Yeah, yeah, interesting. I'm curious about this idea of the tools proliferating their value beyond the role, our current role as architects, and what, what the incentive is there, because the business model hasn't changed or is it changing? Uh, the contracts haven't changed or are they changing? I'm just curious what the incentive is.
I mean, there's, I think everybody agrees that that would be great if we didn't have to
redo the
work at all of these different steps and pay somebody to implement that. And it seems odd that that happens, but it does happen because there's no incentive for the, like, like at that point, it
literally is a handoff.
Right.
And so. So what is the incentive to drive that from the architect's and engineer's point of view?
Nirva Fereshetian: It is changing. but not at a speed way. So I think before where, um, [01:13:00] years ago where we never gave our Revit model to anybody, um, that has drastically changed. So, yeah, I mean, even if we gave it, we gave it with all kinds of written statements not to use it, not to measure it from, you know, so,
but now, um, a lot of our, uh, contractors and CMs are saying, well, we want to use the model.
So, and if that means that we need to be a little bit better at building it, or understand how,
Evan Troxel: Can you
imagine? I can't even imagine being a, a Suffolk construction getting Revit models from all these different teams and all these different firms and the different Wild West nature
of every single project out there and having to pick that up and deal with it. It's just gotta be
crazy
Nirva Fereshetian: It is crazy, but the technology's out there to kind of, before when the, you know, years ago when there was this IPD concept, the technology wasn't there to support it. Like, I know we [01:14:00] experimented it with a little couple of different things. Uh, projects where they had to come to our office and, or we had to come to their, go to their office because the structure was not there, uh, we couldn't share a Revit file, so we had to use Revit server, whatever, but now I think there has been the cloud and, uh, posting about all of that content there, uh, makes it really, gives hope that these things are, can be, um, shared and work together.
And if you think about it, I, uh, the, you know, the, if you think that we are one company and do downstream everything, then we would behave very differently.
Right?
So if we are the designers and have the engineers and it's just there is a big company above it and all of us are working for the same concept to make it if but the fact of it is is just so [01:15:00] fractured that no one can see that this is it's a it's possible if we worked for one
Owner, which is, I guess, what the IPD thing was to make an, to make an organization that is, um, one ownership and make sure that everybody, um,
Evan Troxel: In this together,
Nirva Fereshetian: is together.
Yeah, so not until we feel that, I think it's hard to change anything because we don't feel that,
Evan Troxel: Are there tools out there that are making that kind of restructuring of data, maybe even after the fact, easier? Is that even a
possibility, do you
think? Hmm.
Nirva Fereshetian: I feel in one sense, some of these platform based things, um, are making, um, like Speckle and others are, have, I think they have a great future. The problem I see is that we are so much chained in products, um, and before if I [01:16:00] feel that it's, before I felt changing of tools is, uh, uh, an issue. Now I feel the platforms are the issue.
Evan Troxel: Mm
hmm.
Nirva Fereshetian: changing of tools is relatively easier. But because we post and collaborate in certain platforms, um, that is not going to go away. So,
um, it is hard to see, to be optimistic about that. I'm trying, but it's hard
Evan Troxel: that, that is a very difficult reality to deal with, right? Because all of the, the consultants on the team have to also
be using
Nirva Fereshetian: The same thing.
Evan Troxel: the same version of
the software,
right? Not, not just the same platform, the same version, exactly, right? Or else you're going to run
into potential problems.
Yeah,
Nirva Fereshetian: Definitely. Um,
Evan Troxel: Is there anything else that you wanted to talk about before we call it?
Nirva Fereshetian: uh, no, I, I really enjoyed the conversation. Uh, it's been great, Evan. And, [01:17:00] uh, I hope, um, the, I, I hope that these conversations and multi, uh, layer and multi people conversation actually make us, uh, become more aware of how we can contribute to this, uh, ecosystem. I think, um, We do a lot of talking, we do a lot of, uh, planning, but, um, IC not very much action, and all of us complain, uh, all of us are, uh, not happy, um, but I hope that, um, we actually do something about it.
Evan Troxel: Yeah, the complaint department, right? And then, and then the, the accountability part of, of like the next part after the complaint. It's like everybody kind of
looks over their shoulder. I
Nirva Fereshetian: Blaming somebody else, yes.
Evan Troxel: To actually do the thing to fix this problem is not the complaint part. That's the easy part, right?
The hard
part is the actual
Nirva Fereshetian: That's right. I mean, I hope, I mean, I see some [01:18:00] hope on some of those things and some conversations of real change and some conversations of sharing, but, um, there's definitely less action. I mean, uh, uh, podcasts like this are terrific, Evan, in terms of, um, bringing us, um, bringing our voices from different perspectives, from different roles from together to, um, to validate all of our issues.
But, um, what, what is disappointing is there's less, little action and more, um, more conversation. So, I, I do see some data, um, efforts, uh, the common data platforms and other things that, um, several, um, companies or other efforts that are coming together between the, Different European architects and others that are trying to work together for that, but, um, it's just too slow, Evan.
Evan Troxel: Yeah. Yeah. [01:19:00] Well, this has been a
fantastic conversation,
Nirva Fereshetian: Thank you
Evan Troxel: much. And I think just shifting the perspective more downstream, like you were mentioning there, if we think about our work product as Think about the next people who are going to get it. That, that alone is, is something worth contemplating and how it might start to affect what you do today to not incur
technical debt,
right?
Because That's if you do something now that, that just, um, benefits you in the short term to meet this deadline, but it breaks 10 things downstream, it's not worth it. And so to be thinking about
and have empathy for
those future users of
that data is,
Nirva Fereshetian: So, the small example is within the office, but the bigger example is, you know, from design phases to construction. That's the, that's the small example. Think about the other teams, but also think about the larger. workflow of moving it from one, um, office to the other in terms of making the building built at the end and, and operated.
I mean,[01:20:00]
Digital Twins and all of this, all these conversation, um, if everything's going to be starting all over again, and that's really a huge problem to solve.
Evan Troxel: Waste in the
Nirva Fereshetian: That's right.
Okay.
Evan Troxel: Thanks,
Nirva Fereshetian: Thank you, Evan.
​