Natalia Bakaeva joins the podcast to talk about the topics of rethinking data, process, and innovation and discuss the challenges of redundant work, the myth of spontaneous innovation inside firms, the value of knowledge retention, and how AI and purpose-built tools like ARKI are transforming how architects access information. Natalia shares her personal journey from practicing architect to tech founder, offering insights into software design, user behavior, and what it really takes to build a more sustainable and creative practice.

Watch this Episode on YouTube:

Episode links:

Connect with the Guest

• Natalia on LinkedIn
• ARKI website

Books and Philosophies

• Don Norman’s The Design of Everyday Things
  • Amazon Link
  • A seminal text on user-centric design that resonates with Natalia’s drive to create intuitive, purpose-built architectural software.
• Shoshana Zuboff’s The Age of Surveillance Capitalism
  • Wikipedia Overview
  • Amazon Link
  • Examines how tech companies harvest data, paralleling the conversation about architectural firms using internal data more effectively.
• Matthew Frederick’s 101 Things I Learned in Architecture School
  • Amazon Link
  • Offers foundational principles of design thinking, relevant to Natalia’s reflections on education and creativity in practice.
• Dieter Rams’ Ten Principles for Good Design
  • Overview from Vitsoe
  • Amazon Link
  • Philosophy guiding minimalist and meaningful design—ideals echoed in Natalia's software design approach.

AI Tools and Emerging Technologies

• ARKI by Natalia Bakaeva
  • Official Website
  • A platform aimed at surfacing architectural wisdom from project data using AI, as discussed extensively in the episode.
• The Mom Test by Rob Fitzpatrick
  • Official Site
  • Amazon Link
  • A must-read for understanding how to validate product ideas through honest user conversations—directly referenced by Natalia.
• GitHub Copilot for Developers
  • GitHub Copilot
  • An example of AI supporting creative professionals—paralleling how AI could support architects in drafting and documentation tasks.
• Prompt Engineering Guide
  • Prompt Engineering Guide
  • Learn how to talk to AI tools effectively, aligning with the podcast’s discussion about shifting behavior in digital search.

Events and Networks

• Confluence by AVAIL
  • Conference and Podcast Link
  • Podcast and event series supporting innovation in AEC. Mentioned in the episode and co-hosted by Evan Troxel.
• Autodesk University
  • Autodesk University
  • Explore presentations and discussions about evolving AEC tech stacks and workflows.
• AEC Tech by Thornton Tomasetti
  • AEC Tech
  • Learn about the innovation ecosystem where projects are cultivated.

Psychology and Personal Development

• Daniel Kahneman’s Thinking, Fast and Slow
  • Wikipedia Overview
  • Amazon Link
  • Understand the cognitive processes that underlie decision-making—crucial for behavioral shifts in digital adoption.
• Carol Dweck’s Mindset: The New Psychology of Success
  • Amazon Link
  • Relevant to the growth mindset required to evolve architectural workflows and firm culture.
• James Clear’s Atomic Habits
  • Amazon Link
  • Explore how small behavioral changes—like searching differently—can lead to transformative practice.

Recommended TRXL Podcast Episodes

Based on this episode, here are some relevant TRXL podcast episodes that explore similar themes:

• TRXL 154: “Construction is Sick”, with Jim Walker - Discusses industry inefficiencies and systemic issues
• TRXL 165: “Transitioning to Leading People in AEC Tech”, with Phil Read and Adam Thomas - Focuses on leadership and embracing new methodologies
• TRXL 158: “AEC is an Adhocracy”, with Andy Robert and Mercedes Carriquiry - Discusses change management and cultivating resilience in the industry

About Natalia Bakaeva:

Natalia Bakaeva is a registered architect OAA, artist, and placemaker passionate about creating physical forms that reflect diverse cultural influences. She has worked on residential, commercial, healthcare, educational, and public space art projects. Born and raised in the Far East of Russia, her global journey includes Japan, Spain, Moscow, London, and Toronto, where she resides.

Natalia's dedication to the sustainability of architectural practice and diverse background led her to co-found ARKI, focusing on incorporating AI agents to eliminate tedious work in design workflows. ARKI is an AI-powered system of record that utilizes internal data to accelerate future construction projects. Her approach empowers architects to focus on creativity and efficiency, enhancing economic and sustainability outcomes in the built environment.

Connect with Evan

• LinkedIn
• YouTube
• Twitter/X

Episode Transcript:

183: ‘An Appetite for Transformation’, with Natalia Bakaeva

[00:00:00]

Evan Troxel: Welcome to the TRXL Podcast. I'm Evan Troxel, and in this episode I welcome Natalia Bakaeva. Natalia is a registered architect, artist, and placemaker passionate about creating physical forms that reflect diverse cultural influences. She's worked on residential, commercial healthcare, educational and public space art projects.

Born and raised in the far east of Russia, her global journey includes Japan, Spain, Moscow, London, and Toronto, where she currently resides. Her dedication to the sustainability of architectural practice and diverse background led her to co-found ARKI focusing on incorporating AI agents to eliminate tedious work in design workflows, which you're gonna hear more about today.

In this episode, we explore the topics of rethinking data process and innovation and discuss the challenges of redundant work, the myth of spontaneous innovation inside firms, the value of knowledge [00:01:00] retention, and how AI and purpose-built tools like ARKI are transforming how architects access information.

Natalia shares her personal journey from practicing architect to tech founder offering insights into software design, user behavior, and what it really takes to build a more sustainable and creative practice.

A key theme from this conversation, which connects to many of my other episodes, is the challenge of talent loss in the profession.

Stay tuned until the end where I'll break down this critical issue and share concrete examples of what leadership needs to address and hopefully reverse this concerning trend. As usual, there's an extensive amount of additional information in the show notes, so be sure to check those out. You can find them directly in your podcast app if you're a paid member and if you're a free member, you can find them on the website, which is trxl.Co. Lastly, you can really help the podcast by sharing the episodes with your colleagues and by commenting and sharing my [00:02:00] LinkedIn posts. You could also leave a comment over on YouTube for this episode and engage with me and other listeners there. I came away from this conversation, energized. It was amazing. And so now without further ado, I bring you my conversation with Natalia Bakaeva.

​

Evan Troxel: Thank you for coming onto the podcast. It's great to have you.

Natalia Bakaeva: Uh, thank you for having me, Evan.

Evan Troxel: let's start by talking about how you got to becoming a

Natalia Bakaeva: Of course.

Evan Troxel: founder, co-founder. I'm not like, I want you to tell the story, but, um, I know you have a history in the architecture industry that is wide ranging.

So give us, uh, your background.

Natalia Bakaeva: Thank you Evan. So my story starts, um, in far east of Russia in Vostok. That's where I was born. If you know the Berian Railroad, um, that's the city where it ends. So if you think about, uh, getting to [00:03:00] Moscow, which is the capital of Russia, it's about eight and a half hours flight. Just to give you a scale and perspective of where I'm actually from, uh, that's where I went to architecture school, uh, when I was 16 years old.

So for more than half of my life now, I've been an architect and consider still myself an architect. And, uh, it's been a passion of mine. You know, I always tell, um, my peers that. I was so obsessed with technology from day one. Uh, I start using more tech when I was like 18 to the point where one time my professor professors even failed me and sent me to redo a project because they wanted me to do it by hand.

And I did it on a computer, so I rebelled.

Evan Troxel: exactly the architectural profession that I went through as well. It was like there was two people using technology and it was like, what are you doing? Why are you doing te? Why are you using these tools? We want you to use these tools. And it was very much like dictated to you which [00:04:00] tools you will use to do the job.

Natalia Bakaeva: Exactly, exactly. You got it. So they failed me. They sent me to summer to summer kind of resubmission, and I spent, uh, you know, uh, the summertime just redo, redoing this project by hand this time. Um, so that was, uh, my education. We had a lot of, uh, you know, architectural physics, uh, theoretical mechanics, uh, a lot of.

Very robust, like post-Soviet type of subjects, uh, that were brought basically from Soviet Union, that's from engineering school, from civil engineering rather. And uh, from there I thought that, you know, I would like to see bigger picture. I would like to be in Europe and, uh, continue my studies there. So I went to do masters at, um, university, which is a joint program between London Metropolitan University from London, uk and, uh, British Higher School of Design, which is the, was the [00:05:00] school in Moscow.

And that's where I did my masters. And that was the opposite of everything I saw, uh, when I was going through my bachelor education. It was, um, we have a site and you decide what the problem is for this site.

Evan Troxel: Right.

Natalia Bakaeva: So. When we were going through, uh, the Bachelor, uh, you have, uh, technical requirements. You have, let's say a school and the program is 30 classrooms.

Each classroom is for certain amount of people. This is the square footage and go fit it into the building on certain site. Here I arrive into environment where you can build a city or you can build a bench,

Evan Troxel: Mm-hmm.

Natalia Bakaeva: doesn't really matter because if you decide that the problem of this site, it lacks a bench, you should justify and concept explain why.

So, so that was definitely a huge change for me and a big personal transformation [00:06:00] that I had to go through. And then from there I decided not to stop there and, uh, continue my journey and go to North America. Um, I heard that the standards of profession were pretty high and, you know, going through license process was appealing to me and I also knew that.

Just the kind of operational flow and how things are done, um, here in Canada or the us. Uh, follow the standards and kind of the guidelines. And I, I wanted to learn about that. I wanted to be part of that ecosystem. So I came to Toronto. I've been here for the past 11 years, uh, practicing. I got my, uh, certificate of practice.

I got my license as an architect here. And, uh, throughout my career here in Toronto, I worked in small firms, you know, everything from four people team working in custom homes all the way to, you know, multi-billion, uh, healthcare projects with, you [00:07:00] know, 10 plus buildings and team of 60 plus people and 40 consultants on one team.

And, you know, it's like those mega projects and, uh. This is a very long answer to your question, how I got to be a founder. But essentially, no matter where I went, which geography or which type of firm I saw the same problems. Things we struggle with day-to-day as architects, and this is applicable to both principles and, uh, you know, technicians or intermediate architects, they see those problems from different angles, but they all revolve around the same issues in my opinion.

And, you know, I kind of grew to be obsessed with this idea that I can do something about it. And in architecture office, I always felt like there is not enough room for innovation because we wanna be, you know, a hundred percent billable or as much as [00:08:00] possible to kind of squeeze that time. And, you know, even it seemed like there was a desire to innovate inside the firms where I were.

Where I was, but then still there was never time allocated to it. So the only way for me to create this innovation was to create a, A company on my own. So that's how I end up on this journey where I'm still today.

Evan Troxel: It, it, you know, that that part that you just said really sparks this. Memory for me too. It's like there's hope that innovation will just happen as a byproduct of the really smart people working on the projects. And we'll be able to capitalize and leverage that future projects. And as you said, like there's no time allocated to doing those kinds of things. And so what did you do about it? Like you, it's not like you [00:09:00] could make that time unless you wanted to spend that time on your own after hours

Natalia Bakaeva: Yeah.

Evan Troxel: developing that stuff and then bring it back to the firm question mark, right? Um, because you're just so loyal to that. Um, I think a lot of firms think that that's just gonna happen.

Or, or maybe, you know, this is like, the whole idea of hope is not a strategy, right? Like you can't hope this stuff will happen and benefit the business where you're not enabling that to happen within, from within the business. And so what did you do? You went off and you. Started your own thing and I think a, a lot of people end up having to go that route and these companies don't even realize what, how much they're losing by not incorporating that into the practice at all on that level.

Natalia Bakaeva: You are so right about it, Evan. And I think that I have a couple of points to make here based on just what I learned, uh, in a couple of recent years doing this. The work that I'm doing today [00:10:00] is that for some reason there is this illusion that. If, let's say we hire software engineers as architects and we bring them to the office, like, I don't know where are we gonna find the budget for it, but let's say it is happening.

Evan Troxel: Mm-hmm.

Natalia Bakaeva: Um, then we will be able to just build a custom software for every workflow, which I also think that's part of the same problem. Um, you know, we lack innovation first. We don't do anything about it. But then we take this, um, extremely proactive measures. And from what I learned from those firms who did it, it's not effective either because you have to maintain the software, you have to be able to speak with software engineers, and you have to be able to productize the workflow.

So make, make a thing out of it. Right? It's not an easy task. And myself, I'm still learning every day, even though [00:11:00] before starting this company. I, for year and a half, had a chance to work at the property tech startup myself, where I learned about startups, I learned how to speak with software engineers. I learned, learned about customer success and how to, you know, build in public and deliver products that constantly changing and evol evolving.

And it's not an easy thing to do. And you know, I feel sometimes we as professionals first go from a point where we don't have time or we don't do anything about it, and then we go to the next extreme trying to imagine those complicated pieces of software that we will develop in house and we will maintain, we'll run.

And very often I have to tell, you know, those, those prospects of those customers, that's not how it works. I have a software engineer, engineering team working with me and it's still extremely hard to. [00:12:00] Continuously maintain to build, to make sure that there is no bugs and, and, and we are software engineers.

Imagine doing that in the architecture office.

Evan Troxel: Yeah, there's little room for, for those kinds of problems on top of project problems. Right. Um, and, and so, okay, so bear with me for a second because like, I am potentially making a really weak connection here, but I I this idea that you experienced do over when you were in school, right? You, you gave a project, you, you did it digitally. You used digital tools, right? And then they said fail. Go back. do it by hand. Okay. I'm sure. Well, I'm not sure. I would be curious to hear what you learned by doing it that way. If you found any value in kind of going back and doing it again in an analog way. And then I want to draw connection to what you just talked about, which was like, [00:13:00] this, there's this perception that we can just jump to the end.

We can envision this grand thing and that it just appears, right. I think that's what kind of professors used to think happened when you did stuff with digital tools. It was like, oh, you cheated. Right? You didn't use the same tools that I used when I was learning how to. How to be an architect. Right. Um, and so therefore, I want you to do it how I did it.

And, and okay. So there is value in that. I, I bet. Right? And at the same time, it's not like we're never gonna go back to doing things the way they were. And now this weak connection potentially that I'm, I'm drawing here, is like, that's what you're telling architects. You're saying, no, no, no, no. Like, we're not gonna skip to the end.

That that actually isn't a thing. We have to fully understand the problem. We have to develop the problem. There's gonna be bugs, we're gonna have to address those. Software development is hard, just like architecture is hard. And we need to somehow find a way to kind of marry these together. So let's go to the beginning of my, my, my query here, which is like, did you learn something by going [00:14:00] back and doing it again by hand?

Or did you feel like it was a complete waste of time? I mean, you probably felt things, but then there's like the real that may, you know, maybe you did learn something in there.

Natalia Bakaeva: Uh, great question. So I think to begin with, I was very upset, um, because I, I knew that

Evan Troxel: Yeah.

Natalia Bakaeva: like they were holding me back and, you know, I, when I started architecture school, I thought that design is everything. Design is God and all the other things that history of art or we, we had like million subjects again in, in this more traditional education back home.

I thought that they were all unimportant. So when they told me to redo something that has been already created and do it manually, I was not happy to say the least. But in the same time, I was always so obsessed with design that for every project I had, like several [00:15:00] concepts that I wanted to develop because I was, I was just like so hungry.

I would lock myself in the room and I would just spend hours working on my project. You know Evan?

Evan Troxel: design some more.

Natalia Bakaeva: Yeah, exactly. You know what's so funny? Uh, a few years ago, my mom, we were traveling, um, somewhere in the world and she, out of the blue, tells me, you know, daughter, I was worried about you. You could have studied less.

You know how many parents can say that about their children? I was shocked. I'm like, you should be happy. Look at me. I'm so, uh, dedicated to my craft. Exactly. And she's like, I was actually worried about you that didn't look very healthy. I'm like, you just

Evan Troxel: Yeah.

Natalia Bakaeva: describe,

Evan Troxel: you.

Natalia Bakaeva: describe architecture school in a nutshell.

Evan Troxel: Wow.

Natalia Bakaeva: Uh, so yeah, so I get to design another concept that I have developed and I think that was, even though it was in the summer and I really didn't wanna do that, but, you know, [00:16:00] I, I remember this project so well just because I think you right to connect it to what I do today because it stuck with me throughout my career, throughout my life that, that episode that I knew that I'm very dedicated to technology.

I was always. Testing things, trying things out, and talking to my peers and promoting them around. Let's try this, let's try that. And that was kind of my, always my, uh, agenda, if you will. Um, so I, I did use a completely different set setup for this project. So, you know, if the first one was on the white canvas, then the, the, the second one was like an inversion.

It, I took a black piece of, uh, cardboard and I drawn it in a white chalk. So I, I completely reinvented the whole thing and I quite frankly designed the whole new building for it. So, so it was just, uh, another exercise for me. Um, and, uh, I think I enjoyed it at the end. 'cause it's all [00:17:00] about creativity for me at that time.

And, uh, tying it to the second part of the question. I think Evan, you understood it really well, and I know because you speak to a lot of, uh, professionals who are in tech in this industry, that's probably why you, you sense it so well. Because I think the, the danger today is that people hear the word technology or the word ai, and then they think that everything is gonna be now produced automagically for them.

You know, we go from not having things filed at all, just floating on the server to, can we just generate it by clicking a button, you know, it's a, and the gap, as you can imagine, it's, it's absolutely massive. And, uh, I have to sit down and go through the process where every single feature, every single button, every single thing we do has to have a using and a [00:18:00] problem behind it.

Uh, we call it jobs to be done. And for every job to be done, we have secondary job to be done. We have the consequences. We have basically the persona for it assigned. And this is just kinda showing a little bit behind the scenes, but we essentially, coming from a generation of software developers where we don't want to end up with another sales force, we don't want to end up with another Revit.

We want to build the software that is absolutely clean in the sense things that are needed, they will be there. And if we can remove something, we'll remove it. And that's why we have things like reporting and, and maybe we sometimes thinking how to eliminate certain things and make them lean, make them more intuitive.

So I would describe it as being closer to Apple, [00:19:00] maybe. In terms of how you approach things and sometimes sculpting, like subtracting rather than adding, right? So that's the way, that's the way I see it, uh, in a nutshell.

Evan Troxel: And I think those kind of design ideals go back to masters. I remember following Johnny Ive at, at some level and him always referring, well, maybe not like outrightly referring to, but definitely far as like ideally referring to de Rams, right? Like these 10 principles of good design,

Natalia Bakaeva: Yep.

Evan Troxel: it's like nothing is extraneous. There's nothing else there that that shouldn't be there, right? And this idea of subtraction cleanliness and all of those things are definitely kind of in that design ethos that you're talking about. And so you're applying kind of very design centric principles to software design in an architectural a EC environment. And then going back [00:20:00] to my, my really weird question about kind of drawing these parallels, like you also probably learned. different approach and a different understanding of how to create using a different set of tools. And I'm sure that that also applies to you're doing now in firms.

Like you have a background as an architect and you're understanding the problems that they're dealing with and then talking with those individuals, just like an architectural design problem, to solve that problem for them instead of, you know, saying, here's the package that sits on the shelf, take it or leave it with all the extra stuff that you don't need potentially.

Right. Usually, and we only need it to do these few things, but you gotta buy the whole thing. You're talking about crafting very purpose built thing. And so I'm, I'm curious if you could just kind of the audience here on the kinds of things that, that your company is building for architecture firms, because [00:21:00] I think we still haven't really addressed that piece of context.

Natalia Bakaeva: Yeah. Yeah, for sure. Sounds good. So I think in a nutshell, the problems that I've seen in the industry related to information and data access, uh, I'll tell you a story, um, that happened to me during COVID. It was in the middle of pandemic and we were all locked up at home. I was working for a, a very great firm, which is now a customer of ours.

And, um, I was an, an architect on a new project that we got and, and it was a food processing facility where the construction didn't stop, didn't stop during Covid because of, you know, the immediate need at that time. And because we had to rush into remote environment and, you know, we didn't really have processes for it.

And the project was very tough. The client was tough and the [00:22:00] construction was, you know, chaotic as it typically gets. And also plus Covid with all the delays. I found myself one day at 2:00 AM at home, locked up. My family's back home, you know, I don't have family in Canada. And uh, at 2:00 AM I was drawing a simple.

Kitchen for a staff lunchroom. And I was just thinking to myself, this firm is 65 years old. They've done great projects all around the city. They've done all sorts of typologies including like, you know, universities and some, again, training facilities. Many things. And I'm sure what I'm drawing right now has been drawn at least a thousand times.

And I'm,

Evan Troxel: times. Yeah.

Natalia Bakaeva: and I'm tired and I'm exhausted and I'm here by myself and I'm probably gonna make a mistake. And it's a very tough client, so it's [00:23:00] probably gonna become an issue. And then it's probably gonna be also changed 10,000 times where, you know, there are improvements to be made, which we also didn't track because I'm sure if we drawn it a thousand times, we learned 99.

A hundred times, you know, uh, 99, 999 times we, we learned something about this detail. So with all of this, uh, it kind of stuck with me and that's essentially what I brought to our CTO Medi, who is my co-founder. And I was like, listen, this is what we do. This is how we do this. And we jumped on a call with hundreds of architects and we flagged this hypothesis that, you know, potentially data is a problem, data access is a problem.

And, uh, that led us to [00:24:00] about 85% validation of all the questions we asked. And we never asked the right questions like, would you use this software? We said, what is the, we asked them, what is the worst part of your day? How do you. You know, why did you quit your previous job? And you know, when people go through this, uh, we call it the mom tests, right?

So you kind of ask them basic questions. When you hear them start swearing or really express their emotions, that's where yeah, that's where you know, and you start digging deeper. That's how we came up with the concept that, you know, we think that internally there are thousands of units of information that each firm has.

We have a technology today that is allowing us to tap into this knowledge. And then, then, as I already said, we have different stakeholders in each firm. And for each stakeholder, that would mean a different [00:25:00] thing for an architect's architect or draft in personnel, that would mean that. You know, they can be more empowered.

They can feel like they join this new team and they can really, you know, be excellent and find those insights and very efficiently leverage them and come prepared to the meetings by sourcing this information ahead of time. You know, for principles and decision makers, that would mean that they are able to predict the projects better.

They know how much information they already have, they can leverage versus how much of the new data they need to produce or create. And at the end of the day, if the team is more productive, maybe they can either take on more work or maybe they can let the staff go home earlier. They can be more sustainable design practice, which, you know, majority of the architectural offices really struggle [00:26:00] with.

And at the end of the day, if we are a medium sized firm. And we use the technology effectively. Maybe we can even scale without growing the headcount. Maybe we can compete with larger firms or sometimes, uh, we can even think of retiring architects, right? So retiring architects, they exit in the workforce.

And what we hear today is that intern architects or junior architects who joined firms during pandemic, they didn't get proper training. They didn't get that, you know, situation where you have your principal sitting by your side and sketching that detail and explaining to you the workflow how these things come together.

And they really lack that knowledge. At the same time as retired, if retired architects, they exist in the practice, they are not able to transfer that knowledge, that information. And you know, if we are talking about just the digital, uh, leads and, um, you know, [00:27:00] kind of IT stuff and anyone who is dealing with technology, we see that there is a huge problem with fragmentation and not being able to sometimes compile information effectively due to different formats due to the way the data is organized and stored and just the way we set up the practice today and how the search works, right?

So with all this information in mind, with all those angles, with all those stakeholders, we came up with an idea of a platform where you can access, uh, your data from any device you don't wanna be pigeonholed to, you know, either Autodesk ecosystem or you know, windows ecosystem. You can see your data on pc, on Mac, on iPad, on your phone, if you're on site and you can use just the human language to explain to this machine, what are you looking [00:28:00] for?

If I'm drawing a kitchen counter detail, I don't want to go and talk to 10 people asking me, asking them about this specific one detail that we have done. I want to just type kitchen counter to my search engine, and whatever data exists will be pulled up. And why we are different is that today there is a literal search, right?

You can essentially search for this data if it's tagged, if it's labeled, if it's certain, certain way. Because today with AI, we can search semantically and we can also search visually that what gives us this incredible advantage of something is not being noted. Like, let's say a grab bar, but exists in the drawings, you can still able to search for it and retrieve that piece of information that in today's day, if it's stored somewhere far, you will never be able to identify that.

Let's take [00:29:00] a quick break from the conversation to tell you about Avail. Is your team struggling to find the BIM assets they need? Avail's content management system simplifies access to all of your firm's content in one easy to use platform. No matter where your files live, or what type of files they are, you can easily search and access them from Avail.

Evan Troxel: Now, designers can consistently find and reuse all types of content. So what does that mean? Well, standards compliant models and drawings are easier to create. The documentation process is less chaotic, new hires are easier to onboard, projects are delivered faster with fewer errors. You get the idea.

Visit getavail. com to try Avail for free and request a free demo. That's getavail. com, G E T A V A I L dot com. My thanks to Avail for supporting this episode of the TRXL podcast. And now let's get back to the conversation.

I just wanna point out, [00:30:00] Natalia, that you just mentioned, element of a design that I think is so reassuring for you as a software developer. You, I mean, you talk about a grab bar, right? In a bathroom stall, and it's like, you know what that is, right? Like, that's gotta be reassuring for architects. Um, the, the thing I want to the, there's this mental framework and I think it might help here, which is. There's data, like you said, that access to data is, is kind of the, the common pain point, right? And so there's, there's data and then there's information, and then there's knowledge, and then there's wisdom. Like that's kind of the information hierarchy that I think of. And data is, is one of a, the smallest, low level piece of that.

And then wisdom, right, is kind of this high level. We don't even understand how that really works kind. It's kind of magic at some level. It's like, because it has experience, it has a lot of experience, years and years, decades of experience tied into it of real world outcomes and mistakes [00:31:00] and failures along the way to get to that point.

Right. And what you're talking about is kind of, you're, you're kind of hitting all those levels, and I think you're using the, the same word though, data, right? Or, and, and you said information maybe at one, one point there, but I really think that, you know, when you are talking to somebody who's, uh. A BIM technician, right?

Sometimes they're looking for data and sometimes they're looking for knowledge and sometimes they're looking for wisdom, right? And, and when they're coming prepared to a meeting with the right information, it's like, because this is the way architecture has been practiced forever. And you're talking about people who haven't had the opportunity to sit in an office and learn through osmosis of having a principle over their shoulder saying, move the toilet three inches that way.

Here's why. Right? Or, you know, you're, you're dimensioning these studs and you're not thinking about all of the different treatments that are going to be applied to that surface, and then all of a sudden it's gonna bust your a DA requirements, right? [00:32:00] And so it's little things like that, that, that you're right, people haven't had the opportunity.

And so I wanna find. An example, but I also want to understand that example. Right? And so when it comes to capturing that information, we suck at that. We don't capture it. We, we pass it on verbally, we pass it on through red lines without an explanation. There's a lot of different ways that that information makes its way through the generations of architects. And it's nuanced and it's complicated, right? And, and you kind of have to live it at some level. And so I, I'm just curious from, from your point of view, like what, how do you, when you're talking to leadership in firms who are paying for your services or paying for tools or, you know, making those decisions, like how do you that kind of information?

Because they aren't, like, sometimes there's a, there's a sentence in an email that, that explains that sometimes there's, you know, a conversation and, and it's like, how do they. [00:33:00] Capitalize on those people who are walking out the door with all that information. I mean, I recently had a, an interview on the Confluence podcast with Rob Otani of Thornton Thomasetti core studio, and he talked about like, they had this incredible resource, they had this project engineer who had decades and decades of experience and he got to the point in his career where they actually said like, don't work on any projects explicitly, just, you know, be in the office and answer questions.

And he would, in a very detailed way, explain in emails why things were the way they were when somebody came to him with a question and they were able to capitalize on that and build an AI system that kind of answered questions based on years of his emails with his blessing. Right. Um, I'm curious how you convey this to your clients or just now on the podcast to people who are out there.

It's like, like this is a. Like you're staring at a mountain right now of like, where, [00:34:00] here's where we want to get to. How do we get there? Climb the mountain, right?

Natalia Bakaeva: Yeah, great question. And this, as you can imagine, comes up every day and, uh, when we do demonstrations or we talk. Talk to prospect firms. The concept of archive is not new concept and, uh, storing the data and searching through the data. So we get this question that, you know, what is so special about you guys?

And, uh, because we used this to certain way as architects, as engineers, sometimes it takes more work to undo what we think is right than actually explain from this blank slate. Because the problem today is that we still treat our data as a conventional archive. Yes, it is tagged. Yes it is labeled, but essentially we do the same thing we do in a physical library.

And before we put this book away, [00:35:00] we assign a number to it, and now it can be found essentially

Evan Troxel: Mm-hmm.

Natalia Bakaeva: what we do. And you're right, we are currently in the data ingestion mode. That's exactly how it works because that's a step number one. And that's what I always try to explain to people we work with. Because you cannot skip steps here, even though there is AI in the mix, even though the technology is way more capable today than used to be, there's still data pipelines, there's still steps in the product development that needs to be done.

So when you ingest the data, what we do differently essentially is that we process the data on the backend. So there is no manual work for you to do when you want to file your information. And you know, we started with construction details just because it's a kind of simple unit that explains work and it's applicable throughout geog different [00:36:00] geographies.

We are working with five countries now throughout different type of firm. If you are. You know, working in healthcare or in corporate interiors, you're still gonna draw a bunch of details to describe your work. So we moved away from construction details and uh, now we also include sections we include in large floor plans.

We include, uh, different types of information that can bring value, right? Because what we wanna do as a step one to ingest the data and the time that we save on manually tagging the data we can now use to actually start layering that information so we can move to wisdom exactly like you said. And by layering the information, you would be added notes, which we currently already providing.

And that came from a notion where I always saw principal architects or senior architects. At my firms [00:37:00] where they saw Revit, they never worked at it. They saw PDF drawings, they briefly saw them, and then they had an email. That's where they communicated. So I felt like there's never a place to layer up the business data to the drafting data.

What it actually mean to execute this detail when we build it previous time on site. Did it work for us? Was this product maybe discontinued? Maybe the code has changed. How do I deposit this knowledge? Maybe detail is okay, maybe I just need to change the thickness of the insulation and it's gonna be good to go, but where do I place that knowledge today?

How do I attach it to the piece of, uh, architectural engineering data? And then from here we can start collaborating on the data. That's something that we also missing today as architects in these firms, because again, it's either Revit or it's file server. Or maybe we communicate on teams or email. I wanted to create a [00:38:00] place where as a team we can bring bunch of learnings.

Maybe we worked on different projects before and now we wanna join our forces. We want to create this compartment where we add those pieces of information and then we have a conversation, right? We, we now can start from 50% and take it to a hundred instead of starting from zero. All of this, and as you said, needs data, right?

Like we know those, those systems are data hungry. We have the big data problem from day one. Day one, because for it to work work effectively, you need to be able to add information there. Like you need to have a good sample size of data. And if we are talking about the vision and the roadmap and where we going, that's where wisdom comes in because.

What we are working on today, and this is an active development, we wanna be able to quantify [00:39:00] the business side of things and layer it to the architectural and drafting side of things. Because today, I think the biggest problems, and that's why, for example, investors criticize us. They say that architects and engineers, they struggle with profit margins.

So it's very hard to build, to build a software for someone who is struggling with making a profit. We are going directly after that problem. We wanna be able to layer up the business data with the drawing data and almost assign a price tag to every unit of information, or the time tracker or some sort of.

Quantifiable measure that will tell us how we can predict future projects with our internal work today. That's our North Star. We wanna create a value in between that. [00:40:00] Currently they do not have access to because you know, like you can still figure out a way how to store the details you do on PDF. Maybe you do it on, you know, paper, like there's a work around that.

If you really committed to it, right? You can spend way more time. You can talk to 10 people, but maybe you'll find that, maybe not, but there's a chance. What we are really excited about is delivering value that currently is not being able to be extracted in house. Um, maybe looking at Revit metadata and layering it over business proposal data and figuring out the commonalities, figuring out the patterns, figuring out what can be.

Learned here that can help us to be more successful when we work on future projects.

Evan Troxel: That sounds really complicated. I'm, I'm curious how you're doing that, because often these are in [00:41:00] very silos

Natalia Bakaeva: Yeah,

Evan Troxel: of an office, not

Natalia Bakaeva: I,

Evan Troxel: technology wise, but people

Natalia Bakaeva: yeah. Yeah.

Evan Troxel: too. Right.

Natalia Bakaeva: Yep.

Evan Troxel: you do your thing, we'll do our thing. We're a well-oiled machine and I can trust you to do your thing, but there's literally a tiny amount of crossover typically, you know, even, even physically, if I think about like, pre covid offices, it was like somebody might walk over to that other department to talk to somebody about something or, or hit them up on, on a call or something. But I think most of the time it's just like, nope, we're, we're just, we've got this system working. We're going to trust that it works because. We've spent all this investment into the construct that and, and the, the, shared trust that it does work. And so I'm curious, like, how are you actually doing that?

Because, um, you are basically breaking down the established ways that that firms work. And I'm curious how open they are to that. Um, [00:42:00] versus, versus not, but also how you're actually accomplishing that.

Natalia Bakaeva: So. To sum it up, it's not a very easy task. And uh, as you know, construction is estimated to be about 25 years behind on digitalization, uh, as an industry. I don't know if that's a stat that you heard from any of the other guests, but we know that there is a lot of work to be done here. And we also know that professionals in our industry, myself included, sometimes I'm having a hard time changing my own patterns because we are so used to just repeating what we are, um, what we have established already.

And I think it also has to do with liability and, uh, professional insurance and all the things they have to carry. So we almost default to the ways we know

Evan Troxel: Mm-hmm.

Natalia Bakaeva: to be sure that, you know, we are not exposing ourselves to something we don't want to. And I think for us it's very important [00:43:00] to. Find firms who are not just saying that they're created for innovation.

They're completely self-aware that you cannot put Genie back back in a, in a bottle.

Evan Troxel: Mm-hmm.

Natalia Bakaeva: not so much about we are changing the workflows a little bit or completely revamping them. The firms that are working with us, they understand that technology will change the landscape, and I'm not saying click one button, rendering ready, mid journey stuff, like that's not the way it's gonna go.

The firms understand that they can use technology as a sales vehicle. They can differentiate in front of their clients and they can communicate to them that they are enabled and they are en, they're enhancing their productivity day-to-day, and that is helping them to win work. Because the clients are interested in hearing that [00:44:00] because that's how, that's how they build this differentiator for themselves.

Other firms, they want to be better than the firm next door, just literally, they want to be able to compete at the higher level. That's their goal. Um, and I think that they understand. They're, again, self-aware. They understand that that will take certain disruption and that is why we are working so closely with them.

Because as a, as a startup, as a company that is constantly building and evolving, we are so intertwined with their processes today. And our initial goal is not to disrupt them. We actually try, and that's why we built integration with Revit. That's why we are working with firms who are in ArchiCAD, AutoCAD, you know, any software because we actually wanna learn.

There is a value there. You cannot just come, come in with an ax and just like chop everything up and then say, okay, now you do it this way. It's never gonna work in this [00:45:00] industry. And me being on a team is extremely helpful, as you can imagine, because software engineers half of the time don't understand what we are talking about when we say grab bar and we say, you know, those,

Evan Troxel: Right.

Natalia Bakaeva: especially when we start using the lingo and getting really, um, hard on acronyms and, um,

Evan Troxel: Yes.

Natalia Bakaeva: uh, I have to go sit down and decode all of this, uh, for my team.

Evan Troxel: Hmm.

Natalia Bakaeva: And they've been extremely good at, at, at, uh, learning about architecture, but still, like we understand that it takes a person coming from the industry to be able to execute this work because those processes so complex, they're so intertwined. So I think my short answer to this, it's a process and, um. To the firms that are thinking about innovating, thinking about their five 10 year as strategy.

My [00:46:00] advice, always start early. Don't wait on next best tool. Figure out what values you identify with and just start working on it. Start wrapping your head around how things work. Like we meet with our customers every couple of weeks, sometimes every month, and we just tell them what's happening in the industry.

And they, as architects, they don't have time to, to go and research, but half an hour call with us. They feel like they're already up to speed, even though we are talking about our product development. But we would always mention something about what we saw, what is happening, you know, what they saw, what they tested, and how it can be potentially used in the future.

And we are experts in this. That's what all what we do. Um, so I think that. It's not so much about changing everything from the get go, it's about understanding. It's gonna take us a very long time to get there.

Evan Troxel: Yeah, I, I'm curious because you say you can't [00:47:00] just go in and start chopping with an ax. Like what has the transition process been like when you're kind of going alongside them and how, like, because they're the idea of disruption, like I, it sounds to me like these firms are interested in transformation.

They are interested in evolution. And like, there's different ways to accomplish that. Like burn it down, start over, right? There's

Natalia Bakaeva: Yeah.

Evan Troxel: and then there's the ex, there's the non extreme of like, oh, we'll just, we'll just take it in little bite-sized chunks. Eventually we'll eat the whale. Right. Kind of a thing. Um, sounds like you're somewhere in the middle of that because you have these firms that are like ready for transformation, at least from a leadership level. They want to see that happen. They understand the value that it could at least for the next five to 10 years, and, and that they'll be in a better place sooner. So I'm just curious, like what has been the appetite of transformation for these firms and, and what are, what feedback [00:48:00] are you getting where it's like, oh, the light bulbs are going off? Because I'm curious to tell that story to the people who are listening to this, who are in firms that are not doing that at all.

I mean, that's the low, let's, let's aim for that lower end because they're the ones who are yet to kind of see the possibilities there.

Natalia Bakaeva: Yeah, great question. I think that. It's somewhere in the middle, like you said, but it's more of a discovery for us today. We are still learning. We are asking questions every day and not because I don't know how it's done, it's more for us to, one more time, get to why, why doing this this way? We are asking five whys and really trying to uncover what is they're trying to actually accomplish.

Because there is a lot of buildup, like you just mentioned. I admit myself, we just used to do it this way. That's why we are doing it this way.

Evan Troxel: Mm-hmm.

Natalia Bakaeva: think that the main theme [00:49:00] here is to go, uh, lead with collaboration, lead with education. To give you an example, when we use, um, visual search engine that we built, it is searching semantically.

In your data. So you have access to your visual information, textual information, metadata about the project. And we kinda combine all of this and we build a semantic cloud of meanings. And then out of those meanings you'll be pulling the answer. For example, if the drawing is labeled, Hm, you know, stands for hollow metal and you type hollow metal, our system would know even if there is.

Hm. That's what it means. So that's like that information that we like, it's data and then information that we are adding. And then wisdom is the next step, like you said, and, and kind of I [00:50:00] elaborated on that. And I think to be able to communicate things that never existed before and how they can use them, that's the hardest.

That's the hardest part because. If we are used to just go on servers, spend three hours, try to figure out information. If we used to talk to 10 people, like, I'm not exaggerating. Throughout our interviews we had one instance where a person told us if they need to retrieve information from the past project, they need to first talk to their manager.

And then the manager will try to memorize like remember which, which project I was on. And then they don't remember. So they go to accountant and then they try to find it in the accountant system. Then once they find it, they go to it, it has to make the file not readly, but actually downloadable from the old server.

And then they have to go and spend a bunch of hours trying to find like a classroom [00:51:00] layout from that one type of project that they've done several years ago. So that's a way we used to do it. So when I come to them and I tell them, just type whatever comes to your mind and you'll get an answer. All of a sudden we don't know what we're searching for.

And that's been the hardest challenge just to guide the, the team through the process.

Evan Troxel: Explain that. Explain what you mean by we don't know what we're looking for. Is it, is it like, well now I can't even think of a problem. Like what are you, what are you talking about when you say that?

Natalia Bakaeva: So they, like, let's say, okay, so just this week we have a customer who have their typical details set up on sheets.

Evan Troxel: Mm-hmm.

Natalia Bakaeva: And for them to find them, they download that PDF full of details or annotation or you know, the data there. And they just flip through sheets and that they [00:52:00] memorize which detail on which sheet and that's how they search for it.

So when I come to them and I, I will tell them, just type what you're looking for in the search. They're like, oh, but I'm used to,

Evan Troxel: I browse, I don't search. It's like, yeah, you, it's how you go through a magazine, right? Oh, I'm

Natalia Bakaeva: yeah.

Evan Troxel: for anything in particular. I'm just looking to see what, what might catch my eye. It's a completely different approach. And so what you're saying is like they're kind of at a loss, like what do you mean search?

I don't know. I don't, I don't search. I

Natalia Bakaeva: Exactly, and that's where we come in as a team. And you know, I always bring my technical team as well, and I explain to them as an architect who would use the software in my practice, I tell them, you create the collection, you share it with your team, you code it and name a certain way. And then you use precision search.

That's another thing that we allow to do is similar to Google. If you put air quotes, uh, you can search for exactly the name of the view [00:53:00] or title of the sheet that, that, that, that you're looking for. And I educate them about that as well. Um, sometimes I have to remind that that's the option as well. And uh, I offer them best practices.

I guide them through this process of transformation. And I think that's why I always tell the, the firms that are deciding whether to go go with us or not, it's not only about the product that we are delivering today, it's about the best practices. It's about what we learn from this, hundreds of people we talk to in different countries.

Everything from Singapore, South Africa, Europe, north America, you know, south America. Like we, we've done it all and uh, we can help you to, to, to do better in general.

Evan Troxel: I mean, yeah, you're talking about this educational component, right? Where it's like, like they actually have to relearn. I'm curious what you call this, like I would call this a behavior change, but I don't think [00:54:00] people like that word. They don't,

Natalia Bakaeva: Yeah. No.

Evan Troxel: don't need, I don't need you to change my behavior.

What my

Natalia Bakaeva: Yeah.

Evan Troxel: What are

Natalia Bakaeva: Yeah.

Evan Troxel: about? But, but that's how I kind of have always previously categorized it. But this idea that they need to learn a new way because like even growing up on the internet like I did, right? It's like that wasn't a thing when I was a kid. And then it became a thing and we had to learn how to use it.

And now I have behaviors. I have to relearn in the age of AI because I search Google with keywords,

Natalia Bakaeva: Yep.

Evan Troxel: Like that. I don't even, it was so funny. At one point I'm like, how would you find this? I asked my wife, how would you find this on the internet? And she's like, well, I would ask this question on Google.

I'm like, what do you mean? You ask a question? This was like. 10 years ago, you, what do you mean? You ask a question on Google? I I've never searched, used Google like that before. And she's like, oh yeah, I use it all the time. I actually literally just ask a question and, and now AI is, is even different than that, right?

Where I think people are still very rudiment rudimentarily using it like that. Where it's like, how, how, tell me [00:55:00] about this. But no, there's like way better ways to use it. And you're actually holding their hand and saying, I realize that you used to maybe search for hollow metal, but here's what I would do, right?

And now in this context, it's different. And so that educational component has gotta be, I mean that you, you're right. It's not just the product. Here it is now use it. Everybody like that actually doesn't work in a EC if anybody's still wondering. Um, but, but you actually have to. people, and I had a previous colleague on the show, Cody Winchester in an episode to talk about that specifically.

It's like, no, let's take the burden on ourselves to actually train our employees how to do all this stuff and how to keep them up to date with the latest things. Because if we don't, you can't just expect them to figure it out. And then we're spending all this money on tools that they're actually not gonna use because they don't know how to use it.

Right. Why would you use something you don't know how to use? Right. So,

Natalia Bakaeva: a hundred percent.

Evan Troxel: curious how you kind of, what, what do you call that? Do you call that a behavior [00:56:00] shift or what you just, I mean, you said best practices, maybe you call it that.

Natalia Bakaeva: We call it best practices. We call it AI strategy. I always try to use the words that are already, uh, people familiar with. I don't want to reinvent the new terminology. You know, architects know what best practices. Are, and we are essentially implementing this, uh, this lingo in the same time. Evan, I think it's, um, it's a multifaceted, um, question because we also build a thing called Arche Academy, uh, short videos where we explain to them how to use the software.

And, uh, it's done very interactively. It's not a stale content. Uh, you can always add more, and we actually want firms to be able to add their own content, how they using ARKI or how maybe ARKI spills out into other processes and then that's something they learned because we are learning from them every day.

As you can imagine, they'll try to break our software every single day. But that's good because we [00:57:00] are going then. Diving into the logs and all the information that we have on established like to track all this. And, uh, we are improving every day. And that, that's wonderful. So I think the patients, the ability to see the larger picture, the ability to see the outlook, the ability to see the goal, I think that's what we should be focusing on in this game as professionals.

It's not instant. And I think we shouldn't be in the mindset where, you know, today we have nothing and then tomorrow we just have it all fully established

Evan Troxel: Mm-hmm.

Natalia Bakaeva: is working again, out automatically. It's never gonna be the case. And um, I think in terms of like just communication in general and um, being able to, we call it build in public, right?

Because if you see my LinkedIn, I always talk about. Things we have done and, [00:58:00] um, things that are upcoming. Essentially, it's not a easy task because you get criticized, you get a lot of, um, positive feedback, but also, um, you know, it's not, it's not, um, it's not as comfortable as just locking yourself up in the room and just assuming you know everything.

So, but in the same time, we de-risk our decisions because we come up with a concept because we know there's a problem. And then we go and we sit down with our customers and we source feedback from, you know, five, 10 firms. And based on that feedback, then we digest it and we decide what to do next. And not to say that we always just take what they tell us and we just.

Digitize it because that's another problem with, uh, some of the [00:59:00] existing, uh, pieces of software that we have in the industry today that, um, it feels like we are just digitizing the processes that we know of. The goal is to hear the feedback, have an ability to digest it, and that is why for me, it's very valuable to work with, uh, our CTO who is coming from 15 plus years of pure software engineering.

And one of the companies where he was a lead engineer at is Salesforce in Tableau, and then essentially building the best software practices inside of our firm as well. Because a lot of things that we have today access to, they unfortunately do not rely on those best software practices. To give you an example, uh, our Revit integration is evergreen.

We never want our beam managers to chase their team and being like, update this, update [01:00:00] that. Like, this is a new release. We do it all for you. We send you a change log, you just restart your Revit and it's there.

Evan Troxel: right? And the, the app is updated automatically, kind of a thing.

Natalia Bakaeva: And Evan, in full transparency, sometimes it means that we say no to certain things because we know that maybe it feels on the surface like it's gonna solve something, but if there is no real use case for it, there is not truly a proven kind of record of this workflow or this uh, piece of automation that is needed, we will sometimes not do it.

And this is part of going back to being an apple of AC software. Um, we just very protective of what we put in the software.

Let's take a short break from the conversation to invite you to join the most influential technology leaders in the AEC industry at Confluence. Composed of in person events and a [01:01:00] podcast co hosted by yours truly, Confluence is designed to foster conversations between AEC firms and technology companies so they can learn, share, and engage with each other to support industry innovation.

Evan Troxel: Software company Avail, which creates content management solutions for the AEC industry, started hosting Confluence events in 2019 to understand what firms are needing, wanting, and thinking around technology. To learn more about Confluence, explore upcoming events, and listen to podcast episodes, go to confluence.

getavail. com. My thanks to Confluence for supporting this episode of the TRXL podcast. And now, let's get back to the conversation.

I'm actually glad to hear that because I think there's probably a lot of ideas that it's like maybe someday, right? But as a startup, you have to focus and you have to put your energy to what does the most for the, the most amount of people. Right. So I, I'm curious, you said earlier, um, [01:02:00] so maybe a couple more questions here.

Um, you said earlier that, like you talked about the idea of removing buttons, right? Or removing features. Have you done that? I mean, maybe you have an example of that kind of a thing throughout ARKI lifetime, because I. just curious if the rubber meets the road there because it's like I've, I've lived through software products.

I mean, talking about Apple, like at one point they had to com, they, you know, keynote was a great PowerPoint comp competitor and it was super featured, but it was on the Mac only and they wanted to bring it to the cloud. They wanted to bring it to iOS devices and at that time, iOS and the Mac were completely different development ecosystems uh, basically like set fire to keynote as everybody knew it and the whole kind of productivity suite and said, we're going to regress so that we can then. Put it on all of these platforms at the same [01:03:00] time with the same feature set, and then we will rebuild it. And I, everybody screamed when they did that. Like, what are you talking about? And of course, they still let the old version live while they did all that. But then it was different, but it was for the better.

Natalia Bakaeva: Yep.

Evan Troxel: they had to go through that kind of painful process for their users, but, and ultimately to serve their users when it, when it, when everything kind of came back to quote unquote normal. And so we lived through that. Like, oh my gosh, this is, doesn't have the features, it doesn't have these buttons, it doesn't have these things that I rely on.

But it also gave them the opportunity to say like, wow, we really had a lot of scope creep and features that like nobody was using. Let's get, let's actually never put those back in, for example. So I'm just curious in your history here with Akey, what, have you done anything like that to actually remove something because it wasn't valuable enough or not enough people were using it?

I don't, there's a lot of ways you could frame that.

Natalia Bakaeva: Yeah. Uh, great question. So. [01:04:00] The answer is yes. And I will give you a few examples. When we were starting to build ARKI and me as an architect coming with my brain from the industry, um, I wanted to bring as much information from the project, from the initial project to Akey as we possibly can. Like, I wanted to have as many parameters, so it's as descriptive and you know, it has the address, it has, the client has all the consultants.

And, uh, my initial list was extremely long. And then we just started to chip in away from that list. And then we realized that the list that they care about our customers, it's actually very short.

Evan Troxel: It's a different list than yours. Yeah. Right.

Natalia Bakaeva: And, uh, that's just to, that's just to, to kind of. Show you an example, you have to be [01:05:00] able to have confidence to do that too, because it's not always a nice feeling to, to be in this situation. Um, but ex you have to be extremely open and also extremely flexible and be able to hear from your customers, but at the same time be able to truly understand what they're trying to tell you.

And I think that's what I've been learning myself and kind of personally, that have been a huge, uh, steep growing curve for me. Because, you know, you hear something like we used with our, you know, customers, clients, um, on the design side, right? Like they tell you something, you try to implement it. Of course you check the code and everything, but you generally try to make them happy.

You try to make it work for them. Here, same thing. We also want our customers to be extremely happy, but in the same time. Because they're best product practices, because we [01:06:00] have software engineering expertise, sometimes what it seems, it's not what it's gonna be at the end. And I actually really appreciate that and that's why I like this multidisciplinary collaboration because if I would partner with another architect, we probably just gonna build another software that already exists on the market.

And, uh, we have this unique angle of bringing those, um, this expertise in house today. And I think another example I wanted to give you is that what we saw in the industry and what is available for our customers today is something that, you know, on the surface might solve the same problems. But I think with the technical capabilities that we.

Discovered and we were able to build, we came up with, uh, something like, um, asset deduplication with AI and asset versioning with ai and that I think [01:07:00] initially we didn't realize the depth of the asset versioning. And when I say asset version, meaning that, let's say you have a floor plan or a construction detail, let's say, and uh, you want to take a snapshot of that information and you wanna keep tracking it as you develop this detail, maybe as it changes, right.

Initially we thought about it as, you know, you put a data on it and it's good to go. But then we realized that, you know.

Evan Troxel: versions that day. Yeah.

Natalia Bakaeva: And there are also some typical details that are seen in multiple projects and there are also variation of that, the same detail, just because something changed, but maybe not by 30%, but maybe by 5%.

Evan Troxel: Mm-hmm.

Natalia Bakaeva: had to develop a new framework, new way of thinking about this problem. And today, with the visual search and uh, be able to visually deduplicate and, uh, timestamp those [01:08:00] assets, it's actually working way better. But again, if we haven't made this mistake early on, we wouldn't be able to be where we are today.

Evan Troxel: Yeah, I, I'm curious, you've talked a little bit about kind of solving problems for firms and there's this kind of industry wide, or, you know, you con you, you, you're working with firms in, in lots of different countries and, and you're getting, ideas and feedback into your software that then, I don't know, I want you to explain, does it benefit everybody?

How does, like, it, it sounds to me like the data, the information, the wisdom, the knowledge that is, is, is kept within a firm like a little bubble, but there's these other things that apply to the platform that everybody gets advantage of. I'm just curious how kind of you separate those things, uh, when you're talking to different clients.

Natalia Bakaeva: A hundred percent. So each firm gets the private secure cloud. We know that data is the main source of income for architects, engineers, and we [01:09:00] extremely. Serious about how we treat it. And each firm sits in their own, we call information silo or data silo. So once you log in, you log in into your own ecosystem as a firm.

In the same time, if you submitting a feedback or if we are inviting you to continue developing software with us, like for example, today we are building a fee estimator proposal generator. And, uh, we invite firms to join us. And some firms actually enjoy, develop a software with us. They don't get to do that very often.

And for them, that's another avenue to learn, um, to engage their maybe junior or intermediate to senior staff, depending on what we are working on. That's like a, it's like an activity for them as well internally. And, uh, essentially we, we go about, uh, this, uh, process. [01:10:00] Very, very methodically, right? So we hypo, uh, we have a hypothesis.

This hypothesis, and again, based on jobs to be done right, there's a, there's a problem, there's a job to be done. Uh, and there is solution that we assume should be there. We come with this hypothesis to multiple firms and multiple stakeholders inside each firm. We talk to principals, we talk to, uh, senior architects, intermediate architects, and then users.

So drafting staff. Sometimes we'd bring a business person to the mix. Sometimes we'd bring cybersecurity IT person to the mix, digital practice lead. And we, again, as I kind of started this conversation, we look at the problem from different angles, depending on what that problem is. We source the feedback and uh, we put this feedback on the canvas from different firms, different geographies.

And then we digest it. So we turn it into statements or features or workflow processes or [01:11:00] workflow automation. And then we go back to them and we ask them, is that what you meant? And then when they tell us that's either yes or no, we continue. And little by little we release those two versions to them that they can play with.

Again, we source the feedback, we implement it, and that's how we grow. And that's how we've been building for past year and a half. As soon it's gonna be two years. And, uh, we planning to continue doing it this way. As I already said, it's um, it's an interesting process, not something that I've done in the past, but as you mentioned in the beginning of this conversation, it's very similar to the way you design a building.

There are phases there are. Processes that run in parallel the processes that tie to each other and they're sequential. And I always try to map what [01:12:00] we do to how I would design a building, and that really helps me to digest this information

Evan Troxel: I bet it helps you translate it to communicate it to your clients as well,

Natalia Bakaeva: a hundred percent.

Evan Troxel: language they speak. So it sounds like you're constantly iterating and evolving your product instead of like a yearly big release cycle with small patches along the way. Is that safe to say? I mean, this is, again, this is kind of a shift that I think I remember somebody. Really another version, like a new version of Revit. Like why can't, and and they were frustrated because every year we change the version, right? At Revs, Revit 20, 20, 21, 20 22, 20, right? And so it was like, and, and to me, like looking at my phone again as the model, it's like, what do you mean? Like this is happening all the time and you're okay with it on your phone, but you're not okay with it in business like this.

The stakes are way bigger here, right? So why wouldn't you expect that? is a shift, right? With. [01:13:00] Cloud-based kind of software development. It's just constantly evolving and constantly being updated. And firms are, it's like, oh, the button moved today. Right? Um, where do I find it now? I mean, uh, as an extreme level maybe of, of, of a kind of a thing they would see, you know, probably not, you know, most of the time, but it's like there's this constant change going on versus once a year or once every couple years, we might go through this process.

And I'm just curious kind of what are, are people talking about that when you're, the way that you're developing, when you're working with these firms? Or, or is this just expected now?

Natalia Bakaeva: So, uh, great question. I, I actually really love this, uh, stream of thought and kind of this, uh, side of this conversation. We do communicate to our, uh, customers and people who are on trial or any sort of prospects. Uh, our product updates, they go out weekly and weekly. We build new things, and this is again, uh, going back [01:14:00] to software practices and, uh, bringing the team that is coming from the software development background and, uh, being able to bring the best practices, uh, and implement them here.

So instead of waiting, we release, uh, those features in a very small, digestible. Bite-size, uh, chunks. And that's good because they're able to go test it right away. Ask a question. We release a feature, we set, send a product update, product update. You can sign up on our website. It's, it's like a one page, uh, summary, and they immediately go test it.

And they ask a question, that's it. We answer. It's done. And we don't have to go through this painful process of now we need to push an upgrade, we need to install a hot fix. We need to do all of that. It's all taken care of in the background because we trying to get to automation and, uh, going through version updates every year.

That's, uh, the opposite of that, in [01:15:00] my opinion, at least.

Evan Troxel: Yeah, I mean the, the once a year, um, release cycle can be really painful for organizations to deal with. I mean,

Natalia Bakaeva: It is painful.

Evan Troxel: why it can be painful, right? It's like, okay, we gotta educate users on how to use all these new features. If there are a lot, maybe there isn't, um, maybe it's a new ui.

Maybe it's like we have to upgrade the projects that, you know, the data is that, that those of

Natalia Bakaeva: Yep. Yep.

Evan Troxel: And, and that takes time. And there's so many things that go along with that. there's time, there's downtime to actually deploy it. You know, a lot of people had to get really smart about deploying thing, leave your machines on overnight so we can do these upgrades and, and then you have more behavioral changes there.

It's like, what do you mean I don't leave my, my computer on all night? Like,

Natalia Bakaeva: Yeah.

Evan Troxel: things that our industry has gone through,

Natalia Bakaeva: Yeah.

Evan Troxel: time. And, and it's, it is just kind of a, it, it's, it makes sense. I can totally see why you've designed your business to work like that. And then also your, your really strong [01:16:00] point, um, I don't wanna skip over.

It's like, well now they only have to digest it little pieces that have at a time rather than big changes all of a sudden. And it's like, what do you mean? Like, I don't have time for that. I'm not gonna upgrade. Right. Like that's what we've seen too because of the, you know, legacy software release cycles that, that are still, still happening in, in many regards today.

Natalia Bakaeva: Yep.

Evan Troxel: a pretty fascinating way to kind of, you know, it for, for your, and it's good to hear that, that they're actually jumping in and testing that right away and kind of, oh, let's, let's check this out, because it is such a small hurdle right. At that point, and it's,

Natalia Bakaeva: Yeah.

Evan Troxel: something they can take on.

Natalia Bakaeva: Yeah, we really try to minimize it because it's already new software, right? Like there are new things that they need to learn about. And if we again, go through this process gradually, it feels very natural, right? Like we are not coming one day and say, forget everything you knew.

Evan Troxel: Mm-hmm.

Natalia Bakaeva: this. [01:17:00] And then adoption becomes a real problem.

Evan Troxel: Right.

Natalia Bakaeva: they almost at the point where once they know more about the software, it's more inviting for them. Once they receive this product updates, they're more engaged. They can actually go and, um, you know, see for themselves, oh, I learned this. Thing. I wanna go quickly test it and you know, it's already now kind of in my back pocket.

Next time when I need to do it, I can go and just quickly search or, uh, use precision search like we, like we said before, um, something that I want to mention in terms of the interoperability and rev versioning and, you know, all the software versioning, that was one of the biggest problems that we saw on day one as well, because everyone would talk about it.

Different tax stacks, you know, you switch between the firms, things are done differently. That is why we, even though today we started with Revit as a first integration and then expanded to CAD and PDF, but [01:18:00] we are aware that for us to be successful, we need to be software agnostic because we want to be able to bring all these pieces of software together and cut through the silos of software.

Um, you know. Uh, information that sits in different, um, in those different compartments. And then what we did as a first step, we allowed them to upload the data without upgrading their models, and then we upgraded for them. So once they bring the data forward and they want to tweak it, they essentially don't have to worry about any of that.

And once the data is being consumed again for the future work, we just do it for them and they don't have to be.

Evan Troxel: know about that and they're on board with that. It's

Natalia Bakaeva: Yeah,

Evan Troxel: I can hear some IT people and, and digital practice people like what? But obviously this is something you're working [01:19:00] directly with them about.

Natalia Bakaeva: yeah.

Evan Troxel: Yeah.

Natalia Bakaeva: And it's also because it's done in chunks, it takes less time. It's very digestible. Again, we're trying to always break this big massive tasks and make them. Very interactive, almost like small, so they don't, they don't feel as overwhelming and this whole transition doesn't feel as, you know, painful.

Evan Troxel: Nice. F Okay. Final, let's wrap this up here. I I, I'm curious kind of from a big picture perspective, like the why you, you say, you know, you talk to these clients and you ask the five why's, and I'm curious why you're doing what you're doing because, um, you know, and, and I'll lead the witness a little bit here, I think, and, and people might not like that.

I'm gonna say it like this because I am leading you in doing this, and maybe we want to hear your actual authentic reaction, but I'm, I kind of have a sense because you're, you're like wicked smart, I can tell. Right? And, and the. The thing that I want to [01:20:00] put out in front of you is like, why is this important?

What is the true value of an architect? I think that's why, because it's like, well, let's do the valuable stuff and not the stupid stuff. And we do so much stupid stuff. Like, and, and stupid is, is a, it's a negative word, but, and, and, and like we do, stuff we have to do is maybe a better way to put it, like this is all stuff that has to be done on a project.

Maybe we don't have to do it like this, but because of contracts, because of standard of care, because of insurance and risk and all of these things, like there are still all these things that we, we have to do, which I categorize as stupid stuff. So, so I'm just gonna throw that out in front of you, why are you doing what you're doing?

What, what is what, what is the goal? Like, what are you trying to get to? What are you trying to help firms achieve?

Natalia Bakaeva: I have two stories for you. We are in conversation with one of the biggest firms in the [01:21:00] world. Can I say name here? We can say names, right?

Evan Troxel: Yeah.

Natalia Bakaeva: uh, we've been talking to Zaha, did architects for a while now, and, uh, just learning about the challenges. And this person who I met at one of the conferences last year, uh, just told me and shared with me, uh, very candidly that we have the most creative, the most design driven architects from the entire world.

They come to the Haid architects and they work crazy hours because they love design. No one wants to draw construction documents so they see the value and tools like Akey to help them bridge that gap. We want to still have the most creative people in the world coming and helping us to create this incredible project, but [01:22:00] at the same time, we are living in real world and every design needs to be executed.

That is why if there's a way to shortcut this, they would love that. And the same time when we come to architecture school, and that's kinda looping nicely. Back to my first story,

Evan Troxel: Mm-hmm.

Natalia Bakaeva: have promised this unleashed creativity. This like infinite options for design decisions.

Evan Troxel: Yeah. Right,

Natalia Bakaeva: And then you start literally on your job number one, and the reality hits, and it's very different what from what we promised to.

So I wish to our profession to be able to be more creative, to be able to get and to remember what they come to this profession to do. Great design, changing the world, building the spaces that will change people's mindset, do less redundant task, and, [01:23:00] uh, just be excellent, profitable, fulfilled professionals and just don't quit their job and go work for developer, but actually love what they do every single day and, and feel like what they were promised to is what they got.

Evan Troxel: Isn't it interesting that somebody from, I mean, I, I'm similar to you in the way of what I'm about to say here, which is like you went outside of the profession to, to help the profession, right? I call it going from working in the profession to working on the profession

Natalia Bakaeva: Yep,

Evan Troxel: this idea of. actually need those people who would've thought, because it's so hard to do it from the inside, it is so difficult to change firms from the inside.

Change the practice from the inside there's so much pressure already. There's so many things. We, there's so many boxes to check, there's so many deadlines. There's all these things that you're fighting with because that is what you signed up for, right? Like you're delivering projects. But [01:24:00] it's so hard to change that from within. Um, I've experienced that firsthand myself. And,

Natalia Bakaeva: me too.

Evan Troxel: are, there are people who are willing to stick around, but in a different way, right? And really try to make a dent in the universe of the profession of architecture. So, well done, well stated. Uh, I would love it if you would tell the audience where they can learn more about you and what you're doing.

Natalia Bakaeva: Yeah. Thank you, Avan. This is a great recap of what I said, and I agree that we are on the same page here. Um, our website is get ARKI.com. It's G-E-T-A-R-K i.com. Uh, my LinkedIn, uh, I write a lot about the subject, about the, you know, AI workforce and AI and AC and I'm very critical about the buzzword ai. So if that's something that you are interested in.

You can just follow me or even send me a friendly message. And [01:25:00] um, yeah, so that's the best, uh, channel to connect with us. If you want to see what we do, you can subscribe on a website and get in touch with us. And I'm very open and showing and presenting what we built so far and hearing your opinions and thoughts.

It's not only about the good stuff. Sometimes it's important to hear some critic. We are open to that. Uh, yeah. And stay in touch and I would love to hear from you.

Evan Troxel: Thank you, Natalia. This has been a, a great conversation again, that it's get ARKI.com. I'll put links to that and to your LinkedIn in the show notes for this episode among things that we've kind of touched on. So thank you for taking the time to have this conversation today. It's been really, really wonderful and I hope a lot of people get a lot of things out of it.

And it's, I hope that it actually starts conversations like that to me is like the overall outcome that I could hope for is that we have to have this discourse. It's great to have it in public here on the, on the podcast, um, but I hope [01:26:00] that it continues beyond this podcast, so thanks.

Natalia Bakaeva: I hope so too. Thank you, Evan.

Evan Troxel: Before you take off, in the introduction to this episode, I mentioned that architecture firms are losing talent because of a problem, and the problem is the lack of innovation and poor knowledge infrastructure. Natalia has shared multiple points in the conversation that clearly explain how the failure to innovate internally, especially around data access, process improvement, and knowledge retention, is directly leading to burnout, dissatisfaction, and ultimately loss of talent in architecture firms.

Let's break this down into five key takeaways. Number one, burnout from redundant manual work. Natalia has said, I found myself one day at 2:00 AM drawing a simple kitchen for a staff lunchroom. I was just thinking to myself, this firm is 65 years old. I'm sure what I'm drawing right now has been drawn at least a thousand times.

She highlights the soul crushing redundancy in [01:27:00] architectural work done repeatedly across firms with no shared system to access or reuse it. This inefficiency directly contributes to burnout. Number two, no time or space for innovation. She said that she always felt like there was not enough room for innovation because we want everyone to be 100% billable, even if there is a desire to innovate inside firms.

There was also never time allocated to it. Firms are unintentionally stifling. Creativity and innovation, the very things that draw people to architecture in the first place. This disconnect pushes talent out of the profession or into other industries like tech number three, knowledge is lost as seniors exit.

While juniors struggle. Natalia mentioned how intern architects who join firms during the pandemic don't get proper training, retiring architects. Are not able to transfer that knowledge. A huge gap in knowledge transfer exists and there's no systematized way to [01:28:00] capture wisdom, which means new talent isn't empowered and senior expertise walks out the door every year.

Number four, digital tools are here, but underused. Today there is a literal search. You can search if things are being tagged.

And because today with AI tools, we can search semantically and visually, which clearly shows that firms have the potential. And number five, lack of strategic vision. She said, you can't hope innovation will just happen. Firms think that that's just gonna happen without enabling it from within the business Leadership often lacks the mindset or systems to encourage innovation. When firms don't invest in better workflows, purpose-built tools, or even education around them, their teams feel stuck and unfulfilled. So in conclusion, with all of the anecdotal evidence and the reoccurring topic with my guests on this podcast, firms are failing to support innovation and meaningful efficient work. Even though technology [01:29:00] accessible data and knowledge sharing systems are all here right now. The result: architects leave, talent is lost and firms struggle to grow sustainably. Firms are bleeding talent and not because architects hate the work. Well, they do hate some of the work, but it's really because the practices themselves haven't evolved.

So like many of us that have moved adjacent to the profession that we love, Natalia is building the solution from the outside in. I hope that you'll support what she and others like her are doing. That's it for this episode. Thanks again for listening and I'll catch you in the next one. Bye.

​

Overview

In an industry often constrained by outdated workflows, siloed stakeholders, and risk-averse contracts, SHoP Architects has emerged as a beacon of what’s possible when architecture embraces innovation without losing its soul. Today, John Cerone takes us behind the curtain, and I have to thank him once again for being willing to do so. We need more of this in the AEC industry!

Through model-based delivery, empathetic collaboration, and bespoke digital tools, SHoP is evolving from an architecture firm into a catalyst for industry transformation—one project at a time.

This case study explores how SHoP is designing the future of architectural practice today, and what AEC leaders can learn from their approach.

Vision: From Drawings to Data-Driven Design

In Randall’s and my recent interview with John Cerone on an episode of the Confluence Podcast, I was particularly interested in learning about SHoP Architects’ concept of using lightweight models as a foundational framework onto which high-fidelity components are hosted during the design process. This strategy offers several strategic and operational insights for AEC firms looking to modernize their practices.

There is often pressure to get into BIM early or use it as a “design tool” for the sake of efficiency. But there is a trade-off: Traditional BIM tools like Revit often force designers into premature specificity, requiring detailed component decisions far too early in the design process. When architects must define specific wall assemblies, MEP systems, or structural elements during initial design phases, it creates a rigid model that becomes increasingly resistant to change. Each modification ripples through the entire model, requiring extensive manual updates to maintain consistency. This “early commitment” approach not only stifles design exploration but also creates unnecessary technical debt—the more detailed the early-stage model becomes, the more labor-intensive it is to pivot or respond to evolving project requirements. This stands in stark contrast to SHoP's lightweight modeling approach, which preserves design flexibility until component specificity is actually needed.

1. Early Flexibility, Late Precision

By starting with a lightweight model (geometry, surfaces, spatial relationships), SHoP maintains design agility early in the process. This allows:

• Faster iteration without heavy overhead
• Rapid decision-making with stakeholders
• The ability to incorporate client and jurisdictional feedback before the model becomes “brittle” with detail

As the project matures, precision increases naturally through the hosting of detailed components—materials, fasteners, assemblies—by fabricators, consultants, and manufacturers.

2. Decoupling Design and Execution

The hosted systems model allows different parties (e.g., contractors, fabricators, engineers) to work asynchronously and in parallel:

• Architects define “what” and “where”
• Fabricators define “how” and “with what”
• All parties work within the same spatial model

This approach decouples design authorship from fabrication authorship—without compromising the alignment between them.

3. Real-Time Constructability Feedback

With fabrication systems being overlaid onto the design model, feedback loops on:

• Material availability
• Assembly constraints
• Tolerance issues
• Cost implications

…can happen in real time, not weeks or months later during documentation or shop drawing review.

This supports early design optimization that reflects actual fabrication realities.

4. Mass Customization and Rationalization

Once high-fidelity systems are “hosted” to the lightweight wireframe, the model becomes a live dashboard for rationalization tools:

• Automatically group parts by tolerances (standardize or repeat)
• Identify opportunities for kit-of-parts or prefab
• Run performance simulations (energy, structure, egress)

This enables mass customization—complex geometry with underlying system simplicity.

5. Digital Ecosystem Enablement

The lightweight model serves as a common digital environment—a sort of operating system—on which multiple stakeholders can plug in their tools, apps, and simulations. It promotes:

• Use of APIs and cross-platform interoperability
• Real-time data overlays (e.g., cost, schedule, performance)
• Better digital twin readiness for operations and FM

6. Increased Trust Through Transparency

When stakeholders can directly “host” their components, there’s:

• Less need for RFIs and interpretive translations
• More accountability
• A shared understanding of scope and sequencing

This reduces adversarial posturing and builds trust through shared authorship.

7. A Path Toward Continuous Delivery

This modeling strategy is incremental, modular, and evolvable—key characteristics of continuous delivery in software. It supports:

• Iterative, milestone-based development
• Scope prioritization (build the core, refine the edges)
• Versioning and rollback of design features

Summary of Values

If you’re leading an AEC firm and considering how to evolve, adopting SHoP’s lightweight model + hosted system strategy is a compelling first move. It invites collaboration, reduces downstream surprises, and makes space for innovation—without sacrificing control or clarity.

Dan Chuparkoff joins the podcast to talk about why traditional industries like architecture need to embrace reinvention. We discuss practical ways to foster innovation despite resistance, explore the dual nature of technology, and dive into topics like innovation through separation, AI's true potential, diversity as a catalyst for innovation, reframing learning, and the importance of cross-pollinating ideas and talents across industries.

Watch this on YouTube:

Episode links:

Connect with the Guest

• Dan Chuparkoff on LinkedIn
• Dan Chuparkoff on Instagram
• Dan’s website
• Dan’s brother Thom on TRXL 075: ‘Architecture as a Hobby’, with Thom Chuparkoff

Books and Philosophies

• Clayton Christensen’s The Innovator’s Dilemma
  • Amazon Link
  • Introduces the concept of disruptive innovation, crucial to understanding the pace and impact of change in architecture and tech.
• Cal Newport’s Deep Work
  • Amazon Link
  • A guide for cultivating focus in a distracted world, highly relevant to navigating change and learning new tools.
• Carol Dweck’s Mindset: The New Psychology of Success
  • Amazon Link
  • Highlights the value of a growth mindset for individuals and organizations adapting to constant technological evolution.

AI Tools and Emerging Technologies

• ChatGPT by OpenAI
  • ChatGPT Overview
  • Explore the large language model Dan refers to as a new standard interface for work and creativity.
• **Otter.ai for AI-Driven Meeting Transcription**
  • Otter.ai Website
  • Automatically transcribe and summarize meetings, as discussed in the context of communication workflows.
• LinkedIn AI Transcription and Language Translation Tools
  • LinkedIn Learning AI Tools
  • Train yourself on real-world applications of multilingual and AI-powered content strategies.

Visualization & Design Tools

• Midjourney – AI-Generated Concept Art
  • Midjourney Website
  • Understand how concept visuals are created with AI—great for exploration, but not for buildable designs (yet).
• Autodesk Forma (formerly Spacemaker AI)
  • Autodesk Forma
  • An early example of AI applied to site planning and early-stage design in architecture.
• Revit + Dynamo + Python
  • Autodesk Revit
  • Dynamo BIM
  • Learn how to automate repetitive tasks and integrate code into your BIM workflows, as mentioned in the episode.

Innovation, Strategy & Organizational Change

• McKinsey on Innovation Culture
  • The Eight Essentials of Innovation
  • Explores how large organizations can foster change and embrace risk—mirroring Dan's experience at McKinsey and Google.
• Dan Chuparkoff’s Website
  • Dan's Website
  • Where Dan explores patterns of innovation and organizational transformation across industries.

Events and Networks

• Google I/O
  • Google I/O
  • Stay current with announcements in AI and technology tools that can shape design, communication, and collaboration.

Psychology and Personal Development

• Daniel Kahneman’s Thinking, Fast and Slow
  • Wikipedia Overview
  • Amazon Link
  • Key to understanding decision-making in fast-changing environments.
• Adam Grant’s Think Again
  • Amazon Link
  • A guide to questioning assumptions and staying flexible—a great mindset for innovation leaders and design professionals alike.

Related TRXL Podcast Episodes

• Episode 172: 'Architects in Airports Talking AI and AEC', with Phil Read
  • Phil Read discusses leveraging AI for meaningful work, the importance of curiosity and play in professional development, and how AI is reshaping client engagement and creativity in architecture.
• Episode 177: 'The Digital Futures of Architectural Practice', with Kristen Forward
  • Kristen Forward explores integrating artificial intelligence and emerging technologies into architectural practice, focusing on AI implementation and digital transformation in architecture.
• Episode 123: 'Bringing AI to the Building Code', with Scott Reynolds
  • Scott Reynolds discusses UpCodes' Copilot, which leverages AI to make building codes more accessible, highlighting the journey of UpCodes and the potential for innovation in the compliance space.
• Episode 141: 'AI is Not Your Strategy', with Mehdi Nourbakhsh and Scott Thompson
  • Mehdi Nourbakhsh and Scott Thompson talk about creating an AI implementation strategy for a 1,000-person AEC firm, emphasizing the importance of aligning technology adoption with business goals and focusing on people in the implementation of AI.
• Episode 163: 'Confusing Evolution With Innovation', with Nirva Fereshetian
  • Nirva Fereshetian discusses the complexities of implementing and managing digital practice within an architecture firm, addressing challenges like tool fatigue, understanding business problems, and adopting new technology.

About Dan Chuparkoff:

Dan Chuparkoff is one of the world’s leading experts on AI, innovation, & the future of work. As a technology leader at Google, McKinsey and more; Dan led transformations for teams in every industry as the world navigated three decades of technological change. Dan knows first hand that the people who leverage the power of technology will outperform the people who don’t.

The Technology-speaker for non-tech teams, Dan’s superpower is making complex things simple and useful. With his skill as an AI-educator combined with his formula for harnessing the power of innovation, he helps audiences to escape disruption and find growth and success. Dan shows teams how to make sense of AI, how to harness the Power of Technology, and how to combine that with the Power of Human Expertise. With this powerful blend, teams will learn to leverage AI & other technological advantages to thrive in the exponential future ahead.

Connect with Evan

• LinkedIn
• YouTube
• Twitter/X

Episode Transcript:

TRXL 182: ‘Imagining Where We Want to Go’, with Dan Chuparkoff

Evan Troxel: [00:00:00] Welcome to the TRXL Podcast. I'm Evan Troxel, and in this episode I am joined by Dan Chuparkoff, who is one of the world's leading experts on AI innovation in the future of work as a technology leader at Google, McKinsey and others, Dan led transformations for teams in every industry as the world navigated three decades of technological change, he knows firsthand that the people who leverage the power of technology will outperform the people who don't.

Something I think that this audience probably knows a thing or two about, and today he shares about change. Creativity and how leaders can prepare their teams and organizations for a future powered by AI and innovation. He draws from decades of experience in software and product development and shares valuable insights into why traditional industries like architecture need to embrace reinvention. We also talked about how to practically foster [00:01:00] innovation in the face of resistance, the dual nature of technology innovation through separation, AI's true potential diversity as a catalyst for innovation.

Reframing learning the importance of cross pollinating ideas and talents from different industries to drive innovation and more. One of the main themes of this episode is about change agents. I'll put out a challenge to you, dear listener, and it is that change agents must lead their teams through technological change. Can you identify who the change agents are in your organization? Maybe it's you. Anyways, stick around to the end of the episode because I'll wrap things up and tell you why I think this theme is a really important takeaway from today's conversation.

Lastly, you can really help out the podcast by sharing these episodes with your colleagues and by commenting on and sharing my LinkedIn posts. And you can leave a comment over on YouTube to chat with the other [00:02:00] listeners. As usual, there's an extensive amount of additional information on the show notes, so be sure to check them out.

You can find them in your podcast app if you're a paid member and if you're a free member, you can find them at the website, which is TRXL.Co. So now without further ado, I bring you my conversation with Dan Chuparkoff.

​

Evan Troxel: Dan, welcome to the podcast. It's great to have you here. I.

Dan Chuparkoff: Thanks Evan. Uh, it's great to be here. I'm looking forward to the discussion today. Um, I, architecture goes deep back into my, uh, personal history and I'm looking forward to talking about how, you know, architects are seeing change, how non architects, other designers are seeing change and, and the technology progress in the world.

Uh, it's impacting us all. So I'm looking forward to the conversation and, uh, thanks for.

Evan Troxel: Yeah. You're, you're, I, I love that you're here and, and I've had your other brother half on this show before [00:03:00] and I love Tom's, uh, stance that architecture is his hobby and he shows up every day to his hobby. I think that's a really cool attitude to have. And his, you know, it's, it is pretty infectious.

His. he's a, he's just a great guy. And so I'll put a link to that episode in the show notes so people get the full familial effect here. But Dan, you're in a different industry and you, I mean, I know that there are obviously crossovers, but maybe you can tell us a bit of your backstory and, and so that we know kind of how you got to where you are today.

Dan Chuparkoff: Yeah, for sure. Um, so I've, I've been a technologist for 30 years, I guess professionally. Uh, I was a product manager for most of that and a software engineer for a tiny bit of it at the beginning. Um, but I sort of stumbled into technology accidentally. I actually had originally intended to be an architect.

And I got an internship my senior year of high school for the Hillsborough [00:04:00] County, uh, school board in Florida. We were designing schools all over the, all over the county. And, uh, as an intern, I, you know, pretty much all they would let me do was draw parking lots lines like they, they would draw this whole plan and I'd get the site plan and I'd try to figure out how many parking spaces would fit in the parking lot.

And, um, you know, so I spent a good chunk of a semester drawing parking lot lines, and I was filing plans away in, you know, those architecture plan cabinets, you know, the big long, flat files. Um, I'm, I'm like in a, in our storage room, like filing plans away one day and I meet this guy that I hadn't met before.

Uh, his name was Mr. Pock. Um, and I introduced myself. I told him I was getting to know all the people around and, and I'm like, how come I haven't seen you? And he said, that's 'cause my office is down here. We're like on another level, practically in the basement. And he shows me where he works. And, and the first thing I see is he's got a computer sitting on his desk.

He also has [00:05:00] one of those old style drafting boards on the slant. Uh, but he's got a computer and a plotter that was like plotting at the time. It's making all this noise. And that's why they shoved him in the basement. 'cause his plotter was making so much racket,

Evan Troxel: Yep.

Dan Chuparkoff: right? And I'm like, what does this, how do you, what does it do?

And he's like, oh, it's just for cad. And I had never heard the acronym CAD before. And, um, uh, he showed me what he's doing. And it was AutoCAD revision nine, which back then was the first one that let you spin the design around. You could, um, you could look at it in three dimensions and, uh. And he showed me how to work it.

I spent a week with him and then, you know, he showed me I could copy paste parking lot spaces. Um, and now we say the words copy paste all the time now, but like in 1986, that was like magic.

Evan Troxel: It still is if you actually think about it. Right? Yeah. We do take it for granted though.

Dan Chuparkoff: So I [00:06:00] go back upstairs to where my normal desk is and I finish my project in Ink and Mylar, if I make a mistake, I gotta tear the whole thing up and start over. And I'm looking around and all these architects are drawing on, on Mylar and Ink. I'm like, Hey, does anyone know about Mr. Pock in the basement?

Like, why, when are we getting more computers? And the architects at the time, they weren't ready for that. They didn't understand that the drawings that came outta that thing would get better. They didn't understand that like the ability to share digital designs, you know, across stakeholders and, and cities would, would be dramatically better.

And so they, they for the most part, rejected that thing and resisted it. I saw that that was gonna change the future of architecture, and I, I changed my major in, aligned with that. Like, I, I want, I wanna make software that can do that to all the other industries. Um, and so that became, you know, a, a 30 5-year-old, you know, love with, with technology way back then.

Evan Troxel: Wow. [00:07:00] That that's, uh, it's interesting. And then you even make me think of like. A basic tool that we have today, which is to, for me, not a basic tool, which is a clipboard manager even where you can copy of stuff and

Dan Chuparkoff: Yay.

Evan Troxel: here and then pick which one you want to paste and where, and like just the amount of like, how long did it even take us to get from a single paste to multiple copy paste and, and what a big jump that was.

There's still so many people that don't even use a basic tool like that, right? Because

Dan Chuparkoff: Yeah.

Evan Troxel: know it exists. But I, and I think that's part of it too, is right, you, you don't see the potential because you don't know it exists. But then once you know that it exists, you're also kind of up against this existential threat of who's gonna replace me with this?

Will it replace me? And there's all of those kinds of, and, and so a lot of things haven't changed in that regard,

Dan Chuparkoff: Yeah, yeah, yeah, yeah. It's the same problem happening over and over again, regardless of what role you have or what industry you're in, like we're all facing that constant, um, uh, tool that helps us and threatens us at the same [00:08:00] time. Uh, and that's, that can be terrifying. I.

Evan Troxel: Well let, let's expand on your credibility. Where, where did you go from there?

Dan Chuparkoff: Yeah. So, uh, I started as a software engineer at a small, a small marketing services company that most people have never heard of. Uh, gradually, you know, I then tried some startups and then a digital agency. And then I worked at a company called Atlassian that makes software for developers. And then I ended up at McKinsey and Company, and then at Google, uh, finally at Google I worked on Android operating system things.

If you're, if you make mobile apps, you probably used a bunch of my tools, uh, Android Studio and Crash Lytics and Firebase and things like that. So that's, uh, the, the 32 year, uh, abbreviated version, but, um, ended up at Google actually wearing my Google vest right now, today for the video listeners. Um, but, uh, yeah, it was, it's, it was fun.

I saw some big companies and some old companies and some startups and some, you know, massive enterprises. And, uh, it was a, it was [00:09:00] an amazing journey. So,

Evan Troxel: And, and your brother's an architect. And so I'm sure you guys talk about kind of the, the pro, let's just say the contrast between what you've seen in the technology industry. Obviously your brother Tom is very technologically oriented in the

Dan Chuparkoff: right.

Evan Troxel: of architecture and leveraging those kinds of tools that we talk about on this show all the time.

But,

Dan Chuparkoff: Mm-hmm.

Evan Troxel: um, I'm curious, like from your perspective, when you're working at a company like Google, and

Dan Chuparkoff: Mm-hmm.

Evan Troxel: from my point of view, having never stepped foot in a Google office, I mean, I'm sure that there's some of the same issues that we're probably gonna talk about today, even. Call it plaguing, call it whatever you want.

But, but these, these large incumbent, you know, Google's been around for how long now? When did Google start? It's, it's got

Dan Chuparkoff: Yeah, it's, uh, yeah. Yeah, almost 30 at this point.

Evan Troxel: Right.

Dan Chuparkoff: So.

Evan Troxel: it's like this, this idea of disruption and, but also spend a lot of money on r and d, a lot of money on innovation and things like that. And they're constantly trying to come up with the next [00:10:00] best thing. they've had some big moonshots and they've also, you know, I'm sure just thrown a bunch of stuff away. Right. Um, but, but, so there's like this, it's all happening. It's, it's everything everywhere, all at once, right? All of

Dan Chuparkoff: right, right, right.

Evan Troxel: are going on in the soup pot. And then I, I think about like the contrast of, and I'm just gonna generalize and say most

Dan Chuparkoff: Yeah. Yeah.

Evan Troxel: are just kind of like, oh, how can we do what we do a little bit better,

Dan Chuparkoff: Mm-hmm.

Evan Troxel: how we do it?

Or, or.

Dan Chuparkoff: Right, right, right.

Evan Troxel: and, and I, I think that there's probably, you know, you probably share a lot of stories with, with him about that, and I'm sure that there's some of, you know, oh yeah, I see that. But then there's probably a lot of, you know, there are some differences in the way technology companies operate compared to especially really established architecture firms, even though they,

Dan Chuparkoff: Yeah.

Evan Troxel: have a lot of resources, and I could probably at the same time say that they're the ones spending the most money on the r and d when it comes

Dan Chuparkoff: Yeah.

Evan Troxel: you know, not disrupting themselves or, you know, being the ones who disrupt themselves instead of somebody else doing it to them.

Dan Chuparkoff: Right, right.

Evan Troxel: Google's point of view, and just being like this [00:11:00] technology company that has even put its toe in the water of a ECA few times,

Dan Chuparkoff: Yeah.

Evan Troxel: what do you, what's been your experience with just kind of seeing how this has played out over the last two decades?

Dan Chuparkoff: I think so the first thing I'll say to just try, try to, uh, uh, normalize what Google is like a little bit more for people. Some people look at Google and they're like, you know, they have a trillion dollars, they have hundreds of thousands of really smart people, like they can do things there that I can't do.

Um, but to, once you're on the inside, you see that they're, they're actually just a normal, big enterprise like many others inside, they have small teams that have like no budget to work with and they're scrounging for, you know, people and headcount, you know, then they have big legacy things that have been running for 20 years and they're afraid to touch anything.

'cause they don't want the, like, you know, the, the, the revenue to dip at all. 'cause that could be, you know, devastating for them. So first, Google has a lot of the same things [00:12:00] going on that many other small and medium and big enterprises have as well. Um, the second thing I'll say is fundamentally, as part of Google's life, I think because they sort of were born out of the internet, and also at that moment the way we searched for things on the internet shifted from the, the a OL Yahoo portal style thing to a consumer driven search, right?

It, it was, it was very guided before, like there were, you know, 15 categories and you could click on finance or you could click on travel and, and you would see the travel portal. Um, and, and suddenly users had control to go anywhere on the internet they wanted. And so Google saw that even brand new things.

Could get completely disrupted if you're not constantly making them better and better and better. Um, you know, at the time Alta Vista was the dominant search [00:13:00] engine and um, you know, it had only been around for four years and it, they just got left in the dust. And so the Google saw this sort of existential, um, de need for change that a lot of people don't see.

Or maybe in their industries it's not quite as fast as four years, right? Maybe of 20 years or maybe 40 years before you're just left in the dust. But at some point you will get left in the dust if you like, aim for. Stasis, right? If you just try to like, hold things where they are so that you don't take risks, minimize risks, minimize, you know, disruption and, and bad choices, then you'll probably be fine for a while in technology, that for a while is maybe only five years.

Um, and in, you know, in architecture maybe it's 25 years, I, I don't know what the, what the number is exactly, but it's, it's not forever.

Evan Troxel: Yeah.

Dan Chuparkoff: so, you know, people that try to hold the, [00:14:00] the line, uh, and keep things stable and risk free for too long will get left behind eventually.

Evan Troxel: Yeah, I mean, one of the main topics I wanted to discuss with you today is change, right? The, a

Dan Chuparkoff: Yeah. Yeah.

Evan Troxel: but, but just really how we deal with it as a, as an industry, as individuals,

Dan Chuparkoff: Mm-hmm.

Evan Troxel: then other, how other industries, like you're, you're talking about kind of a, just a different perspective completely, which is like, if we're not changing, we're gonna die, kind of a

Dan Chuparkoff: Right, right, right. Yeah.

Evan Troxel: industries like ours where, where it's maybe not as urgent of a, of like, I don't, we're not gonna die. We're gonna be fine. And, and then it kind of leads to like, oh, you kind of forget that you needed to look outside and, and you know, const continually kind of survey what's going on because you're busy, you're doing, you got deadlines, right?

You've got all these things that you've gotta do today. And, and so I mean. Well, I'm curious before we start really getting into the topic of change, um, because I think, you know, this goes way beyond [00:15:00] architecture. This, I mean, we're, look, we're seeing it

Dan Chuparkoff: Oh yeah.

Evan Troxel: We're seeing like there's people, like it was literally freaking out, but, but, but there's, there's also kind of this idea, like something actually can't get better until the one that's there is completely broken or dismantled or burned to the ground, right?

It's like, so, so there's all of this kind of floating around in my head too, but, but maybe you can kind of tell us your new focus since Google and, and so we can kind of frame the conversation around your expertise.

Dan Chuparkoff: Yeah. Yeah, that's, that sounds good. Um, what, what I started to notice about two years ago at Google is, first of all, I liked going to conferences and speaking on a stage to an audience about stuff that I thought about the world. Uh, and so I started doing that a little bit more. And, you know, meanwhile back at Google, I was helping my team.

I, I led a team that had about 150 people on it. Um, and so I was helping my team navigate, change and figure out what new stuff to do and, and figure out what bad stuff to stop doing. And I sort of realized, hey, the, the rest of the world [00:16:00] needs some of that leadership too. And so if I could combine my love for speaking at conferences with my desire to be a leader of teams in a world of constant change, um, then I could, I could do my most fun thing in the thing I was best at at the same time.

And so I quit Google a year and a half ago, and now I just helped teams all over the world to navigate new technology. Changes. And right now that means AI a lot of the time to a lot of the people. So we're talking a lot about ai, but you know, in six more years we'll be talking about how robots are helping to do stuff, take our trash out, or bring us our medicine or, or whatever they do.

And so that, you know, so that that, uh, constant technology, uh, revolving door of, of helpers assistance, uh, is never going away. And so I just do that now. I'm independent. I have a company called Re Reinvention Labs and we're just doing research on, you know, how change is happening in each [00:17:00] industry and what that's gonna mean for the people that are trying to be successful there.

And uh, so that's what I do. And uh, that's what we're kind of gonna talk about mostly today. 'cause that's what I do every day.

Evan Troxel: Yeah. I mean this, this idea of change and disruption, I mean, these are all kind of words that for a lot of people are super uncomfortable, and then there's others who are, are super comfortable with it

Dan Chuparkoff: Yeah. Yeah.

Evan Troxel: I mean, like you, your, your job is to help people get comfortable with it so that they can do something about it.

Right.

Dan Chuparkoff: You are right, right, right.

Evan Troxel: kind of the pace of innovation, and maybe you, maybe we can start here, is just what have you noticed with the pace of, of innovation and change just in the last couple years?

Dan Chuparkoff: Yeah. Yeah, yeah. So it, it definitely, there's on one side of the argument that the potential changes available to us is growing exponentially in that speeding up. But at the same time, the uh, amount of change [00:18:00] accepted into organizations is actually throttled because of leadership change out. Right. Like the, a person who is whatever, my, I'm 55, I'm, you know, my age.

I'm a leader at Google or any other organization. I have maybe eight or nine years of leadership left in me, and then I'm gonna retire. I don't need to change that much if I'm the leader. Right. So I'm just gonna ride it out.

Evan Troxel: you don't have to enable it either,

Dan Chuparkoff: Right, right, right. I can just, I'm just coasting on whatever, whatever laurels we like, you know, we built up in the meantime.

Then 10 years from now I retire, and then the person that I've been grooming to take my spot takes over and they're probably 15, 20 years younger than me. They're more comfortable with the digital age, they're more comfortable with risks. They have like 900 iPhone apps on their phone, so they don't care about new tool fatigue and stuff like that.

So they lead [00:19:00] my company in a completely different way. And so that generational flip in leadership actually is the thing that drives change more than the availability of new technology. And generational leadership is throttled by, you know, age and. Generation size and, and stuff like that. So, so what you'll probably see is in any 22 year span, most organizations aren't forced to change.

But then outside of that span, when they get to 25 or 30 years, they start to see that they're competing now against organizations that are led by people that have a different technology adoption attitude, mindset. And when you start competing against those people, you start drifting back unless you start making those changes too.

So that, that's kind of the, the due dual dichotomy of, um, of change, both speeding up and, [00:20:00] and stock at the 22 year, uh, point at the same time.

Evan Troxel: This, this idea of like being almost entitled to be in business is

Dan Chuparkoff: Hmm.

Evan Troxel: me, right? Because I mean, there's, you're competing in architecture where I'm coming from. You know, you're competing against other firms who are roughly doing the same things that you are,

Dan Chuparkoff: Mm-hmm.

Evan Troxel: it's like. We're hitting these revenue goals, we're hitting our, you know, our teams are, are, you know, trying to balance fees versus,

Dan Chuparkoff: Yeah. Yeah.

Evan Troxel: know, billable hours and all these

Dan Chuparkoff: Right.

Evan Troxel: And, and it's, it's difficult to actually, you gotta change everything if you wanna change. I mean, I actually, I'd be curious to hear what you, what you kind of advise people there because, because it's, it is really difficult to change it all, and it's hard to change little

Dan Chuparkoff: Yeah.

Evan Troxel: of it in the machine as it's moving and

Dan Chuparkoff: Right, right, right. Yeah. Yeah. Yeah. I, I've been, I, I've been fortunate enough [00:21:00] to be part of, um, some sort of like dramatic shift in a, in a business's, uh, business model and. And technology adoption, uh, two times. Um, the first time I was part of a startup that got acquired, um, we had 35 people or so, and we were doing our thing and it was kind of new and cool, and then we got bought by this much larger organization.

And so naturally we got folded into that organization and we started to look for efficiencies and we took some of our things that had been working that enabled us to take risks and reinvent in the market. And we lost some of those things because now we are folded into this bigger machine. And now any risks that we took impacted the risks of the much bigger organization.

Right? And so that actually slowed us down a little bit. And the, the, the new cool stuff that we were doing when I first started there started to become harder and harder. On the other end of the spectrum, maybe 12 years later, I was working at a big [00:22:00] company that wanted to reinvent itself, but was struggling to because of the mothership and our legacy products and customers.

And so instead of just trying to do it anyway, in spite of all these risks and, and challenges, we created a little, a little team that was separate. We took about 20 of us and got a different office. We worked in a different building, not too far away, just down the street, but we had our own culture, our own mindset, like we were shielded both legally and and financially.

Like by creating this new entity that had better risk taking practices because, you know, we, we had legally separated. Yeah. Yeah, yeah, exactly. And, and we knew that we weren't resting on the, the revenue of the, of the mothership, right? We, we had to make or break what we were trying to do there. And so, you know, we were hungry and we took more risks and we reinvented things and it, it was [00:23:00] actually dramatically successful.

Um, so, you know, thinking about that is like when you are trying to draft some dramatic change, first just create a pilot team. Give them a little more freedom than you're normally used to in your normal culture. And if it works, gradually grow that team, right? Send some more people over there, start doing a little bit more, start begging bigger customers.

Little by little that new team just becomes the organization, right? And that's a, that's a much better way to start. Try to just gradually create, uh, create change in a much bigger risk adverse organization.

Evan Troxel: When I was leading our digital practice team at the firm that I was at, you know, I, we, we talked a lot about digital practice,

Dan Chuparkoff: Yeah,

Evan Troxel: I always would reinforce, it's like someday we're just gonna call it practice again. Right? Like,

Dan Chuparkoff: yeah, yeah.

Evan Troxel: it's,

Dan Chuparkoff: Right,

Evan Troxel: at calling it something so that everybody knows what you're talking about, but you

Dan Chuparkoff: right,

Evan Troxel: be so influential and like you're saying like [00:24:00] the, the balance tips at some point where it becomes the bigger thing, because the way you used to do things is falling off the back, back of the conveyor

Dan Chuparkoff: right, right. Right. And, and it, and the both things coexisting is super normal and it shouldn't feel weird to people on either side. Right? Like the, the existing product still has customers that expect those existing things, and it, and those, those customers will want to be customers for a long time. It's okay that that starts shrinking as long as people have, you know, another, another place to go.

As you know, as the new world or the new digital world, the new AI powered world, you know, starts to become a bigger and bigger part of the business. Mm-hmm. Right, right, right.

Evan Troxel: were out there

Dan Chuparkoff: Yeah.

Evan Troxel: do the same thing that you, you said they had to move into a different building because there was, there's a lot of [00:25:00] naysayers in the existing organization and there's a lot of influence about, well, we're going this direction, why are you doing that over there?

And, and

Dan Chuparkoff: Yeah.

Evan Troxel: have to create that separation at some level that you're talking about. Or because it's unlikely that everybody's gonna be on the same page, that this is a good idea and there's no guarantee that it's gonna be successful anyway. Right. And

Dan Chuparkoff: right, right, right.

Evan Troxel: that separation, I think is a, is a key component of what you're talking about.

Dan Chuparkoff: Yeah. Co Completely agree. 'cause, 'cause yeah, there are no guarantees that it's gonna work. In fact, most of the time it does not work. Right. Like most new things that the organizations try aren't successful. And so, you know, it, that takes a different appetite for, for risk. Personally, a different, like family situation.

Like all those things can be different. So, you know, while you're in those intense moments of risk, let the people that are comfortable in that, in that world, like inhabit it by themselves for a little while, while they're trying to figure it out. Um,

Evan Troxel: and that fear [00:26:00] is so real that it keeps a lot of people from trying it. Right. And, and,

Dan Chuparkoff: yeah. Yeah. Yeah.

Evan Troxel: you know, I just wanna reinforce here that it's like, either way you're gonna learn something.

Dan Chuparkoff: Right. Right, right, right, right.

Evan Troxel: it might not be, no matter what.

Dan Chuparkoff: Yeah.

Evan Troxel: will get made. It's not like, if it doesn't work, that is a complete failure.

We don't get anything out of it. Right.

Dan Chuparkoff: Right, right, right. Figuring out some things that don't work is an important thing that more organizations should do.

Evan Troxel: Yeah.

Let's take a quick break from the conversation to tell you about Avail. Is your team struggling to find the BIM assets they need? Avail's content management system simplifies access to all of your firm's content in one easy to use platform. No matter where your files live, or what type of files they are, you can easily search and access them from Avail.

Evan Troxel: Now, designers can consistently find and reuse all types of content. So what does that mean? Well, standards compliant models and drawings are easier to create. The documentation [00:27:00] process is less chaotic, new hires are easier to onboard, projects are delivered faster with fewer errors. You get the idea.

Visit getavail. com to try Avail for free and request a free demo. That's getavail. com, G E T A V A I L dot com. My thanks to Avail for supporting this episode of the TRXL podcast. And now let's get back to the conversation.

How would, how would an architecture firm, I mean, there, there definitely are examples of, and I've interviewed people on this show who've done this. Like I, I think of like, there's a structural engineering firm, a Thornton Thomasetti, who started what they call Core Studio, which grew out of their advanced modeling group.

And,

Dan Chuparkoff: Yep.

Evan Troxel: um, I mean, so it, it really was kind of like they incubated this thing, but, but kinds of. Advice would you say like helps get people in the mindset of, of okay, I think we've kind of established why that could be important, but then

Dan Chuparkoff: Right, right.

Evan Troxel: you, how do you do it? and architecture firms are not set up to be [00:28:00] incubators.

They're

Dan Chuparkoff: Yeah. Yeah. Right.

Evan Troxel: know, like some, some of them think like that. They think hackathons and they think incubate ideas and they think turn

Dan Chuparkoff: Hmm.

Evan Troxel: and they, you know, they, they think about it that way, maybe through experience, but a lot of them haven't. So I mean, is there anything that just comes out from you that when, when you talk to firms like this.

Dan Chuparkoff: Yeah. I think the first thing is, um, even before there's any kind of a formal practice, whether you have an incubator, whether you have like a, a a a next generation, you know, project team or, or anything that's, that's formal and getting resources just. Supporting the notion of learning some new things or trying some new experiments is the first thing culturally that's important before you can do it procedurally and, and, and formally with, with a whole new, you know, division of your company.

First you have to like, get people comfortable just trying new things for no reason, right? Like getting a [00:29:00] software subscription that you're not sure you need yet just to start kicking the tires and see like, if you had this new thing, what would you do with it? And, um, most people flip the, uh, flip the learning until after the decision was made.

They're like, okay, we're going to decide to get Revit, and nobody's used it yet, but we, we had this big committee and they decided that it's worth the $5 million or however much Revit costs. I don't know.

Evan Troxel: A lot

Dan Chuparkoff: Right. But, um, but like, they, they make this formal declaration first, and then they give everyone the new tool, and then everybody's thinking there, shit, now I have to learn it.

Now it's part of my job. Now I,

Evan Troxel: other job. Yeah.

Dan Chuparkoff: right, right, right. And so way before that, you need like a, a sandbox to play in, right? Like, like get some new tools for a week, just get the trial and say like, Hey, next week is playing around with new [00:30:00] tools week. And just let people explore a little bit or give them, you know, at, at the company Atlassian that I worked at.

We had, um, we had a $500 a year budget to just buy some software that we thought might be helpful, like we could get a new trial, single person account of whatever we wanted. There was no approval process as long as we were under that cap. And that allowed us to play around with new tools like HubSpot before they were big.

Um, the, just, just kick the tires and see like, could this help me do my job better? Um, and the people on the ground, they're the ones that usually know if it can actually do their jobs better. Um, and, and we sometimes pulled,

Evan Troxel: to them.

Dan Chuparkoff: yeah. Yeah. Yeah.

Evan Troxel: I also think about like the Google example of 20%. I don't know that they still do still do this, right? But this idea of 20% of your time was used for side projects. Some of those really paid off for them, right? Gmail was an example of, of one of those projects that somebody was coding.

You know, what is it, one day a [00:31:00] week or whatever.

Dan Chuparkoff: Yeah, yeah, exactly. Um, there, there, uh, there that practice still exists. For those listeners that don't know, Google's 20% time is an informal, uh, project or process that, that just says one day a week, you're allowed to work on anything you want. It doesn't have to be your formal team. It doesn't have to be the product that you're assigned to.

What, what actually happens is sometimes a person will just take a training class and they're just gonna disappear every Wednesday afternoons for a while. Um, sometimes four or five people will get together every Friday and say like, Hey, we could maybe create a new project here. Do you want to try it?

And they'll do that for a while, and you can, you can spend some amount of your time. It's not always 20%, it's not universally applied, but what it is, is a, an awareness that learning new things is maybe not just as important as your day job, but more important. Than your [00:32:00] day job. And so it's not a distraction from the work your, your work is a distraction from the r and d

Evan Troxel: Interesting.

Dan Chuparkoff: um, 'cause the r and d stuff that you're doing, that's the next 25 years of your company's revenue.

Like, that's dramatically impactful time. And a, a lot of people think of that in the opposite way where it's, you know, it's getting in the way. We don't have time for that. We have customer deliverables and you have to keep your utilization up and, you know, all those things are hard.

Evan Troxel: That, that's the first time I've ever heard that being mentioned, so I'm really glad that you mentioned it. And, and I'm also curious if you could kind of expand on expectations around these side projects, because I think a lot of times it's like, well, if, if this, if every single person who partici participates doesn't bring something back to us that was quote unquote worth it,

Dan Chuparkoff: Mm-hmm.

Evan Troxel: they get cut off and somebody else ne needs to.

But I don't think it was like that. I mean, tell, tell me how,

Dan Chuparkoff: Yeah. Yeah, it's, it is certainly if you're, if you're [00:33:00] spending, um, like if you're spending money that isn't time at Google on a 20% project, for instance, you and me, we start a new startup and we have servers running now and we have users logging into some product that we're not even charging for. We're starting to consume organization money at that point.

And so that's fine as long as we have a monetization plan and as long as our user adoption is growing and those people are referring new people in and we have organic, um, adoption, and that demonstrates that the product that we built has value Outside of that, if it's just me and you spending some of our own time, that's just education and there's not a great way of measuring that.

Education made you smarter or didn't so. Yeah, right. Uh, but Google has a sort of, you know, empowering trust, uh, approach to measuring that. And if you're doing stuff that you feel like is making you better, and you always have to [00:34:00] explain it to your boss and, you know, talk to your boss about what you're doing and what you're getting out of it.

And so as long as you can confidently have that conversation, then you can, you can get a little autonomy to, to try and learn new things. Um, so that's, I, I think the two sides of that, if you're spending money, there has to be real, like demonstratable customer growth. If you're not, if it's just for educational purposes, then you, then you have a normal leadership conversation with your normal boss like you do about other, other things.

You try.

Evan Troxel: Yeah,

Dan Chuparkoff: Right,

Evan Troxel: it's, it's interesting to think about it also from the, the context of like, it could become a thing

Dan Chuparkoff: right.

Evan Troxel: the company gets the thing, they get the benefit of the thing,

Dan Chuparkoff: Yeah. Yeah.

Evan Troxel: not gonna get snatched up by somebody else outside.

Dan Chuparkoff: Right, right, right, right, right.

Evan Troxel: it's

Dan Chuparkoff: Yeah.

Evan Troxel: at that point, right? You've, you've basically

Dan Chuparkoff: Yeah.

Evan Troxel: r and d of it.

Dan Chuparkoff: Right, right, right. And, and now imagine, imagine your Google and, right, and Evan and Dan, we started to create this side project, and Google didn't actually believe in it, but we [00:35:00] did. And they wouldn't let us work on it anymore. So you and I quit and we start our own startup and we get, you know, $8 million of investment and then we build our own product.

And one day Google wakes up and we're competitors. Right. And so, you know, invest in your own people. 'cause um, you know, they'll, they'll invest in themselves.

Evan Troxel: if they, if

Dan Chuparkoff: Yeah.

Evan Troxel: chance. Yeah. Yeah. I, I just don't see that kind of idea is really taking hold in the architect or a EC industry. Right. And, and I, I, a lot of it comes from where we've come from and, and

Dan Chuparkoff: Mm-hmm.

Evan Troxel: operated, but also. it's just not like the way that we're taught to think about our companies as design problems or, or even, or

Dan Chuparkoff: Right, right. Right.

Evan Troxel: a, an employee about how you would think about contributing to, to your company and, and making that the argument to do that.

Dan Chuparkoff: Yeah, it's, it's, I think one of the things, we'll talk a little bit more about like creativity and, you know, [00:36:00] technology and the AI revolution and what that's gonna do. Uh, but like, one of the things that makes me optimistic about the problem that you just observed is as we start using technology to.

Propagate our design productivity to help us do more things, help us do things faster, help us make more complex designs, more, more levels of detail for those designs. Like we, we start using technology as a, as a dramatic productivity accelerator. Then we actually start becoming technology companies and the, and the things that you're doing that, that take, you know, new tool adoption and take, you know, experimentation and, and educational, uh, experiments.

Those things all start to look just like it looked inside of Google or inside of any other software startup I've worked. The more, the more we sort of technology empower the [00:37:00] world, the more. Companies that traditionally don't feel like they're technology companies are actually becoming technology companies, and they'll start to benefit from hackathons and, and software acquisitions just like all the others.

I think

Evan Troxel: So to get ahead of that curve, or if that's like of super interest to somebody, do you feel like they really need to hire people from outside of the architectural training and background and kind of typical structure of a firm get that expertise in, to help them get to that point faster?

Or, or is that something that can be done from, from inside?

Dan Chuparkoff: I, I think it, it should probably be done both ways, right? I think you should cross pollinate with technologists or scientists or mathematicians or, you know, artists from other. Other industries because those people will have done some experiments that you haven't done. Um, but you also shouldn't let them come in and take over completely because they don't know your [00:38:00] industry as well as you do.

So from the inside, you should also, you know, merge those two streams together so you get, you know, industry validated thinking and, and vision, right? Because you know where your architecture industry is trying to go. And then these other people will give you new tools and practices that maybe, uh, maybe unblock some things that are blocking, uh, the road to that place.

Evan Troxel: There's an example that came to my mind when you were saying that, which was there was like a healthcare studio. the healthcare studio really, really, really wanted to only hire healthcare. Architects

Dan Chuparkoff: Mm-hmm.

Evan Troxel: right? Like there's an efficiency there, um, there's experience there, and so therefore you can maybe get a better product than you're used to producing maybe faster. and at the same time, I think what, what you're actually talking about here is you're talking about the cross pollination of ideas and experiences. Because as a designer of architecture, I wanted my team to be extremely [00:39:00] diverse and not

Dan Chuparkoff: Right.

Evan Troxel: on one project typology because they're gonna bring something to the table that I would've never thought of.

And there's kind of a, a bit of a battle in those two different ways of thinking. And I think that, that, that's probably on all over the place.

Dan Chuparkoff: Yeah. I, I a hundred percent agree that it is, I think if, if you're doing, um, if you're doing work that's. Really close to the same every time, and you're trying to get it done faster and cheaper. Um, and maybe, maybe incrementally better than getting people that have done that thing over and over again is the best way to do that.

But if, if you're trying to do something brand new, some of your like legacy experience gets in the way of reinventing the way you do those things. Um, and so, you know, bringing somebody in that's only worked on, I don't know, schools instead of hospitals or the other ways either for me to imagine, right?

Somebody that's designed emergency rooms thinks about [00:40:00] efficiency of room movement and moving patients in and out and cleanliness in, in, in ways that like other architects don't know. And so, you know, you bring hospital architects into. Uh, um, auto mechanic architecture, right? They, they would, they would create a body shop that was magical, right?

And that, and that would be, that would be amazing. Um, and I don't think people are doing that enough. And, um, I think, uh, that, that cross pollinization can, can breed some new invention, some re rethinking of, of old ways of doing stuff.

Evan Troxel: I think it applies, you know, way beyond design and, I mean, I'm not, I'm not trying to con what you're saying at all. It's like, and um, I feel like an architect should be on the board of every different kind of community group there is out there because the way architects think is so different than the way everybody else got their training and the way

Dan Chuparkoff: Yeah, [00:41:00] yeah, yeah, yeah. Right.

Evan Troxel: me is a huge advantage that architects have. And it's a beautiful service to these other organizations. Like if there's somebody on, you know, it's not, it's not even just like city planning, which is still kind of in your wheelhouse, right. But it's like something else completely like the way your church operates, for example, or

Dan Chuparkoff: Yeah, yeah, yeah,

Evan Troxel: the Girl Scouts or anything like that.

It's like you would, you have just a different. Approach to problem solving. and I think we could, as architect could, could do the same. Right. We could

Dan Chuparkoff: yeah, yeah, yeah,

Evan Troxel: out of that as we could give to it in another context by bringing in the kinds of people that you're talking about who have just this very big difference in, in experience.

Dan Chuparkoff: yeah, yeah, yeah. To totally agree. I, you know, generally, uh, I. Diverse thinking. It often un unlocks new ideas that wouldn't have been there before. And that diversity can be, um, you know, the kind of d cross industry diversity. It can also sometimes just [00:42:00] be age diversity. Like bring a brand new person in, like letting an intern sit in your board meeting for a while and just talk, like, talk.

What do you think, right, as a person that's grew up with an iPhone in your pocket as a, you know, 22-year-old, what do you think about how you navigate spaces, how you solve problems that unlocks whole new ways of thinking sometimes. And so, um, you know, there's a lot of, you know, a lot of use of the word diversity a lot of the time right now.

But, um, most people don't think about it in the way of cross industry diversity or cross generational diversity. We're not, we're not doing that as much as I think we could.

Evan Troxel: The typical mindset is like that we're gonna, the young people are gonna learn from the old people, but it's

Dan Chuparkoff: Right.

Evan Troxel: that is bi-directional in this right? It's

Dan Chuparkoff: Yeah. Yeah.

Evan Troxel: I, I'm sure I've brought this up on the podcast before, but there's a thing I've heard of, and I, somebody can fact check me on this, but it's like this Japanese corporate meeting culture, which [00:43:00] is. The youngest people, so the interns, for example, get to do all the speaking in the meeting first,

Dan Chuparkoff: Yeah, yeah, yeah. That's,

Evan Troxel: then they're not, they're not going to go against what an somebody who's been

Dan Chuparkoff: hmm.

Evan Troxel: a long time is going to say, because they don't know what they're gonna say.

Dan Chuparkoff: Right, right,

Evan Troxel: there's, as long as they have the, they feel safe enough to share and, and not get stepped on by doing it.

Right. This is used as a tool by the older generations who run these companies to get new ideas and make it a safe place to do that. And, and so you kind of need all that for that to

Dan Chuparkoff: Yeah.

Evan Troxel: right? Because

Dan Chuparkoff: Right.

Evan Troxel: only gonna work the first time and then somebody's gonna get stepped on and they're like, I'm never gonna talk again in these meetings because Right.

Dan Chuparkoff: Yeah. That didn't, that didn't work out very well for me.

Evan Troxel: I thought that was a really interesting kind of strategy and how to

Dan Chuparkoff: Mm-hmm.

Evan Troxel: those kinds of interactions in those, in those meetings.

Dan Chuparkoff: Yeah. Yeah, yeah. Completely agree. I hadn't actually heard that before, [00:44:00] but, uh, I, but I love that analogy. Uh, that,

Evan Troxel: again, but, but if it, if it isn't, they should, we should all do that.

Dan Chuparkoff: yeah. Yeah, yeah. I totally agree.

Let's take a short break from the conversation to invite you to join the most influential technology leaders in the AEC industry at Confluence. Composed of in person events and a podcast co hosted by yours truly, Confluence is designed to foster conversations between AEC firms and technology companies so they can learn, share, and engage with each other to support industry innovation.

Evan Troxel: Software company Avail, which creates content management solutions for the AEC industry, started hosting Confluence events in 2019 to understand what firms are needing, wanting, and thinking around technology. To learn more about Confluence, explore upcoming events, and listen to podcast episodes, go to confluence.

getavail. com. My thanks to Confluence for supporting this episode of the TRXL podcast. And now, [00:45:00] let's get back to the conversation.

one thing I wanted to talk about with you is just kind of the reason I wanted to go into kind of the pace of change was because, you know, I think that we're seeing that behaviors, workflows, skills that were relevant just a few years ago maybe aren't as relevant or just aren't as needed now. And I mean, you have a huge focus on what's going on with AI and you're really keeping your fingers on the pulse in that.

And that's where we're seeing a lot of this disruption. And I, I just think again, about this idea of entitlement to like our, our business is, should we be here in the future? Of course the answer is yes. Right?

Dan Chuparkoff: Yeah. Right, right, right,

Evan Troxel: Like, I don't think it's a guarantee people aren't. Participating in the act of change. And

Dan Chuparkoff: right,

Evan Troxel: from, from, from your point of view, like of forced adaptation, um, things that people might do to [00:46:00] disrupt themselves or not be disrupted right. In the future.

Dan Chuparkoff: right, right, right.

Evan Troxel: around for something's gradual and comfortable to happen. Um, and so just from, from your point of view and, and I mean maybe we start to transition really to talking about AI here.

Like what are,

Dan Chuparkoff: Yeah.

Evan Troxel: are you seeing with this kind of skills being uprooted and not needing people to do things and, and the way that it's radically changing industries.

Dan Chuparkoff: Right, right. Yeah. Yeah. So, so first I'll, I'll say I, I'm, I'm very optimistic that there are some things that AI is never going to be able to do. Um, a AI is very constrained by the training data that we feed it. And there are, um, that because of that, it, it kind of only knows the commodity kinds of things about the world, the things that lots and lots of people know and talk about publicly, or at least in places that have been scraped.

Um. [00:47:00] That's a small set of the stuff that we actually use to make decisions. Um, so I think that AI will always struggle to, to do real problem solving. Um, when you decide on the right solution to a problem, you're doing that with context in your head, what you saw yesterday, you know, the conversation that you have with your wife or your, your partner.

The, the, the, you know, all the things that you imagine about the world. Those things help you make decisions and AI won't ever know those things. And so problem solving and decision making, and even just pulling the world to a new place that we're imagining we want to go, those are things that AI can't see.

Um, and so the kinds of things that we do as people are first process stuff. We do things over and over again. We get tasks done, we communicate about that work, we look for issues. Those three [00:48:00] things AI is gonna be really good at. But the other three things, making decisions, solving problems, imagining a better world.

AI won't ever do those things. So if you can sort of take your work and, and tease apart those first three things, and the second three things you'll start to see that your job just becomes problem solving over time. Your job is to like look at the weird stuff that a, I can't figure out what to do and figure out what to do.

Right? That's what, that's what your job over time will become. And I think that will exist forever. I think we'll, we'll always have safe, secure places as people in any industry, as long as we like, adapt what we do and give away some of the commodity stuff that AI is better at than us. Does that make sense so far before.

Evan Troxel: Yep. Yep.

Dan Chuparkoff: Um, I think the, the second thing I will say about it is [00:49:00] in, in most cases when, when we look at some of the big technology things, we, we got it. Phones were, were mostly, were mostly mobile and app driven or, or mobile browsing. Uh, now in the world, it's only been really 10, 12 years since we started that transition and all of us became like mobile capable fairly quickly.

The internet right, completely changed the way we looked for and shared information. After 10 years or so, we all became great at internet stuff. Um, that will also happen with ai. We'll probably just gradually start embracing it and 10 years from now we will, we'll say, okay, well, yeah. Inter AI stuff is just, that's just how we get information Now, I don't read.

Long papers anymore. I just read the digest from my AI assistant. Um, so that that change will happen sort of slowly and gradually, so it shouldn't freak people [00:50:00] out because you will have some, you know, ramp toward, toward that happening. But now if you resist it, right, and you, you try to say, but yeah, but the, the, um, the CAD machine in the basement of Dan's first job, the drawings that come outta that are garbage.

I'm not gonna use CAD because the garbage designs that come out are not things that I would want to use. If you resist it completely and completely ignore it, and don't expect that it will constantly get better, then you will become one of those draftsmen that I worked with in 1986 that never learned cad, and that would've been, that would've been bad for them, right?

Evan Troxel: Yeah. Yeah. It, the, this idea though, I think is, is exacerbated by the constant fire hose of news, right? Of you've

Dan Chuparkoff: Mm.

Evan Troxel: this right now. And so I'm curious

Dan Chuparkoff: Right, right, right.

Evan Troxel: like do, how, how can you get by without having to really like, dive [00:51:00] in and, and become a deep, deep, deep committer to this

Dan Chuparkoff: Yeah, yeah, yeah.

Evan Troxel: what do you

Dan Chuparkoff: there.

Evan Troxel: like is the best way to kind of that ramp that you're talking about?

Dan Chuparkoff: Well, so first there's a, there's a pretty hard line in time. November, 2022, that's when chat UPT first came out, right? And, um, if you were in school in November of 2022, all of a sudden everyone said, Hey, just put your homework in Chate. You'll be amazed,

Evan Troxel: Yeah, students

Dan Chuparkoff: everyone

Evan Troxel: are always looking for the shortcut too, right? Like

Dan Chuparkoff: right.

Evan Troxel: there's so much incentive to do, so, yeah.

Dan Chuparkoff: Right? Yes, exactly. So, so if you were, if you are, uh, what I, I don't know what age that may be, makes you 24 or younger. So you were in school on the chat, UPT day. All of a sudden you, you used chat UPT for everything. There's no going back. Like you put every [00:52:00] email in there, every social post, every, every article you write for the blog, every book you write, like you just, you just use it.

And so that, that age is, is, you know, entering the workforce. Those people are your coworkers, they're your competitors. And, and those people are AI powered already full stop. And so first you don't have to go all that all the way there. You don't have to put every, I don't know, design into, into some AI powered design assessment tool.

But start dabbling with it because one day you're gonna wake up and your customers will choose not to award you an RFP, and you're gonna find out it's because they went with this other team and that other team is using some AI thing that you're not using. Um, and so, you know, you don't really need to change until your customers are picking the other people.

Um, that's [00:53:00] when you have to,

Evan Troxel: Yeah.

Dan Chuparkoff: and so anticipate that that's coming and start dabbling, start playing around with it. Start figuring out, you know, what it could do for you, what you trust and what you don't trust. Uh, you know, start hiring some people that are 24 or younger and asking them what they think, what they do with it, and, and start the exploration.

Uh, the next five years is gonna, it's gonna be an interesting, uh, uh, flip. It'll be the fastest technology adoption, um, I think that we've ever seen.

Evan Troxel: Yeah, that, that's an interesting graph to track, right? Because it

Dan Chuparkoff: Hmm.

Evan Troxel: if you, I, I think that there was a graph that showed like the telephone, an adoption of the telephones in houses, right? Landline

Dan Chuparkoff: Right.

Evan Troxel: versus like the cell phone. And I think the cell phone was like a 10th of the time because it was like 50 years of adoption for landline. Telephony, and then you've got cell phones and I mean, this is before smartphones, quote unquote

Dan Chuparkoff: Yeah, yeah, yeah. Right, right, right.

Evan Troxel: Nokia, right? Everybody had a [00:54:00] Nokia pretty fast. And, and so, and that was, that was 2000, I don't know. That was a long time ago. Right? Probably

Dan Chuparkoff: Right, right, right.

Evan Troxel: I, the Matrix 1999 had the cool slide out Nokia, you know, Neo had

Dan Chuparkoff: Yeah. Yeah, yeah, yeah.

Evan Troxel: cutting edge tech at that point.

Right. And,

Dan Chuparkoff: Right.

Evan Troxel: you think about how fast AI since you said 2022, right? November

Dan Chuparkoff: Mm-hmm.

Evan Troxel: 2022 is when Chachi PT rolled out. And now look at where it is. And it's the beginning of 2025, right?

Dan Chuparkoff: Right, right, right. Yeah. And, and you know, also I want, I want to, I want to be clear, what AI can do right now is mostly language processing. So if you're, if you're taking, if you're having a meeting with a bunch of people and you say a bunch of stuff, having an AI note taker in the room with you to log what was said in the meeting, what decisions were made, what action items were there, that's a great idea.

Um, it will transform the efficiency of communication [00:55:00] across your team. Um, if you're writing content and it's gonna be read by people that are maybe outside of the US maybe now you can publish content in five or 10 or 25 different languages, right? So you can reach your whole global audience instead of just the, the one you've speak to in English.

Those are things that already are working really, really great and global teams should be doing those things already, um, in a EC, you know, to, to have a, a structural engineering drawing and put it somewhere and say like, what are the flaws in this drawing? That technology is really in its infancy right now.

Like, we don't have the, that kind of stuff just isn't in the training data. And so when we say ai, I wanna make sure I, I distinguish between language processing stuff. And graphical image [00:56:00] processing stuff. 'cause uh, a lot of the design stuff that requires precision in images is still a long way off because that stuff wasn't enough in the training data.

Now companies like Autodesk and, and the others are going to make great things, but, but that, that road there is a little bit slower.

Evan Troxel: And, and just to kind of throw in some other ideas about what I've seen going on in this space is, is like, uh, very small teams developing. Language based interfaces to produce code, to build geometry in real time in your modeling application like

Dan Chuparkoff: Right, right, right.

Evan Troxel: right? But it's still language driven to code something that would

Dan Chuparkoff: Yep.

Evan Troxel: take somebody a lot of trial and error or a lot of experience, right? You gotta

Dan Chuparkoff: Yep.

Evan Troxel: for that time to create this stuff either way, versus, oh, I wanted to, you know, round off the corners on the 15 floors at the same time, and, and it creates the code [00:57:00] that lets you execute that and then you can use it again and again and again and again, and all of a sudden, like you have to find ways. To leverage the existing tools to do little things in the bigger

Dan Chuparkoff: Right, right, right.

Evan Troxel: It's not just

Dan Chuparkoff: Right.

Evan Troxel: it's not just for project managers and people processing a lot of email. It can be for designers too, or without going full on down the IP role of like it generating design ideas that that Then there's like questions over where that came from and ownership and all that kind of

Dan Chuparkoff: Yeah. Right, right, right,

Evan Troxel: Yeah.

Dan Chuparkoff: right. Yeah, exactly. Or even just the structural integrity of, of, of the shape that your

Evan Troxel: Right.

Dan Chuparkoff: journey, uh, design came from or whatever.

Evan Troxel: Yeah.

Dan Chuparkoff: Um, but yeah, that, that's a great example. And, and that's, I think another, another place where we could bring that cross pollenization of industry back.

Um, if, if you hired a random non-architect software engineer to come in and just like look over the shoulder,

Evan Troxel: Right. [00:58:00] Yeah,

Dan Chuparkoff: uh, they would find. Amazing efficiency things that you're gonna overlook. Uh, if you're not a software engineer. One of the things we always say about great, great software engineers are the laziest ones, right?

They wanna, they wanna do the least amount of work possible, and so they'll find ways of like automating some of that stuff. And that that will definitely help in the a, EC.

Evan Troxel: The question then is, how can a EC afford those people? Right. Because,

Dan Chuparkoff: Yeah.

Evan Troxel: but, but you, you get what you pay for on some level when,

Dan Chuparkoff: Yeah, yeah,

Evan Troxel: Yeah. Right.

Dan Chuparkoff: yeah.

Evan Troxel: let's talk more about creativity, because this idea you, you posted on LinkedIn and you talked about how ai, um, it what creativity is, and then what you thought.

You've already got into this a little bit, what, what CRE creativity will never do, when

Dan Chuparkoff: Yeah.

Evan Troxel: to. Caring like that. That's a big one, right? You, you talked about that AI won't care. Um,

Dan Chuparkoff: Mm-hmm.

Evan Troxel: and so the, the thing that [00:59:00] really interests me about this topic or this, this, this framework of, of what AI can do as a tool and where do humans fit into that process, especially as architects, which is, it's about, it's actually about the human experience.

And then there's all this other stuff we have to do to make it actually physically work in the real world as

Dan Chuparkoff: Right, right, right.

Evan Troxel: Midjourney doesn't do that, right? It's, it's images and okay, maybe it thought us, you know, it, it drew a picture that, oh, I'm going to pursue that, go down that road, and then we can actually reverse engineer and then, you know, so take it a few steps back. Interject some other client ideas and then move forward and actually come up with something. But then there's this whole like, okay, we have to produce these drawings. We have to produce these details, we have to get it through the permitting process. We have to go through the bidding pro, all these things that architects have to do.

And so there's like, there's not a lot of threat there, but, but this idea of

Dan Chuparkoff: Right.

Evan Troxel: the, what I like about this is that it actually brings us closer back to our true value as what architects can do, which is not just commodity stuff anymore, right? The,[01:00:00]

Dan Chuparkoff: right, right,

Evan Troxel: of design and tools, uh, uh, like it's, it's gross, right?

Like it's

Dan Chuparkoff: right, right.

Evan Troxel: we don't need more of that. We actually need architects to actually realize their true value and be able to apply their time and energy into that. And maybe this is a way to start doing that.

Dan Chuparkoff: I, I think it is, uh, right. I think the, um, there, there, because our, because some of our processes are so heavy, there's so much stuff we have to do just to get the thing to the point at which it's built. You know, there's, there's one day at the beginning of the project that's super fun where you're like, just sketching on a, on a napkin or a STA notebook and you're like, I can imagine this amazing building, this amazing space.

It's gonna be so cool. And then the fun ends for like, I. A year and a half, and you have to do all that other crap to get your napkin sketch to life. Um, you know, what should happen or what I'm optimistic that will happen is that the painful [01:01:00] stuff that, that shouldn't take as much human creativity and, and, um, and imagination and unique perspective and all that stuff, all the processing stuff should get automated so that you spend more time, you know, doing the fun part at the beginning.

And, um, I, that makes me really excited about the AI future, not just in a EC, but like that's, that I think will be true in, in medicine and in, in, uh, uh, software engineering and, and all the other industries too.

Evan Troxel: Yeah. Th this idea of like younger generations and change, right?

Dan Chuparkoff: Mm-hmm.

Evan Troxel: catalyst of change is the, when the bit flips and it's like, oh, there's some new

Dan Chuparkoff: Mm-hmm.

Evan Troxel: charge now. And because I think a lot of people think, okay, well yeah, you can spend more time on the project. And we'll, of course, we'll always that that's the, that's actually what BIM did, right?

It just allowed

Dan Chuparkoff: Right,

Evan Troxel: cram even more into the same. as we had before

Dan Chuparkoff: right, right, [01:02:00] right.

Evan Troxel: you know, more metadata, whatever it is, and, and all of the, that can be leveraged for good. Um, and at the same time, like, I like to think of it is like quality of life, right? Like you can

Dan Chuparkoff: Yeah.

Evan Troxel: wanna spend that time.

You

Dan Chuparkoff: Right.

Evan Troxel: it into the project, you could put it back into yourself. You could work less hours, you could go on that trip and get those experiences that then bring, you, bring back to your projects

Dan Chuparkoff: Mm-hmm.

Evan Troxel: can build better architecture because you've had those experiences. And like,

Dan Chuparkoff: Right, right.

Evan Troxel: actually feeds other, right?

It's, it's

Dan Chuparkoff: Right.

Evan Troxel: in, in a positive way. And I, my hope is that. We can actually use these tools as leverage so that we can have better experiences so that we can provide better experiences so that we can provide better products and not just work more or work longer.

Dan Chuparkoff: Yeah.

Evan Troxel: because

Dan Chuparkoff: right, right,

Evan Troxel: we've done that.

And I think that that's an interesting perspective from the younger generations as well. It's like, I'm not gonna do it like that. Like I, I see

Dan Chuparkoff: right.

Evan Troxel: do it, and I'm not interested in doing it like that. And a lot of [01:03:00] people are leaving or not going into the industry because of that. But I think I'm hopeful that the ones that do actually will have a, a different way of, of approaching the way

Dan Chuparkoff: Yeah. I. Yeah, I, I completely agree with that. I, I'm the parent of three sons. Uh, I have a 30-year-old and then 2 23 year olds. And they're, you know, as they come into the workforce now, they're, they have a completely different mindset, right? They're, they're not trying to work, you know, they're butt off for 50 years to get a gold watch and a pension.

Like, that's not, that's not their view of the world anymore. And, and they're, um, they're gonna approach work in a different way. They're gonna find efficiencies in their own work and then, and then split the dividend with their organization, right? Where they've got some efficiencies. So now I get a little bit more vacation time, and I can also do a little bit more work for your stakeholders.

Um, but then the, it's the, the, um, the dynamic has flipped for, for sure, for, [01:04:00] for some people younger in the workforce.

Evan Troxel: Yeah. I'm hopeful in that way for sure. I, I, I'm just curious, maybe wrapping up here, what you are most excited about or what you think maybe the biggest takeaways are. I'm sure even in the time in the year and a half, since you haven't been in Google, things have changed pretty radically so. What I'm, what I'm not looking for here is like, like you've even experienced this, right? With a year and a half of like how

Dan Chuparkoff: Mm-hmm.

Evan Troxel: are moving and so there's a lot of stuff that you probably even told people a year and a half ago that doesn't apply anymore. And so I'm trying to

Dan Chuparkoff: Yay.

Evan Troxel: a little bit of that, but like bigger picture, what do you, what do you think some of the takeaways are from this kind

Dan Chuparkoff: I think,

Evan Troxel: yeah.

Dan Chuparkoff: I think one of the things that excites me the most is, um, the ability for AI to help us communicate across language barriers more than we can right now.

Evan Troxel: Hmm.

Dan Chuparkoff: Um, you know, a lot of the global economy transacts in English right now because it's the one language that lots of people [01:05:00] know. And, um, and that's a little bit broken.

There are 6 billion people that don't speak English at all, and those people can't read. Most textbooks that were written, they can't watch most YouTube videos. They can't like, join most enterprises because they don't, they don't know how to understand, uh, the, the words that are being spoken. Um, I think AI translation is going to democratize access to information in the world in ways that are super interesting.

Evan Troxel: Kinda like

Dan Chuparkoff: enable. Yeah, yeah,

Evan Troxel: Yeah.

Dan Chuparkoff: yeah. Um, you know, we, we will probably in the next year have a toggle on our computer that lets us just flip the language that we hear and, and read when we get messages or we join meetings. You know, if, if we wanna speak Mandarin, we're gonna speak Mandarin and everyone else will get English or Spanish or German or whatever they like in real time.

Yeah. Like, those things already work in, in, um, in teams. That functionality is already there. It's not widely used. Um, but, but I [01:06:00] think that's the thing that excites me the most. 'cause I, I think this is a big world and lots of our organizations aspire to be global, but, um, our definition of global right now is, is a little bit broken.

Um, and it could be a lot more global than it actually is. And that, that's a, that's an exciting, like human, um, step change that makes me, um, makes me really, really ex excited about the next decade.

Evan Troxel: So do you think then, based on that alone, that corporations and teams should be thinking about business very differently and who their customers could be and what their footprint is and, and those kinds of things? Because it's, you kind of framed it in this idea of sharing information, but like. If you can speak Mandarin in real time and all you can actually speak is English in real time, actually changes things pretty structurally to what's possible with your business.

Dan Chuparkoff: I, yeah, I, I think that is, um, exactly, uh, my, my advice [01:07:00] for organizations, I think people are thinking about their, um, their customer market as a way narrower than it actually is. You know, there, there's a whole continent of Africa, you know, that's growing rapidly, like skipped over the non-digital ways of doing things right.

They jumped right to digital money. They, they jumped right to cell phones and never even installed, uh, telephone lines and cables and. Um, you know, there's a middle class in Africa that needs all the services that we all make every day here in the us. Um, there's a billion people over there, um, another billion people in, you know, India, uh, you know, billion and a half people in China.

That's just three of the countries, uh, Africa,

Evan Troxel: Yeah.

Dan Chuparkoff: uh, continent. But, um, you know, there's a, there's a lot of, uh, opportunity I think out, out there in the world that, um, that this new, new way of exchanging information, uh, will enable. And I think that could, you know, that will be opportunity on both sides for us [01:08:00] servicing them and for them joining, you know, the, the global economy.

Evan Troxel: You've played with that a little bit, and I'm just, my question, my guess, my final question is how, how much did you trust it not knowing the Mandarin that you've had it translate to?

Dan Chuparkoff: Yeah. Yeah, yeah. Yeah. So, so a, a couple things. Uh, all the translations that I've done so far with it, I've, I've given to a native speaker and they said there was one exception, uh, in Spanish. I said the word team and the word team that it changed was more like family then co coworkers. And so that one word is the only flaw that I've ever found.

It's, it's pretty close to accurate all the time, and it's certainly better than just not speaking to them in their language at all.

Evan Troxel: Interesting.

Dan Chuparkoff: Right? Yeah.

Evan Troxel: I mean, I think I, a final thought just thinking about like using multiple tools to check, like I, I know a lot of people use Chat g PT to check its own work, right? But,

Dan Chuparkoff: Yeah. Yeah.

Evan Troxel: ones too, and it's [01:09:00] like, okay, this tool did this, now let's have this tool check its work, and then maybe a third one.

And, and like between that and, and still the amount of time saved is just absolutely incredible.

Dan Chuparkoff: Yeah, I think it's, it's an exciting time. There's a lot of new stuff available to all of us. It can be scary 'cause that's sometimes overwhelming. Um, but also some of the things that it will drive will be amazingly empowering. It should give you more time in your own day for things like personal growth.

It should allow you to reach bigger customers with better services and, and products. And you know, I think these things have the ability to change the world if we let them. Um, so that's, uh, an ex, it's an exciting time.

Evan Troxel: Thanks, Dan. It's been a fun conversation. I've definitely learned a lot, and I'll put links to everywhere. People can get in touch with you, but if you wanna mention it here in the audio portion, still go for it.

Dan Chuparkoff: Yeah, I'm pretty easy to find on the internet. I have a unique last name. [01:10:00] It's Chu Park off, C-H-U-P-A-R-K-O-F-F. Uh, you can find me on LinkedIn. That's where I'm most active, but also all the other places, Instagram, uh, x or uh, or my own website, uh, dan chu park off.com. So, uh, here I am. I'd love to start a conversation with any of you.

Uh, it's fun stuff for me to talk about. So, uh, I, I appreciate you having me on Evan. It's been fun.

Evan Troxel: Thanks, Dan. Okay, so let's wrap this up before you take off. At the beginning of this episode, I said that change agents must lead their teams through technological change, and that was validated throughout our conversation. Dan emphasized that technological change is inevitable, accelerating, and can be deeply disruptive without proactive leadership.

So here are seven examples from the conversation that back this up.

Example, number one, change is constant and accelerating. He described how technological advancement, especially with AI, is progressing [01:11:00] faster than ever before. The tools available today weren't even possible just two years ago, and the pace of adoption is increasing.

He said the next five years is going to be an interesting flip. It'll be the fastest technology adoption that we've ever seen. Change agents must lead here or their organizations risk being left behind.

Example number two, resistance is common without leadership. Dan recalled his early experience in an architecture firm where CAD was initially rejected by architects despite its clear advantages without someone advocating for the long-term benefits of change, organizations tend to default to the status quo, even when it's less efficient.

Example number three, culture must ship before processes can. He emphasized that embracing new tools starts culturally, not procedurally, and that leadership has to create a safe, experimental environment.

Change agents cultivate a growth mindset and empower their team to [01:12:00] explore before formal adoption.

Example number four, legacy thinking stalls. Progress. Dan explained how older leaders nearing retirement often avoid change because they don't see the payoff within their timeline. In contrast change agents are essential because they bridge the generational gap and prepare the organization for a sustainable future.

Example number five, isolation enables innovation. He discussed how creating a separate innovation group, free from organizational inertia, can succeed under proper leadership. Dan said we created a little team that was separate. We had our own culture, our own mindset We reinvented things and it was dramatically successful.

Change agents lead by shielding innovation from internal resistance and giving it room to grow. I'll say that again. Change agents lead by shielding innovation from internal resistance and giving it room to grow.

Example number six, AI is already transforming workflows. Dan [01:13:00] highlighted how younger generations are already natively using AI tools. and if change agents don't lead adoption, they risk becoming obsolete as clients and competitors move forward.

And lastly, example number seven,

without leadership, fear wins, fear of the unknown or failure can paralyze teams. Dan and I both acknowledge that the fear is so real that it keeps a lot of people from trying new things, Change agents are the antidote to this fear, and they provide vision, permission, and momentum to move forward.

So in conclusion, change agents are not optional in this era. They are mission critical for navigating rapid technological shifts, fostering curiosity, overcoming fear, and ensuring their organizations thrive rather than stagnate. That's it. Thanks for listening, and I'll see you in the next episode.

​[01:14:00]

Summary

In this special Campfire Series episode, I sat down with Ian Keough—widely known as the father of Dynamo—for a deep dive into the origin story of one of AEC's most transformative tools.

From humble beginnings in a mezzanine at Buro Happold to becoming a foundational pillar of computational design inside (and outside) of Revit, this episode recounts how Dynamo evolved from a scrappy utility library into a global platform with millions of installs and a vibrant community of computational designers.

Key Takeaways

Matt Jezyk joins the podcast to talk about his journey from architecture to software development and his pioneering work with platforms like Autodesk Revit, Dynamo, and now Motif. We discuss the evolution of design collaboration tools, the impact of new technologies on the architectural design process, and how embracing real-time collaboration and cloud-based systems can revolutionize the AEC industry. Key discussion points include the challenges of modern software design, the advantages of integrating multiple platforms, and the future of AI and machine learning in AEC design.

Watch this episode on YouTube:

Episode links:

Connect with the Guest

• Matt Jezyk on LinkedIn
• Motif on LinkedIn

Tools and Emerging Technologies

• Motif
  • Motif Official Website
  • The collaborative design platform discussed in this episode, focusing on modern workflows, real-time feedback, and dense information continuity.
• Dynamo for Revit
  • Autodesk Dynamo Page
  • Parametric and visual scripting tool co-created by past podcast guest Ian Keough—key to computational workflows that Matt Jezyk helped bring to life.

Visualization & Design Tools

• Figma for Architects
  • Figma Official Website
  • The web-based collaborative design tool cited as inspiration for Motif’s approach to real-time, multiplayer design environments.
• Miro – Collaborative Whiteboarding Tool
  • Miro Official Site
  • Frequently used during the pandemic for remote architectural collaboration—worth exploring as a stepping stone to more integrated collaboration platforms like Motif that feature an “infinite canvas”.
• Bluebeam Revu
  • Bluebeam Revu
  • Still widely used for PDF-based markup workflows in AEC; understanding its limitations helps illuminate the “data loss” problem Motif aims to solve.

Modular Construction and Innovation in Building

• Factory OS
  • Factory OS Website
  • A leading U.S.-based modular construction company tackling housing affordability through prefab innovation.
• Katerra (post-mortem)
  • Belinda Carr: The Rise and Fall of a $2 Billion Construction Prefab Startup | Katerra
  • A sobering case study in VC-funded AEC disruption, referenced by Matt in the discussion.
• WeWork’s Construction Playbook
  • Construction Dive: Q&A: How WeWork's construction team is using tech to scale up
  • A deep dive into how WeWork achieved industrialized construction at scale, echoing themes of repeatability and process optimization.

Psychology and Personal Development

• Daniel Kahneman’s Thinking, Fast and Slow
  • Amazon Link
  • Useful when considering how we make design decisions under pressure and with incomplete information—core to Motif’s mission.
• Julie Dirksen’s Design for How People Learn
  • Amazon Link
  • A guide to designing user-centered tools and platforms—very applicable to user interface thinking in AEC software development.

Recommended TRXL Podcast Episodes

For further exploration of topics related to collaboration, design technology, automation, AEC innovation, and the evolving role of architects in the digital age, consider these episodes:

• Episode 180: ‘The Dynamo Story’
  • Ian Keough tells the origin story of Dynamo and takes us on a journey through its evolution from a simple idea to becoming an essential tool in computational design.
• Episode 179: 'Analyzing AEC'
  • Matt Wash and Konrad Sobon discuss digital transformation, enhancing productivity through data insights, and understanding a company's digital footprint.
• Episode 163: 'Confusing Evolution With Innovation', with Nirva Fereshetian
  • Nirva Fereshetian explores the complexities of implementing digital practice in architecture firms.
• Episode 168: 'The Challenges of Under-Digitization in AEC'
  • César Flores Rodríguez addresses challenges and opportunities in digitizing AEC.
• Episode 158: 'AEC is an Adhocracy'
  • Andy Robert and Mercedes Carriquiry discuss leadership and change management in AEC.
• Episode 165: 'Transitioning to Leading People in AEC Tech'
  • Phil Read and Adam Thomas share insights on transitioning to leadership roles in AEC tech.
• Episode 177: 'The Digital Futures of Architectural Practice'
  • Kristen Forward discusses the impact of emerging technologies like AI and machine learning on architectural practice.
• Episode 137: 'Accelerating Tech in AEC'
  • German Aparicio Jr. talks about AI, machine learning, and innovation in AEC.

About Matt Jezyk:

Matt Jezyk spent over two decades at Autodesk, contributing significantly to the development of Revit Architecture and Revit Structure. He also led the team responsible for Dynamo, a computational design tool widely adopted in the architecture, engineering, and construction (AEC) industry.

Matt was most recently at Tesla, where he developed software to streamline the design, fabrication, and construction processes for the company's Gigafactories.

Throughout his career, Matt has been instrumental in integrating computational and generative design with digital fabrication tools and robotics, presenting his work at conferences such as ACADIA, SmartGeometry, and Robots in Architecture.

Matt holds a Bachelor of Architecture from Carnegie Mellon University with Minor in Business, Concentration in Computer Science.

Connect with Evan

• LinkedIn
• YouTube
• Twitter/X

Episode Transcript:

181: ‘Densities of Information’, with Matt Jezyk

[00:00:00]

Evan Troxel: Welcome to the TRXL Podcast. I'm Evan Troxel. Today. I welcome Matt Jezyk to the show. You might recognize his name from my recent campfire episode. Ian Keough where he shared the story of Dynamo, an episode I highly recommend checking out. If you haven't already, you can find that link in the show notes.

Matt has been quietly shaping the tools and technologies that have transformed the AEC industry with over two decades of deep experience, and he is played a leading role in the early days of developing some of the most influential platforms in the space. Autodesk Revit. Dynamo and Project Refinery to name a few, pushing the boundaries of computational and generative design long before they became formidable tools.

He began his journey in architecture, but quickly moved to the software side as a product [00:01:00] manager at Charles River Software. Also known as Revit Technology Corporation, which was, as we all know, acquired by Autodesk early in the two thousands there, he served as a senior engineering manager and focused on creating next gen solutions for AEC workflows.

But he didn't stop there. Well, he did stop there for almost 17 years, but then he took his expertise to Tesla and Rivian where he helped build the systems, powering their smart factories, applying his knowledge of design, automation, and software at an entirely different scale.

Many lessons were learned as we'll hear about in this episode. Now as co-founder and VP of product at Motif, Matt is back in AEC bringing his journey full circle. He's working with a team that is building a new kind of platform for the architectural design process. In typical fashion for guests on this show, it's forward thinking, ambitious, and rooted in the belief that better tools [00:02:00] lead to better outcomes. Through every chapter of his career, Matt has championed automation, creativity, and cross-disciplinary collaboration. He has a knack for sensing where the industry is going and helping it get there. Faster. As usual, there's an extensive amount of additional information in the show notes to explore, so be sure to check those out.

They are, of course, in your podcast app if you're a paid member or if you're a free member, you can find them on TRXL. Co. By the way, Matt does some screen sharing during this episode showing motif. So check it out on YouTube if you're curious. And while you're there, hit the subscribe button to let me know that you're a fan of the show. On YouTube just search for TRXL podcast. That's TRXL podcast. Or find the link in the show notes page at TRXL. Co. All right, now without any further ado, I bring you my conversation with Matt [00:03:00] Jezyk.

​

Evan Troxel: Matt, great to have you on the podcast.

Welcome.

Matt Jezyk: Yeah. Thanks for having me. Appreciate it. I

Evan Troxel: it's been a long time coming. We've, we've been you know, passing in the hallways at Autodesk University over the years. Uh, been stalking you on LinkedIn for years, uh, and you've been probably listening to episodes of the podcast. And now here we finally are in the same place at the same time.

It's great.

Matt Jezyk: yep. Same thing. I've really, I've enjoyed listening to your podcast. I, I do have to admit that I, I, to them a little bit in like 1.25, 1.5 is a little fast, but 1.25 is like my preferred and, but that I really like the flow and how you're the, well, number one, the guest that you have, but also just the, the line of inquiry you go down is, is really nice to hear.

Evan Troxel: On my other podcast, just to put little context around, I, I totally get the speed thing. I listen to most podcasts at one, 1.25 or 1.5, but [00:04:00] I had another guest on my other show say, um, I go to sleep with you guys every

night.

Matt Jezyk: That's so funny.

Evan Troxel: And it's like, oh,

that's, I

don't do that. I don't listen to podcasts in bed, uh, because I just, I don't, I don't need any extra stimulation, but there are some voices out there that I could, I could see that happening depending on who you're listening to. And it, and then you wouldn't want to be listening at 1.25.

You would want to be listening at, you know, the, the low D of tones of the, the golden

microphone and the deep voice

Matt Jezyk: Exactly. Yeah.

Evan Troxel: Anyway, I thought that was hilarious, but great to have you, and I'm really excited to have a conversation about. Motif and, and what you've been up to and you've had this really interesting path leading to motif.

And motif is like this new thing, this, this, this new thing that's coming out. And, and, uh, we will definitely get to that point, but I would love it if you would just kind of tell your story about how you got from architecture to various places, maybe back [00:05:00] to architecture, um, but you've had this circuitous path over the last decade plus.

Tell

us about it.

Matt Jezyk: Great. Yeah. Uh, so my background, I went to school for architecture, for building architecture, and then. I was always into computers as well, so I ended up getting a concentration, sort of a minor in computer science and then business as well. Um, and that served me pretty well. So I practiced in Boston for a couple years and then ended up joining a startup that, um, had a really mysterious name called Charles River Software, um, back in the day.

And that turned into Revit. Uh, so there was a small startup of mostly computer science mathematician people that had built manufacturing cad, mechanical CAD tools. Um, one called, uh, pro engineer, and then they were doing the same thing in, in architecture.

Uh, so I was one of the first architects that was hired in that team.

And, uh, we worked together and built, um, this thing and then got acquired by [00:06:00] Autodesk and did a bunch of stuff after that. Um, so my life has been, um, building. Software for architects and engineers more so than building buildings myself. But the good thing about that is that you're able to work with people all around the world that are solving some of the hardest problems out there.

And, um, you get exposed to that and, uh, can collaborate with people, you know, like yourselves and, and others, um, that, uh, you know, a normal architect that might be working on one particular building might not, might not have had that experience. So, so yeah. Uh, so I've built Revit, built a bunch of other things like, uh, computational design tools like dynamo, generative design, simulation tools, structural analysis, energy analysis, um, fabrication tools, web cloud, all that kind of fun stuff.

And, um, and now we're doing it in Motif. Um, it's a new company. Uh, we started about two years ago and, um, some [00:07:00] industry veterans kind of came together. Um, but interestingly, all of us that were the founding team. We, we came from Autodesk, but we all left and went into various manufacturing, uh, spaces for a while.

So I, I went into the electric vehicle manufacturing space for about five, six years, um, and learned deeply about like what manufacturing was all about at scale. So how do you not just build one of something, which is what we're really good at in architecture, but how do you build thousands or a hundred thousands or millions of something, uh, and get that efficiency.

Um, and then of course, like scaling. Um, the, one of the concepts we were working on there was the, the factory as a product. Like how do you make factories quickly and efficiently and scale them in order to make more and more of a, of particular products like vehicles or batteries. So, so kind of like learning how to, I.

Take the [00:08:00] best practices for manufacturing and apply them back into architecture as sort of the longer story arc that I'm interested in. Um, but for motif, like what we're trying to do is coming back from this other industry in manufacturing, how do we build a brand new platform that, uh, starts to advance how architectural practice works, how engineering practice works in the building industry, uh, in a, in a similar way to how manufacturing has changed over the last 10, 15 years.

Evan Troxel: Yeah, it's a, it's an interesting kind of path, like I was saying a minute ago, how you've gotten to where you are and actually. Kind of proactively going out of architecture to learn these things and then bring those back into architecture. And I'm just curious kind of what you have brought back from those learning experiences, but we've seen a lot of, you know, the, these kinds of factories for architecture. Do a lot of, you know, funding, venture capital funding. We've seen a [00:09:00] lot of them crumble under the weight of architecture and

manufacturing and just

kind of

Matt Jezyk: Yeah.

Evan Troxel: side

of all

that. And I'm curious, kind of your, before we, we get into the motif side of things, like can you share from, from your perspective that that is really bringing value to where you are now?

Like, what are the le the hard lessons, I mean, there's a ton of hard lessons in there, right?

Am am I wrong?

Matt Jezyk: No, I think the, the, the trail of, uh, sort of modular construction, panelized construction, prefab in general is littered with these sort of corpses of startups that have tried to do something over the last 20 years and all for the best intentions. Uh, I think the problems are not technological. A lot of them come down to the fractured value chain in architecture to begin with and, and different building typologies that have different like kind of cost constraints and sort of efficiencies and, and just the mass production aspect of it in general.

Um, you know, so it's like if you're gonna build, [00:10:00] like basically every building is like a beta if you think about it. Like there's only one of it, right? So.

Evan Troxel: Prototype. Yeah.

Matt Jezyk: It's a prototype. So like how do you gain the learnings that you do the first time you do that? How do you apply that again and again and again? Uh, and that's where you see, you know, things that are repetitive.

So hospitality, residential, retail, um, anything that has a site adapt aspect like a prototype store and then a site adapt. Like there's a learning and sort of efficiencies and, you know, you lock in, um, vendors and, and, uh, manufacturers to build things for you. WeWork would be a good example of that. I think that in their prime, they were knocking out an amazing amount of square footage just from like an interior fit out standpoint.

And they, at some point they had like about two and a half or three curtain wall, um, plants, like manufacturing plants locked in to say, just to generate the storefront that they use for their interior partitions. So that's a case that isn't. It's not really what you hear about [00:11:00] when you think about like, you know, uh, industrialized construction or things that are, have to do with prefab or modular.

Um, but that's the real thing. Like if you take a vertically integrated, uh, building typology, you take something like, like, you know, uh, like a WeWork kind of space or take, uh, like Hilton Hotels or Marriott or something like that, or you know, how many Starbucks are there, apple stores, if you can lock in the suppliers and the manufacturing process and the efficiencies that you get out of standard details and just kind of like roll them out, that's where it gets interesting.

Um, but sadly that, you know, if you think about it as an architectural critic, then that just leads to the, you know, bland verification and sort of, uh, urban sprawl of like the sameness everywhere. But I mean, that, that's kind of where the sweet spot is. I think right now. Interestingly, I don't think residential ever, I.

It took off. I mean, besides like the initial kind of like Levittown things back in the, you know, early fifties, um, you know, the, and, and you know, production home builders of [00:12:00] course too now, but

Evan Troxel: Yep.

Matt Jezyk: the things that you would think of as like high design, architecturally significant buildings that are residential that are able to be mass produced.

Um, I think that there's still a big opportunity there that hasn't been addressed. I mean, you mentioned some of the, the larger flame outs in the past. Um, you know, Katera would come to mind. There were, um, you know, heavily capitalized, amazing ideas. Um. Ran into issues around scale and production and efficiency, and also just building typology.

Like how do you focus on one particular type of a market? Like it could be like, I think they were trying to focus on mid, mid-rise residential in like the Southwest, like okay, like nail that market and don't try and do it in the Pacific Northwest. It's just different or the southeast and different, you know, like, uh, sort of densities of, of units and things like that.

That's, that's the problem is like, it's not a one size fits all. Um, and I think that's one of the siren songs that people hear about in manufacturing. They're [00:13:00] like, oh, I know how to make widgets, or I know how to make these, um, you know, sort of, uh, circuit boards at scale. And then I just gonna scale that up and make a building.

It doesn't really work that way. Uh, be, be for all the reasons that you, that you've mentioned before.

Evan Troxel: Yeah. It's interesting to think about how these companies have failed by trying to be too. Too much like they did. They're just trying to take on more than like, like your example of just focusing on this one thing. Do you think that that's really coming, like that pressure is coming from the funding mechanism of these startups where it's like you've gotta be this a hundred x return kind of a company for those, for those VCs and, and, because I don't know if that's, even if it's possible to achieve that by being so focused on these a market and a region and a delivery type, right?

It's like whatever those components that make up what this modular, prefab companies are doing, it's like, no, we can do it all. And I think that by [00:14:00] thinking we can do it all, gets really, really like, it just waters it down and makes it really difficult then to solve for all those different markets and all those different environments and. I mean, Lance Auto came on the show a long time ago and said, there's something like 30,000 different municipalities in the US and everyone's got a

different version of

code adoption, for

Matt Jezyk: Yeah,

Evan Troxel: Like

Matt Jezyk: exactly.

Evan Troxel: are wild in in the, the architectural practice. And so the construction industry.

So it's, it's really that as soon as people start to try to go wide, it's like, then you really notice it. That, that it kind of

tends to fall apart.

Matt Jezyk: Yep. Yeah, I think, I think that's true. I think the, the standard VC sort of mantra is, is like, you know, they're looking for the, the unicorns, the kind of 10 x or 20 Xers. So if, if you put in.

Evan Troxel: said a hundred, that's probably not the right number.

Matt Jezyk: I mean, yeah, hundreds are great. Yeah. But,

but like, I think, you know, I mean the, the, the, the fact of the matter is for VCs, it's like, you know, and you can look up the metrics.

It's like, say they put [00:15:00] money in 20 companies, they really just need one hit, and then the rest of them are not gonna do that. Great.

Evan Troxel: Yeah.

Matt Jezyk: but how big is that hit? And that's where the return, like, if you, if you take, you know, an iPhone app like that, the cost of goods for that is relatively low. And the, the sort of size of that market, the total addressable market, or Tam, can be very large.

Uh, and if you monetize that, you know, it's like just a money printing machine. That doesn't happen in, you're dealing with like real physical products and real big things that take time and permits and zoning and people, you know, it's just, it doesn't scale that way. So I think that's usually the kind of natural limit or constraint in some of these is you have a heavily regional, uh, you know, market.

You have a, a. Particular set of buildings or typologies that will work well and lend themselves to mass production. And then you have the sort of upside of like, who's gonna buy it, who's gonna use it? Uh, I think that there are solvable problems there, but I [00:16:00] don't think, um, traditional venture capital is really the best kind of fuel or funding mechanism for a lot of those right now.

I mean, there, there are some VCs that are not interested in the quick return, a kind of two to three to four or five year return. They're interested in a 10 year return. And I think at that scale and at that time horizon, I think it is possible. Uh, and also, I mean, there's other kind of, you know, I hate to say it, but like resiliency at a, at a.

A national level or at a government funding level is useful. Like if you think about how do you recover from a natural disaster, how do you, how do you build housing in the southeast after horrible, you know, hurricanes that happened or in LA recently after the fires like that, there could be kind of an instigation or a kick kickstarting from a funding mechanism at the state or municipal or even the federal level that could, um, give a signal to the market to say, Hey, we're [00:17:00] interested in, in doing something there.

Um, that's actually happening in other countries. Um, in Canada, in Vancouver, there's a really great kind of public, private, uh, thing that's happening with, uh, a company called intelligent,

um, intelligent factories. Intelligent cities. Yeah. Uh, so that's a really great model. And there's some other ones in Europe too that are amazing.

But in the US I think it's a little tricky, but I think that it is something that people will crack over time. But for right now, um, you know, as you mentioned, the, the. It seems like there's this siren song for high-end residential, uh, high design, high-end residential and, and factory built or kind of prefab modular.

Um, but I'm not sure if that's really where, uh, like someone's gonna win, I guess. And it's, it's probably gonna be more on the, um, I, and I think WeWork is like one of those examples that worked. I think, um, I hate to say it, but like, re retail is a good one. Um, you know,

they're,

you know, there's these old, [00:18:00] old, uh, examples of you could, you used to be able to buy an Irish bar in shipping containers.

Like you, you, they would literally design and build an Irish bar and you could put it in two shipping containers and ship it to like Malaysia and set up an Irish bar just 'cause it's in a kit, you know? So like,

why, you know, that's basically the same way that like Starbucks works or like Apple stores work.

It's like they're, they're not really all site built. There's a bunch of pre, pre-created components that. Show up on site and get positioned in the right way.

Evan Troxel: For the ones that go into like a

strip mall or or what, or, yeah.

Yeah.

Matt Jezyk: yeah.

Evan Troxel: type of a

project where it's an

existing framework and then they just need to set it up a box within a box kind of a

thing.

Matt Jezyk: Yeah.

exactly. So, but yeah, but I think, but I think that in, in that space, you, you can use technology to kind of tie back to this and software to identify the opportunities, uh, and, and look at, you know, zoning and look at other kind of infill, you know, uh, sort of site opportunities and, and what's possible.

And, you know, [00:19:00] obviously parametrically configure things and figure out cost and efficiency, that there's a couple startups that are doing interesting work there. Uh, and then the other side of it is just figuring out how to take a design and break it down into smaller pieces that can be fabricated. So I, it's a solvable technology problem, but that's not the constraint.

It's more on the, the market and the, the financials behind it.

Evan Troxel: Yeah. I mean, it's a, it's like I think about like the automotive industry, the EV industry that you are in, and kind of the repeatability of those and, and. You know, like for, for example, you look at some of these cars and like, they don't change the

model if they don't have

to, right?

Matt Jezyk: Mm-hmm.

Evan Troxel: especially in the

EV space because it's all about that

factory

Matt Jezyk: Mm-hmm.

Evan Troxel: about kind

of stretching that as long as possible. Um, and, and in architecture, I mean, you're talking about like really wild and volatile market conditions when it comes to pricing of commodity pieces, parts, right? That, that go into building all that [00:20:00] stuff. Uh, and you also have wild labor fluctuations. I mean, maybe the factories solve for that a little bit better than traditional, you know, on site kind of stuff where it's really difficult sometimes to get the right crew on the job at the right time, um, especially in certain locations over others where there may not be as many. People in that industry or, you know, um, businesses that could bid on a project. It just, and, and I think about kind of the time horizon that, that VCs are comfortable with, with that kind of return and how long these projects take to do. Obviously they're trying to compress those schedules in massive ways to, to make that you know, potential being there and, and, and doing a lot of work in a shorter amount of time. man, there's just, uh, this is a tough business to apply that kind of, of thinking to, and I, I, I find it interesting that you went to, you're on the software side of it, right? You're not in the physical side of it [00:21:00] because on the software side of it, if you can gain those efficiencies and make 'em really. Tricked out for different verticals operating in the architecture delivery space. I mean, talk, talk about that as we kinda lead into where you're at now and why you decided to kind of get out of

the, the EV industry and

Matt Jezyk: Mm-hmm.

Evan Troxel: what you've learned and

apply it

back to the a

EC industry.

Matt Jezyk: Definitely. I mean, so in the EV side we were, we were, it's actually kind of cool, it's like designing three different things at once. You design the product, like the vehicle I,

Evan Troxel: facility side, like to be totally clear about that. Right. You, you, you

talked about kind of these factories and, and

Matt Jezyk: mm-hmm.

Evan Troxel: places

you

weren't

designing cars I for,

Matt Jezyk: Uh, yeah. I wasn't designing the product, but I was designing the process like the, the, the robots and the assembly lines to make them, and then the building to house and feed the process to make the product. So there's kinda like three different design process, like. You know, there's the design of the, the car and then there's the design of like, how do you get all the parts [00:22:00] to the line to make the car in the right efficiency?

And how many robots do you use versus people and all that. And then there's the, now there's 16 different systems of like compressed air of nitrogen of, of gas and electricity that need to go to those lines and you make a building around that. So

yeah, we were connecting what are called the manufacturing engineers that were making the design ideas for the vehicle with the building engineers and, and, um.

Making sure that they were, those three different design processes were as efficient as possible. Because, you know, like everything else, if you, something changes and then you try and build them and it doesn't line up, then that's a cost overrun or a delay. Um, so yeah, so that was kind of cool. And then using that idea of a factory as a product, like building multiple of them, because they're basically the same, uh, is, is, uh, where you get the economies of scale.

Um, yeah, so I was doing that, but then I got super deep into the, the design of the factories and, and how to make that [00:23:00] efficient, how to tie it to generative design and optimization and those kinds of things. Um, so that was kind of cool. But yeah. But back on. Uh, leaving that space. So we, I stood up things at, uh, uh, company Tesla, and then one at Rivian.

We worked on, on those kind of two different, um, companies. But then about a little more than two years ago, um, one of my old bosses, um, Amar, Hans Ball, we, he was the CO CEO at Autodesk called me up and said, Hey, I've got some ideas that I'd like to work with you on and let's see if we can spin up a new company.

Um, and that was the formation for what we're working on now, which is this thing called Motif. Um, and that was literally the case where he was at a company called Berate Machines, uh, with, uh, our CTO, uh, Brian Matthews and our Chief Design Officer, uh, Lira Koska. So they were all working on. Basically building what are called micro factories, like pre configurable, almost like Lego blocks that [00:24:00] make, um, make it easier to make products.

Um, they were doing that for a while instead of doing design. And then we all kind of came back together and literally got the band back together to start to address how can we build the next generation of design tools for architects and engineers. Um, so based on some of the learnings that we've had, but also just kinda looking at the industry from fresh eyes, like after being away from Autodesk for a while and not really thinking about like what the next version of Revit is or whatever.

It's just like you come back and you look at the problems and like, oh man, things haven't really advanced that much at all. So what are the opportunities now based on the technology available, how the generational shift is happening? Like, I don't wanna design for me, I'm a middle aged white guy. I. I want to design for people that are in college now that are in a design undergrad or graduate degree, because their view of the world is remarkably different than, than mine.

And, and that we're looking at these things from like a generational standpoint. [00:25:00] Like what's the 25 year return, like, things like AutoCAD and Revit and Rhino and SketchUp been around for a while. Uh, you know, uh, Revit is turning 25 years old this year, so not even old enough to drink, but like old enough to rent a car now.

It's like, that's, that's like a big thing. So how do we like. That like, and it, it's, and I, I, I can't even teach my, my, uh, my son these tools. 'cause they're, they're, they're gonna be like, this is broken. Like, this is not how I think, uh, you know, this kid, my, my son just speaking it that way is he grew up playing Minecraft and programming when he was like in seventh grade and Roblox and like the always on kind of instantaneous aspect of, you know, uh, connectivity with his friends and, and how they work together.

And then the tools that he's using professionally, like we talked about music, um, are all on the web. They are all

significantly connected together. Um, and, um, why do we not have tools like that for, for our industry that [00:26:00] are, uh, just how people expect to work these days. Uh, and we can get into that a little bit more.

Evan Troxel: So you've got this seasoned team and I, you said, but got the band back together in, in this term, this, this example might be debatable, but you know, you've, you have the new kids on the block, uh, but Motif just came outta stealth and yet you've been around the block quite a few times and the people on your team have as well.

And I'm really curious how you are looking at this product. the lens of the next generation, because that to me is kind of a fascinating thing. Like of course you could make a new version of the old thing, right? You could, you could trim off things and you could polish things and you could, you know, move the UI around and put it on the web and call it done.

Right? But I think there's probably more to it, and I would, I would love to kind of hear your, your take on how you're

going about doing that.

Matt Jezyk: Sure. so I think the key thing here, uh, that we're looking at is [00:27:00] desktop software. Silos of information. Proprietary file formats are, you know, how people are used to working today. But if you look at. Anything else that you've touched, you know, recently, like how you, how you pay your taxes, how you pay your bills, how you interact with your bank, where you get your music from.

All those things are not tied to your computer and your files anymore. They're usually on, on the web and in the cloud. So why is our professional practice and our, our design, uh, sort of standard still tied up in that? And that's where the industry's been going for a while. But, um, one of the things that we saw as we've been, as we've formed this new company and as we started working with, uh, a set of early adopter, we call them design partner, um, you know, sort of customers or, or sort of partners, if you think about it in the US and over at Europe, we started asking them questions like, what.

What do you guys see as the main challenges? Like, and, and a lot of this did come [00:28:00] from, you know, the, the open letters that were, were, um, you know, started a few years ago. There's a, a set of pretty bright, uh, individuals over in Europe that, um, really started to,

articulate. Yeah, they're, they're starting to, to articulate the real problems, like not just with a technology or a product or something like that, but just like, here's how the industry needs to work and here's how we wanna work in our practice and here's how we're looking for someone to help us in that journey.

Evan Troxel: Yeah.

Matt Jezyk: Um, so we saw that as a pretty good signal and obviously everybody's been working with these guys for a long time, but, uh, working with them and others, they were able to show us how practice is changing and one of the things that's happened. A little bit before the pandemic, but also accelerated dramatically during the pandemic was the adoption of these sort of, uh, infinite canvas whiteboarding tools.

Um, so, uh, people usually reference [00:29:00] a, a software called Figma, um, which is not really that well used and, and well understood in architecture, but it's very common in, in software design, user experience, you know, product design world. Um, and that is the equivalent would be like, take Adobe in design or, you know, illustrator and make it work on the web, make it, uh, work, um, in a way that you don't really have a bound sort of canvas, like that's why it's called in big canvas.

And, um, works at different levels of scale and detail and is inherently collaborative. Like, that's the key thing is that it's multi-user multiplayer from the start. It's easy to share ideas and bring people into projects like that set of phenomenon of like always on, always accessible and easy to share with others.

I think, um, sparked something in, in our industry where it's the opposite. It's like not always on, not always up to date, not easy to share versus these online tools. Uh, but fig, like I said, so Figma is [00:30:00] not really used that much, but you'll hear that from a lot of startups is like, it's like Figma for BIM or Figma for Revit.

Evan Troxel: Right.

Matt Jezyk: that plays well in the VC community because they understand it. It's a touchstone. But in the regular architecture community. The other infinite canvas tools that people are using are Miro or Mural or these kind of, um, applications that literally took the place of a physical whiteboard in a conference room that people would come together and pin up and get ideas together and do charettes and design critique kind of work.

They needed a way to do that, uh, you know, remote across time and space, but also forcing function when people were not in offices anymore. How do you practice architecture when you can't collaborate together in real time and, and in the same space? So there was a heavy pickup of these tools, and they're actually really easy to use.

You can get the principal level architect to be using it in the same way that, uh, a junior architect or, or someone else can, can use it. You can get [00:31:00] contractors, you can, you know, bring cross disciplinary work together. It's, it's sort of like lowest common denominator from like a, a. Uh, tool set. But also that is the beauty of it too.

You don't have to be a computational design person. You don't have to be the chief parametric person in your company to, to use one of these tools. So there's been a, it, it's really interesting phenomenon there. So how do you use that to inform the next level of design tools too? Uh, 'cause there are problems with this tool.

Like they're, they're two dimension, like, so architects and engineers work in 3D we solve three dimensional problems,

Evan Troxel: Hmm.

Matt Jezyk: but now you're dealing with an artifact of that, a screenshot. If you, if you will like, let me, let me send a screenshot from, from Rhino or Revit to put on this board and we could sketch on top of it and then remember what we were talking about later on.

Like, those kind of, that level of invisible work or sort of, um, uh, Phil Bernstein used to call it like a sawtooth diagram, like you're building up information and then it drops down because [00:32:00] you've exported or you've dumped it out to a different format about

Evan Troxel: of information right.

Matt Jezyk: Great. So like, how do.

Evan Troxel: lossy, right? This process that we go through, it's like somebody leaves a firm loss, right? Somebody loss somebody, you know? Yeah. You get to a certain milestone in the project and then you looks good. Start over kind of a thing. And it's like, so that's what that saw tooth.

It kind of, so if you, if you imagine if you haven't seen this diagram, it's like the profile of the Sydney Opera House, right? It's like, it's like up and then a, a steep drop and then up again, and another arc, and then another steep drop and it keeps going. And, and that's just kind of this linear, if you think about it, kind of linearly.

That's how data loss or, you know, decision making happens throughout the

life of a prog of a

project.

Matt Jezyk: Mm-hmm. Absolutely. So, so that's kind of where we're starting with Motif is what if we took the best things from these other applications and made them more purpose built for architects and engineers? Like these tools that are being used today are [00:33:00] great. You know, people are using them day in and day out.

But they're a little bit misappropriated because they are inherently two dimensions and they don't really have an understanding of, uh, how the building goes together or other concepts. They're just kind of like looking at a, literally a photocopy. Um, so,

so that was kind of the, the essence of the idea.

So what we're building is a new platform, and that will take time to do. Uh, you don't rebuild, you know, the primary design applications in this industry overnight. It takes, takes time. Um, but what we have is a platform that, uh, can grow to be that. And the, the first application or the first manifestation of this is focused on basically design, review, collaboration, markup, commenting, and is, uh, meant to be a complimentary tool with.

The primary design applications. Like if you spend your day in Rhino, like right now, there's not really a great way to collaborate across different [00:34:00] teams using Rhino. Uh, how do you do that today? How do you share that information or, or kind of link those things together and how do you do it with Revit or SketchUp or Grasshopper or Dynamo?

Like those kinds of things. People are using them. There's a heavy investment in those applications and that's not gonna change, uh, overnight. But what, how can we work on like the interstitial tissue that connects these things together and, and ultimately makes the design a team sport again, where you can share your ideas more effectively inside your company or outside with other people, or even with the client or with the public.

Um, you know, case in point, like, uh, they're, they're building a new high school where I, where I live, like in, uh, north of, uh, Penn, north of Philadelphia, south of New York. Um, and the state of the art is. I'm gonna show up with a physical model and a SketchUp model and a PowerPoint to a public meeting every month, uh, to talk about the design.

Uh, and there, you know, there, there's a good facilitation process and what if we did [00:35:00] this or that, or that, but it's not, uh, the artifacts are not really supporting that design process or the, the review or collaboration process with whoever the other person is. Whether it's the client or the, the general public or the structural engineer or anybody else.

They're just kind of someone sitting there taking notes and has to take them back to the office and give them to the drafter to, to pick up something. So how can we bring that into this century and make it digital, make it trackable, observable and visible to people that don't have, uh, you know, a professional background or software.

They could just log in and, and see the status of these things.

Evan Troxel: Yeah, I'm, I'm curious to hear. About how you're doing that. Because like you, you're talking about kind of these, these artifacts, right? That, that are created as like a snapshot in time, right? And that is how architects have worked forever, right? Like these phases of delivery. It's always that, right? It's like conceptual design, schematic design, design development, construction documents, right?[00:36:00]

And, and it's like at each one of those phases, and it used to be right, you would only get renderings at the end of DD kind of a thing. Um, again, that artifact and now like the expectations of clients have shifted a lot over the years with the advent of new technology, like real-time rendering for example, right?

Where it's just like, because what used to happen was they would say, where's my, can I get updated renderings? And it was like, no, you can't. Right?

Uh,

Matt Jezyk: Yeah.

Evan Troxel: now it's

like,

of course

renderings are free here. Here

Matt Jezyk: Mm-hmm.

Evan Troxel: And, And,

here's the

latest screen grabs right? Of the model that, that we can then. Send to you because they're good enough, right? They're, they're the real time with all the asset libraries and all of that stuff just makes it like, okay, yeah, I can, I don't, it doesn't have to go to the VIS department first anymore. A designer can just send those directly to a client. But there's still kind of like this artifact nature.

It's not real time in the, in that process of, and again, like our contracts are kind of set up that way, and our billing departments are [00:37:00] set up that way. And there's so many things that are still kind of holding onto or making it so that we, we need to hold onto these, these older ways of doing things.

But then you're also talking about the next generation of people who are gonna be using it, and what, what do they expect? do you mean? Like, that's not a live update. What do you mean? Like, I can't log in and see the latest, greatest and, and so having a place for the next generation or the, the currently adventurous, um, people in our, in our generations, right, who are willing to do that. it's a new way of, of working and it's a, it's a new workflow. Um, and it, it's, I'm curious to just kind of hear like what that is like for you as you roll these things out. Like you have these partner firms are probably legacy firms, right? Like they've been around a while, and of course they want to be modern and current and, and be differentiated in some way or do things better. And at [00:38:00] the same time, they're dealing with all of these other things that are kind of holding us to these legacy models, like delivery methods and the way that standard of care works in the practice of architecture and contracts and all of these things. So, I'm, I'm just curious, like how, what's that been like for you guys as you're developing a new platform, a new way of working with, within an industry that's been

around forever?

Matt Jezyk: Oh yeah, no, that's a good point. I think first off, we know that drawings are not gonna go away. You know, as much as you can look to the future and say, we're gonna build off of models. Sure. Like that's possible. But drawings are artifacts that are contractually mandated and, and represent those milestones that you mentioned.

So having a way to manage those is super important. But having them not be derivative, like having them be tied to the actual design or the work product itself and, and sort of. One thing, I think actually Revit got pretty right was the ability for a view to be live. Where if you [00:39:00] see something that's wrong on a planned view or a sheet, you could go in and just modify it right there.

You don't have to go back to the model and change it and then see the result on the drawing. So thinking about a drawing as the expression of your design intent and how you convey that information is actually super useful. But also having them be artifacts that can be pinned in time to say, Hey, this is what this background 80% set look like on Friday.

You know, that's a moment, that's a release, that's a deliverable. So that's super important. One thing that we have heard, um, interestingly, is that if you think about how that works now, is that people, you know are working in their primary design tool and then they generate a bunch of drawings and they usually, it's all PDFs right now, and you generate whatever, 400, 500 PDFs and

toss em over the wall.

Evan Troxel: my, my cohort on, you know, my, my co-host on my other pod podcast, he just delivered a set of drawings. It was over

2,500 sheets,

Matt Jezyk: Wow,

Evan Troxel: eight buildings.

Like not just one building. Right. But, uh, but [00:40:00]

Matt Jezyk: it's massive. Right? But like, how do you, like, how do you even add, if you were the project architect or kind of principal level person, how do you contribute effectively to that team, which, you know, whatever, you know, metric you have of like people to like produced sheets and whatever. But it's, you know, these teams can be somewhere between 10 to 30, 40 people.

Uh, and they're generating massive amounts of drawing. Like how do you review them? How do you, uh, mentor younger people? How do you even understand what your

professional liability is when on these drawings? you know.

Evan Troxel: mean, I

Matt Jezyk: you know.

Evan Troxel: you talk about like doing work in an office under the observation of an architect and is that architect truly doing that? Like that

is actually what

Matt Jezyk: Mm-hmm.

Evan Troxel: says that you're

to do. Right?

Matt Jezyk: Yeah.

Evan Troxel: it's, it's, it's,

an incredibly difficult thing in, in the, the paradigm of creating buildings today.

Right. the

Matt Jezyk: Mm-hmm.

Evan Troxel: and the CYA that goes on in these drawings and in these specifications and all of these different things. Because I [00:41:00] mean, and I was gonna bring this up earlier when you talk about like. There is no hub, right? There's so many ways to do the, there are hubs, right? But there's so many ways to share things and there are so many ways to collaborate and there are so many places to like stuff files.

And is it in the team? Is it in teams? Is it on the server? Is it in your email? Like, where is it? I don't know. Um, and, and so much so that companies have gotten to the point where they're just like, I don't care where you put it. Like, we

try to pull it all together

Matt Jezyk: Hmm.

Evan Troxel: we basically

declared bankruptcy and said, there's no way we can force people to put stuff in the right

place. It doesn't happen, right?

Matt Jezyk: Mm-hmm.

Evan Troxel: during the

pandemic,

it was like, where's the file? Who knows? Right? Um, it's somewhere. And if that person's offline, like you gotta wait till

they're back online to find it.

Matt Jezyk: Mm-hmm.

Evan Troxel: man, it's just, it's really complex at this stage. And so to your point about just keeping your eye on things and reviewing things and contributing in the role that you have as that senior level [00:42:00] person who is. Technically supposed to do that.

It's so hard. Right. It's

Matt Jezyk: Mm-hmm.

Evan Troxel: really difficult.

Matt Jezyk: Yep. So I think, so one of the things that we, we see as an opportunity is imagine, you know, you're running a mid-sized, you know, project, whatever the 400,000 square foot office fit out or something. You're going to a job meeting, you have to fly, you have to go somewhere. The state of the art now is send me those PDF files and I'll look at them in Bluebeam or you know, whatever other PDF markup tool of choice.

But what happens to, anything you contribute there or ideas that you have or you know, information you wanna share back to the team. It's sort of

Evan Troxel: Mm-hmm.

Matt Jezyk: one thing that even in our, so one thing that we've heard a lot is like the kind of pointy haired bosses, if you will, feel disassociated from the work.

And it, you, you know, like we're all kind of mid-career professionals. Like, you know, you might, you might have been very adept project architect, technical person in, in [00:43:00] these tools and working before, but now you're running around at meetings and,

Evan Troxel: Yeah,

Matt Jezyk: you know, dealing with budgets and you know contracts.

Evan Troxel: Yep.

Matt Jezyk: So, but how do you contribute?

You don't wanna give that person a Revit seat. You don't want them messing around with that model. You don't even want them,

you know, so like, what do you do?

Evan Troxel: the model. Right.

Matt Jezyk: So like, what, what if you, what if that person is sitting on the tarmac at LAX, like waiting to take off and have their iPad and was able to just log into this thing and see the design.

And it wasn't in Revit. It wasn't in Bluebeam, it was just in this new thing called Motif that super clean, easy to use, but always up to date. The linked, the models are all linked and shared so that you see the right 3D information and the right 2D information. And you can contribute, you can have a conversation, you can sketch on top of these things and have comments, um, that go back to the rest of the team as if you were there.

So as if you said, Hey, print out this thing for me. I wanna show you how we did this [00:44:00] detail five years ago. Uh, you know, that's the type of type of mentoring and sort of a professional practice that is very common, but it only works well when you're face to face. What if you could do that more remotely and still feel like you're contributing?

Uh, and that's, it's not a review process, it's a participation process. Participation process and contribution and mentoring opportunity that we think is missing in some of these current tools. And it also lets people. Kind of feel disassociated. Like, I don't even know what this team is doing right now. I hope that, I hope this is okay, but how do I review that?

I don't have time to go through that. How do I even know what to look at? Um, so those kinds of things are opportunities for a collaboration tool to bring people together in the same way that you would expect in any other tool these days. It's like, you know, you just show up. You're there physically, either at the same time in space or asynchronously leaving comments and marking things up.

But those are all tracked in sort of Google Doc style that, uh, you can, you can [00:45:00] observe, go back to see who changed, what, when, and how, and then, you know, respond to a deal with action.

Evan Troxel: You know, the sawtooth idea that you talked about with Phil's kind of chart that he showed and how, just to kind of put a diagram to it, a visual to it, to say, okay, oh, I get that. What you're talking about now, I think changes that, right? Like that's, that's definitely why, why we're talking about what we're talking about, right?

It's this idea of that data loss that the downward part of that chart, you know, minimized or going away. I don't, I don't know where, where you guys see that actually going if, but the, the idea of not having that data loss then to me opens up another potential problem, which is just accumulation over time, which is what designs are, right?

It goes from 30,000 feet down to the smallest detail, but it's also like the number of parts goes up, the number of decisions goes up. Like all of these things are going up, up, up, up, up. And, and so I'm wondering like, how does a [00:46:00] system like yours accommodate for that? Because I, I don't wanna wade through more and more stuff all the time, right?

I, I want to. I want to go in there and see what I need to see without having to jump those hurdles to get, okay, what are we talking about? Where do I find it? Because infinite canvas is not necessarily a good

thing, right?

Matt Jezyk: Exactly. Yeah.

Evan Troxel: right? This is what we're talking about. Um,

Matt Jezyk: Mm-hmm.

Evan Troxel: maybe you can

just kind of

talk to, to, that part of it.

Matt Jezyk: Uh, yeah, so, um, I think what we can do is just talk a little bit conceptually, do you mind if I just share screen

Evan Troxel: No,

Matt Jezyk: now? Like it's easy to show some graphics here. Um.

Evan Troxel: Okay. So for those of you, Matt's gonna share a screen. For those of you who are listening on the podcast, you might want to go over to YouTube. I'll have a link in the show notes to the YouTube version of this show, um, so that you can see what he's doing and, and we'll do our best to describe it. If, if you're not gonna do that.

Matt Jezyk: Yeah, so hopefully I can describe it. So, okay, this seems like it will work. Um, and I promise this is not gonna be super salesy [00:47:00] or anything, but thi this is basically the area we're working in. The, you know, where design happens is in these desktop tools where collaboration happens in, in these kind of new whiteboarding tools.

So what if you could do both? And that's kind of what Motif is. So it's meant to be a new platform to handle architectural design. And to your point, Evan, about like different densities of information and focus, like that's inherently built into this. Like the, the level of information that we have is very deep.

Like there's a lot of information, but you don't need to see it all at one time. There's ways to parse that information out and make it, uh, understandable and also consumable by different audiences. So we can talk about that. So yeah, so we, um, this is what we talked about a kind of 20 minutes ago, just the overall space that we're operating in. Um, and we're building a new platform that can handle different levels of information, but meant to encompass the overall architecture engineering sort of information density [00:48:00] problem.

Uh, and then combining 2D and 3D information together. But the way that we're actually doing that is by segmenting out projects into. Different boards. So if you, if you've ever used these other applications, they have, um, an interface kinda like this, where you have a project and then you have these discreet, uh, spaces to come work in and that there's just an in, it's called an infinite canvas board, um, that you can have one that's focused on.

This is where we're gonna do our brainstorming or bring material samples together, or this one is focused on 2D sheet review or 3D model review or exploring four different options for an entry entryway or something like that. So, however you want to organize your work is there, but the project contains all of your models, all of your ideas, all of your images, all your PDF files, really any information that you need.

Um, to execute the project. And that could [00:49:00] live either directly in Motif or it could be linked, it could be pulling that information in from other places. So we're, to your point before, like there's no single source of truth. Like there's no, everything is collaboration. So go where that information lives and pull it into this or provide a link, is basically our philosophy.

Um, so, but back on the idea of like, how do I even find the right things in an infant canvas, what we found just working with people is that they're, they organize their work in that way. Like, okay, this is our 80% check set board to, to take a look at something and then that is a container that people can work in and, you know, any of the comments or markups in there make sense in that, um, sort of for that activity.

Um, but there might be other ones too. So we're not pre uh, pre-design that for people. It's just kind of a general purpose tool. But all of your information is accessible, uh, over the, the. Really the, the history of the project.

Evan Troxel: [00:50:00] Yeah. And I, and I, I like what you're talking about when it comes to like, okay, the, the source of information is the authoring package that it was created in. Right? And it's brought into here, this is kind of an assembly of parts a conversation, for a collaboration, for a presentation, uh, depending on who the stakeholders are, right?

But this gives everybody a place to do that function of moving the project forward, making decisions

Matt Jezyk: Mm-hmm.

Evan Troxel: happen in

a group

setting or a collaborative setting, or in a presentation. To get that feedback from a client, let's say. like the Revit stuff's in Revit and the Rhino stuff's in Rhino, and those, those really advanced operators of those things are still doing their thing in

those packages, right?

Matt Jezyk: Exactly. And that, that's, this is directly coming from our conversations with our design partners where, you know, every, everyone wants a new. It's a great 3D design

platform

like that, that's [00:51:00] not, that's not,

that's not a secret in this industry, right? So like, yes. Um, but also there's like practical switching costs.

Like, okay, like, you know, how long will it take to build something that's equivalent to

whatever?

Evan Troxel: of a product. Yeah.

Matt Jezyk: And, and also, even if there was something today, like, I mean, I, I was around when we, we got people to use Revit instead of AutoCAD. Like that was a fairly fundamental switching cost of like 2D to 3D Parametrics, all that kind of stuff.

Evan Troxel: One way to say it. I mean, it was painful, right? It

Matt Jezyk: Mm-hmm.

Evan Troxel: get experienced operators from one to the other. Like how many times was like the, the flag goes up and it's like, uh, I surrender.

Export to AutoCAD now.

Matt Jezyk: Exactly. yeah.

Evan Troxel: How many times

did that happen? Many

Matt Jezyk: So we're not, we're not doing that right now. Like we are, we're trying to build. A new platform where you design where you want to design, you design in Revit, you design in Rhino, SketchUp, you know, AutoCAD, whatever, uh, you know, [00:52:00] grasshopper, dynamo, Figma,

you know, it's like, and you're linking that information in, in a dynamic way.

So it's not a static thing where I take a screenshot from Rhino, you're bringing in the Rhino file and you can make that right, you know, moment or view, uh, and show the right information in this system and bring it together and mash it up with other things. Uh, so that's kind of where we're going right now.

And you can operate in 2D or 3D. So you, you take that project architect person that might be really good at, at sketching ideas or detailing something out, how do you give them a space that they can draw in? Like right now they're actually drawing in scarily enough, like Bluebeam or, or even like, you know, in PowerPoint drawing details, like, why not?

Have something that's a little bit more architectural in nature that understands units and scale and, you know, materiality and things like that to express your design ideas in. Um, but still with a very elegant, simple user interface that doesn't require you to be [00:53:00] a cad jockey or a computational kind of nerd to, to do that work.

Um, so that's kind of what we're trying to build in this tool is it's not replacing the primary design applications currently. It's meant to be complimentary. It's meant to be a, a collaboration tool that takes the best of these kind of 2D infinite canvas tools and lets you do that work, but also lets you express your ideas in three dimensions and using that same simple tool set of sketching with a pen or a pencil or your finger, do that directly in 3D as well.

Uh, so that's, that's kind of the essence of what we're. We're building right now is something that's simple, easy to use, and works directly with the primary design tools, uh, in a way that we think matches the, where the industry is going, uh, around how people work in real time collaboration, expecting information to be there [00:54:00] consistently.

Um, we're showing on the screen right now, just our whole team collaborating directly on building a presentation. Um, and a, you know, a mood board or sort of precedent study, uh, directly. Like, why, why should it be someone is in the InDesign file and I'll let you know what I'm done? Or here's a new PDF file.

Like, here's the artifact, like right here. Let's all work on it together. Uh, and everybody contributes and participates and provides their best ideas at that point. Uh, and then of course you can be the, you know, the critic or the markup person and say, no, that's all wrong. Sketch on top of this and say, have you thought about this idea?

You don't need to be generating, you could actually just be advising or modifying or mentoring on top of that too. That's a very important part of all of this process. So, so that's what we're trying to support. Um, but not just in two dimensions. It's also in a, in a three dimensional space as well, so.

Evan Troxel: One of the things that you [00:55:00] showed me earlier in this 3D space that I thought was, know, just to really speak to this idea of how architects actually work is, you know, cutting a section. Using the section box in Revit and then seeing that in motif and then sketching over the top of it. But, you know, we've, we've done this forever, right?

It's like roll out the trace literally over the top of whatever that predetermined view was. But what was different was that the, the sketches that people, like, it's happening on the screen right now. That's

actually in 3D,

Matt Jezyk: Oops.

Evan Troxel: It's, like

linked

to the model and the view. And so you get kind of that like, like we talked earlier about somebody who has all this experience adding value to the process, being able to do that with a tool that they understand they don't have to go into Revit to do this.

And we're also not extracting and abstracting information away from the authoring tool. Like this is kind of a, a sweet little middleman kind of [00:56:00] effort here, where it's like I can draw right on top of the model with a tool. I understand, but it's literally linked to the the 3D elements, which then. go back to the, the person doing the authoring in that original, original program. They can actually see it and they can understand it because it's linked to and, and I can

actually rotate the view,

right? Like I don't

Matt Jezyk: Mm-hmm.

Evan Troxel: go back to

this snapshot, this two dimensional overlay. Like it would happen if you did it in Bluebeam or Miro or whatever, right?

It's

actually 3D.

Matt Jezyk: Exactly. So that, that's really the essence of this thing. I mean, drawing is a creative act. It's, it's meant to be expressive and un helps people understand your thought process. So why not have that work in the primary environment, like in, in your 3D environment and not just not a derive thing. Sketching on top of a PDF file is sort of a waste of time sometimes 'cause you're not able to convey the same information.

So we, we felt it was pretty strong, uh, requirement to get. [00:57:00] Sketching, working natively in the 3D scene. So as you rotate the model, or it just kind of knows where that sketch is, and having that be real time so you can express not just the artifact, but the process that you use to get to that point. Like, you know, drawing as a means to express your, your, your thoughts, um, and get them across to others is super important.

Um, so that's, that's, that's exactly how it works. Um, so currently you can mash up, like in this case we're seeing a Revit file and a Rhino file mashed up together. The Revit is the architecture and the structure, and the rhino is gonna be a great ceiling feature that's digitally fabricated. You can pull them all together.

So similar to how you can work in like Navisworks or, you know, uh, other, other collaboration tools. But ironically, it's not just about clash detection. It's about how do we design this thing? How do we connect these things together and figure out. How they're gonna work structurally or architecturally, uh, and use that to change the [00:58:00] original source, like the Rhino file or the Revit file to mediate or respond to, you know, that, that dance of like, if you move this thing, I'll move that.

Um, so this system in motif captures that collaboration in its purest form, the sketching, the commenting, the, the sort of negotiation of who's gonna do what, and then showing those real time changes. So as what we're seeing on the screen, I just change the Revit model to add some structural beam to hang this thing.

And then we change the rhino file to add some brackets and some hanging rods. Um, that's immediately there. That's not waiting for it to sink to the cloud, or I'll give that to you next Tuesday. It's just there. Collaboration should happen in that space.

Evan Troxel: Very cool. for those of you, again, who aren't watching, there is a visual component to the things that Matt and I are talking about happening in the YouTube version of this right now. If you're on YouTube, sorry, you get to hear me talk about it I'm not talking to you. Um, [00:59:00] but this is, the visual really helps kind of solidify what we're talking about.

A visual example is always beneficial, I think to, to me and this audience, uh, because we're visual, visually inclined, maybe more, more so than than others. But, um, I think it really does kind of help. And, and one of the things I, I loved was, was when, you know, somebody sketched in kind of a section, uh, profile onto this building and then we zoomed in and we rotated and that section stayed. 3D space where it was drawn. And I think it's really interesting that you said that the system just kind of knows where that's supposed to be. It, assume you're drawing this like on a tablet or something and it, and you're literally drawing it on top of a 3D view, and yet it, it lives in 3D space, which I think is pretty cool.

I mean that, that to me is something actually new

that I haven't seen before.

Matt Jezyk: Exactly, and it, that's exactly how it works. We're, we're working in a 3D scene. The geometry can be created directly in Motif, or it can be, [01:00:00] um, brought in from, you know, Revit or Rhino or other tools that, uh, if it comes in from those, it's updating live. If you change something, like you add a wall or move a window, it'll update.

But the information you're adding on top of motif is also geometry. So I can sketch that with a mouse. I can sketch it with my, I use a Surface book, uh, with a a, a pen. You could use your iPad with an Apple pencil or even your finger, like a lot of our displays are multi-touch, you know, capacitance screens.

Anyway, you can just start noodling around with just your finger. Um,

and, uh, and that's the idea. So you're capturing those and they're not precious. It's not, it's not a detail that's gonna be, you know, printed. It's just capturing the, the essence of an idea in a way that can be conveyed to other people, um, and, and facilitate the next level of conversation.

Evan Troxel: Yeah. That to me is really the benefit of a lot of these tools that we're seeing show up on the market. Like there's a lot of multiplayer stuff happening right [01:01:00] now in the browser because the browser kind of.

Agnostic is

Matt Jezyk: Mm-hmm.

Evan Troxel: word, but

Matt Jezyk: Yeah.

Evan Troxel: access, let's

Matt Jezyk: Mm-hmm.

Evan Troxel: to, to

this kind of stuff. And, uh, it does seem to me that this really is table stakes and, and, and as a designer from a previous era, if you want to call it that, right?

It doesn't seem like it was that long ago, but, but maybe it is. I got the idea of realtime collaboration potentially all the time is kind of terrifying, I

have to say. Right? It's

like I, to

Matt Jezyk: Hmm.

Evan Troxel: it, it

makes sense when it makes sense. And then a lot of the other time, like, I just want to be

left to my own devices.

Matt Jezyk: Mm-hmm.

Evan Troxel: This platform

pretty much sets you up for that. You could work either way, right? You could be working together all the time, but also because you're pulling in information from other sources and like real time linking that stuff together. Um, it still gives me the ability to go back to my authoring program for, for those parts of it and work on 'em [01:02:00] there. isol isolation for better or worse. Um, so that I have that control, that as a control enthusiast designer, right? Um, that, that, that's where I like to, you know, that's, I wanna make those decisions. I want to decide the proportions, I want to decide the materials I want to, that's, that's my role on the project. Um, that seems like you're kind of getting the best of both worlds. And I'm, I'm curious, like, what, what is the feedback you're getting on, on stuff like this? I mean, obviously you've, you've pursued this. I assume that that is maybe the feedback that you've gotten and that you're pursuing, like, because it makes sense to a lot of architects, but thinking about it from that through the lens of the next generation and expectations and all those things.

Like, just because that's the way I wanted to do it doesn't mean it's gonna be like that forever. So I'm, I'm just curious like what the feedback is that you've gotten that's really. you to this point. Is it like, there's tons of people who just say, I wanna work collaboratively way more often because I learn more, or, or whatever [01:03:00] those, those reasons are.

what, what have you heard?

Matt Jezyk: Absolutely. I think it's both. I think it's just human nature. It's not really the way architects or engineers work, it's just sometimes you're working on your own thing. You really gotta work out an idea. You have to work out some fundamental principle and you're not ready to share it yet. And that's supported in the system too.

So yeah, you can leave your things off in your own space and only share them when you're ready. Um, and then other times it's, it, it really is this, Hey, let's just get the, the four best minds together and just have at it and have a brainstorming session. But that, that is, you know, a balance. So sometimes you might need to go away for two days and just think about something and work it out.

And then you're ready to share it and present it. So absolutely. That's just human nature. It's just how people work and that's supported.

Evan Troxel: So do you see this as a paradigm shift? Do you see this as an evolution revolution? Like where is this on the scale of, of tools [01:04:00] for

architects?

Matt Jezyk: Yeah, I think, uh, where we are right now is meant to be a connective tissue. I think like we're building a new platform that will be the next platform, but right now what it is, is it's not on a day to day to day basis, you're using your main design tool and that's not gonna change. The thing that will supercharge is this thing can look over your shoulder and watch what you're doing and bring that into a shared environment that, uh, can help you do some of the things that might be difficult or hard or tedious right now, uh, a little bit more easily than before.

I. Um, but the thing that happens in startups, which was really interesting, is that it's not just about the first thing that you put out. It's about every other thing that you put out after that and how quickly you can put out more things. So because we're a small startup, it's all web and cloud. We can put out new versions of the software every month, say, for [01:05:00] example, and add more and more capabilities over time.

Uh, so that's, that's something that you'll see here too, is that this is gonna be a journey and it's gonna be a pretty, pretty fast journey. Uh, there's gonna be some pretty large changes, um, both on how we bring, uh, features out to the collaboration environment that we're talking about, but also how we go beyond that into other spaces like around the 3D modeling or parametrics or machine learning or ai.

Like all those things are facilitated by this platform that we have in place.

Evan Troxel: Can you talk about that from like a user's perspective and what you're hearing? Because to me, you know, adding features my explicit say, so yes, I'm

going to install the new

version.

Matt Jezyk: Mm-hmm.

Evan Troxel: brought it

up on this

podcast before. I remember a project manager was like, are you serious? There's another

new version of Revit.

And that was

every

year? That was only every

year.

Matt Jezyk: Mm-hmm.

Evan Troxel: it was

like, can we

just slow down a little bit? Because like, it's hard. Like, [01:06:00] and those were back in the days when it's like, you don't dare like, take your model from this version to the next version

because you don't know what it's gonna

break.

Right. So

Matt Jezyk: Yeah,

Evan Troxel: different. But

I'm just curious from, from your guys' point of view, obviously when you say it, it makes a lot of sense. Yep. I mean, it's cloud-based, we're releasing new features, the software's getting better and better. at the same time, you know, you've got people who are like, oh, you moved my button.

Right? Like, what did you do? Right.

Matt Jezyk: totally. Yeah. And I, I can, I can argue both sides of that too. Like, I mean, think about your phone, like, you know, we're, we're an Apple family, so we have all iPhones, you know, I have an, I have an Android phone as well just for testing, but the number of updates that happen is fairly, uh, frequent, like every, every.

Evan Troxel: definitely been some other things going on in the world that have kind of us up to

temperature for this type of

Matt Jezyk: Right. So, you know, it used to be that you'd have to wait to get a new, a new laptop to get the new version of Windows or the new version of Mac os. Now these things just kind of happen in [01:07:00] the background while you're sleeping, literally

on your phone or on your car, or on your laptop. So I think that the world's expectations is, are different now than they were maybe 10 years ago.

That said, when you're dealing with professional practice and deadlines and trying to control as much of your environment as possible, that could be disruptive. Absolutely. It's like, oh, like, I mean, it even happens now, like in Teams or Zoom or Slack or anything else, any other tool that you're using.

Those things work this way too. They'll, they'll just push a new, a new version out and you're like, wait, there's a new button here. All of a sudden. Sometimes that's good and sometimes it's not. Um, I think where it gets. Bad is when, when you have a, uh, a software development team or a design team that doesn't understand the primary workflows and use cases that their audience, um, are doing on a daily basis and what they're getting paid to do.

And if they start mucking around with those, uh, to, to the detriment [01:08:00] because there's a shiny new feature that they want to add, that's when you start to get user animosity and sort of frustration around this thing. So I think you can, it really does come back to a, a software design problem, like how do you add new capabilities without breaking the things that you have and without fundamentally changing the information architecture and like the layout.

Conceptual framework, object model of the system in a way that's disruptive and sort of breaks somebody's sort of patterns and paradigms. So I think you can do both, but you have to do it intentionally and make sure you listen to people's feedback. Uh, and that's actually another part of this whole thing is that we're, uh, because we, we have, uh, a lot of people that came from market engineering industry, we have a lot of connections in these partners.

There's a good level of feedback back to us. It's not just we throw it over the wall and we don't listen. It's like they tell us like right away, basically. It's like, Hey, uh, you know, you guys broke this thing and we'll fix it. So, but like often it's, it's, um, it could be [01:09:00] done more intentionally in, in a, in a thought, um, provoking way.

Like, I mean, just adding like AI ML tools is a great example. Like they're. Is a heavy emphasis on those, as you've seen in the marketplace now. And it's easy to sort of, we kind of see it in the same way that people kind of took sustainability to heart before and added features that might be green, but sometimes there's like sort of a greenification kind of problem.

Like it just because you added like an ecotech, like Sun Path diagram doesn't mean you have a sustainable practice. You know what I mean? So like

seeing the same thing from AI and ML standpoint right now, just because you're using like, you know, sort of hugging face or like some other like, you know, image generation tool doesn't mean that's gonna give you great results or you really understand what's happening or you're not violating, you know, uh, some copyright information.

You know, like the, like how do we apply these things intentionally and reasonably and as a, as an industry and then also as a [01:10:00] software provider, how do we provide things that are not gimmicky? They're not. Just to please the market or to make a new press release. They're impactful, they're designed intentionally to support or supplement or enhance a current process as opposed to make it different just because it's different.

Evan Troxel: I'm, I'm curious how you engage with

your audience. You, you

mentioned

Matt Jezyk: I.

Evan Troxel: but like,

okay, so a new app shows up on a new version of an app shows up on my phone and, know, we used to have to go through the process of like, okay, install the update where I could read the release notes and then that's gone, right?

Like nobody reads the release notes anymore. And I've seen a lot of companies now because of the speed of development, they don't take the time to. Create documentation about here's how to use these new tools, here's the new tools, here's how to use them, and here's a place to provide feedback for them because that's, that's another job to do.

Right? I get it. Um, so I, I'm just curious. Like, I've even seen software come out recently. It's [01:11:00] like there's no manual, you don't need it. Right. And, and that may or may not be the case. so I'm, because it's so easy to use, um, and, and again, like I, there's arguments for, there definitely is software like that.

Does it exist in AECI don't know. Um, but, but I'm curious how you guys are handling that, because is just gonna get more and more complicated over time. And if you don't have a system in that, and, and you may have a different take on this than I do, but I feel like if you don't have a system now. When it's easy, and I'm using air quotes, podcasting, air quotes, right, where you, you don't have a huge feature set. You're super focused. You're just trying to deliver kind of this baseline MVP kind of stuff, most valuable, like delivering value early. If you don't have that now, and I, maybe you do, um, but, but how do you do it later when

it's even harder, right?

Matt Jezyk: Mm-hmm. Yeah, that's a good point. I think, um, it's very topical because we're, we're about to launch the software and, um, [01:12:00] usually documentation is the last thing that happens in anything. But luckily it's the opposite for us because we've been working with a set of people for the last two years. There is documentation, and there's one of the things that we find useful is writing design documents internally with intentionality ourselves.

Like if you can't convey a concept to someone internally in writing and make that point cleanly and clearly, your, your user's not gonna understand it either. So we've written documents like since the beginning, um, that describe how the software should work. Um, the interesting thing now is that the. You know, what, what you, the, the, like any other design process, like your inputs go into this thing and then there's a bunch of things that happen and then what comes out the other end may not line up exactly with what your inputs were.

Evan Troxel: Mm.

Matt Jezyk: but the, the intent is the same where there is a concept, like a frame, like we're looking at these presentation boards right now that are, we call frames. So [01:13:00] there's a concept of a frame, like how should a frame work? Well, it should work like a slide in PowerPoint or like a sheet in Revit where it's sort of like a container that holds stuff like views and you know, text and lines and whatever.

So like that concept should be understandable and documented somewhere in a way that people can easily understand without reading a tome like a large manual. So how do we do that? It's just gonna be a lot of, um, online resources that are contextual and relevant where it's like, how do I do this? I want to do this thing.

And from an end user standpoint, they don't really care if that's from documentation or from a community kind of, uh, forum or sort of, uh, over, you know, sort of discourse discord type thing. Or if it's AI or if it's a help ticket. They just want an answer to their question,

Evan Troxel: Yeah.

Matt Jezyk: like, what is this thing? So that's very commonly what you see in software these days is a little thing in the corner that literally ask lets you ask that [01:14:00] question, like, how do I do this thing?

Uh, and

Evan Troxel: in the

corner are like totally invisible to a person like

me. I, I

Matt Jezyk: Hmm.

Evan Troxel: even, because I

wasn't

raised on this way

of doing

Matt Jezyk: Mm-hmm.

Evan Troxel: it's like

I learned a long time ago that the help

menu was not that.

Matt Jezyk: Mm-hmm. Yeah.

Evan Troxel: So I, I never even see those little things, that little bug in the

corner like you're talking about.

But, but I

Matt Jezyk: Yeah.

Evan Troxel: you're talking

about the next

generation, and you're talking about people who, who operate software that they're

used to, to doing that.

Matt Jezyk: But we, we do see different learning modalities is like the fancy word for it. Uh, and some people learn better reading things. Other people learn better by looking at a video,

Evan Troxel: Yeah.

Matt Jezyk: watching YouTube or listening to a podcast. Like, so those kinds of things I think we're, we are investing in. So, um, we're, and and the what the, another good thing that happens in software is you can see where people go, right?

So like, the equivalent in architecture would be if you're designing a campus, uh, for a [01:15:00] college, right? You, you have a set of buildings and you could design the quad, like the, the middle kind of, you know, grass area and put,

put paths down. But why not let people walk where they wanna walk and then pave them the next year?

So that's kind of how software works, is like, you can see where people go,

Evan Troxel: the

Matt Jezyk: like, not,

Evan Troxel: right?

Matt Jezyk: yeah, not like maliciously or like tracking or, you know, surveillance. It's just more like. You can look at that data and generate a heat map of like, where do people go? What questions do they ask? And then follow that with like, okay, this is clearly where they're going to ask that question.

We should support that. Um, so, and that, that really is that dialogue between like the software and Baker and then the, the end user. Um, and to your point, like change happens, like, you know, desktop software changes infrequently, but web software changes faster. But that doesn't have to be disruptive. It can actually be beneficial if you're listening and you're designing things intentionality with an in intentional purpose.[01:16:00]

Evan Troxel: I, I'm curious what you guys think about the, there's this idea that I've had for a long time, and I, I'm sure this, I, I actually know that this is not my, my idea, it's not even, it's not unique, but it's like things should have

expiration dates.

I think, uh, laws,

Matt Jezyk: Yeah.

Evan Troxel: like

there's a lot

of things out there.

Um. When it comes to tools and features and things like that, right? Like we all use software that's been around, you mentioned several titles that have been around forever and they can never get rid of anything because somebody relies on that. I'm curious what your, what your take is on that, because it seems to me like anything that really is going to be modern of has to think like that.

Like there, there actually are, and if you're a able to look at the data, right? If you're able to look and say, less than 1% does this

thing anymore and you guys are new.

Maybe this

Matt Jezyk: Mm-hmm.

Evan Troxel: you yet,

but,

but there's got there, it seems to me like there's some kind of expiration date on things at least it's like, hey, let's revisit that and look at that again.

Let's look at [01:17:00] the data now and see where this feature sits or you know, certain functionality or workflows or any of these things because it's like you in 20 years, if you're around then, right? Like you can see what happens. We all

can see what happens, right?

Matt Jezyk: Yeah, totally.

Um, I used to, yeah, like at, at Autodesk, like, um, I, I used to work with, uh, you know, guys like Ian Keo and Anthony Hawk and these, and, you know, a bunch of us kinda worked together and there was a point in time when I was not doing Revit anymore, I was doing dyna mode computational stuff and whatever.

But Anthony and I, Anthony was the product manager for Revit at that time. Or, um, and I got to say in customer meetings, it's probably my fault, but it's not my job to fix it anymore. Like there, there's some feature in Revit that didn't work or something like that, but those are very much those cases of like when you design something, there's like a literally a shelf life for it.

There might, it might have been a good idea at that time, but if it hasn't advanced in literally 15 years or [01:18:00] 20 years, something's wrong. Like there should be a, a reduc reductive process or a destructive process. If something's not used or it doesn't make sense, um, it should be taken out and recycled. It should be rebuilt.

Um, and. There's a concept in software called the, the Big Ball of Mud, which is about software accretion, both from a code base and sort of technology standpoint, but also from a user concept and feature standpoint. Like, why don't you take things away? Uh, sometimes it's, it's actually better for people to simply get rid of five things than to add to more.

Uh, so that, that's a very strong, um, concept that I don't think people actually embrace, um, and, and think reductively. So like a good designer actually knows what to take away, and I don't think that that's applied very well in the software industry, but it should be.

Evan Troxel: I think that's one of Dieter Ram's, like

10

Matt Jezyk: Yeah,

Evan Troxel: of good design.

Right.

Matt Jezyk: totally. Yeah,

Evan Troxel: you,

there's no extra.

[01:19:00] Right.

Matt Jezyk: Well, even back in the Renaissance days, like, you know, like Michelangelo, like, how did you know, what is David? Well, I took away everything that wasn't David, you know, so it's okay, like, not to say that, you know, like, but there's, there's a level of, of self-critique and, and honest feedback. And also just metrics, like the things we talked about before.

If something's not being used, why should you have that cognitive load of literally even seeing that button or having that, that code in the code base, like just get rid of it. Uh, and that's, that's hard to do sometimes.

So,

Evan Troxel: I mean, look at, I mean, AutoCAD,

Matt Jezyk: yeah.

Evan Troxel: uh, like

how it's been around literally like forever and, and there you try to take something away, and I guarantee you, because it's a horizontal piece of software that crosses so many industries, like, what are you talking about? I use that every, I use that thing every single day.

That tool, somebody will raise their hand, right? And say, yeah, I use that every single day. Because the user base is so big, it's been around for so long, and they just keep building and building and building and building, and then you get to the point where [01:20:00] you cannot take stuff away because you're gonna break somebody's. And, and I, I get it. Like, that's really hard to deal with. And at the same time, like it's totally keeping us to these. These older systems. And so as a, as a designer, as an architect, and kind of understanding that, yeah, like taking things away that don't serve us anymore like that, could serve us in so many ways in our lives.

And, and yet it's very hard to kind of step back and, and gain that perspective and understand why

that could be beneficial.

Well, this,

this has been a great conversation and I, I'm excited with what you're showing at, at such an early stage. This has been, uh, you know, a great conversation to kind of talk about what it's like to work in this profession and, and maybe for a next generation even more so, like I, I love that you guys are taking that perspective not just trying to replace what exists today, but kind of redefine it and, and build something that, will serve generations in a much more, [01:21:00] you know, useful way.

So I appreciate you

taking the time to share with us today.

Matt Jezyk: Absolutely. And I think that's really, that's how we think about the company too, is that number one, like we don't know all the answers. Like we have some ideas, but we need to collaborate with people, like thought leaders in the industry like yourself and others to, to find what's next. And we're kind of, we're trying to be humble about this stuff.

Like we, we know some things, but we don't know others. And we are trying to listen. Like that's the fundamental thing is when we work with, um, a lot of these early adopter partners that we have, it's not us saying, here's the beautiful thing that we wanna do. It's listening and observing and collaborating with people to find out what is next and literally going on that journey together.

So, so we've been doing that in, in a small forum recently, over the last couple years, but now it's time to go a little broader, so wanna bring more people into that journey with us. So appreciate, um, you know, having this conversation and I'm sure we'll have [01:22:00] more, more to talk about, um, in the future.

Evan Troxel: Well, we'll have links in the show notes for this episode, but if you want to just say where people can go right now if they're driving a car or whatever, and they, they, this episode just deletes as soon as it's over. It'd be

better if you could just say it out loud.

Matt Jezyk: Sure. Yeah. So, uh, I'm Matt Jezyk. I'm from a company called Motif, and our website is Motif, Tif Do io you can find it online and you'll be able to, um, access the software, find out more about what we're up to, and, uh, we'd love to to hear from you.

Evan Troxel: Fantastic. Matt. This

has been a great conversation.

Matt Jezyk: All right. Thanks a lot. See ya.

An Aspiration and Appetite to Innovate:

John discusses his journey with SHoP Architects, emphasizing the integration of technology and design in architecture. He shares insights into SHoP’s use of 3D modeling, digital twins, and collaborative processes to streamline construction, reduce costs, and deliver better-built environments. Highlights include the Barclays Center project, automation in construction, empathy in design, and the future of data-driven architecture.

Watch this episode on YouTube

Episode Links

• John Cerone on LinkedIn
• SHoP Architects website
• SHoP Architects on Instagram
• Confluence S1E5 - “Looking Forward with AI in AEC”, with Adam Chernick
• Upcoming Confluence Events
  • San Fransisco, CA - April 23, 2025 (open to everyone)
  • Lexington, KY - October 9-11, 2025 (by invitation)

Listen to this episode

About John Cerone

John is a principal at SHoP Architects, where he directs dedicated initiatives for model-based delivery and offsite manufacturing. He is internationally recognized as an innovator in the exploration of future technologies for design and construction, and his work in CAD/CAM integration and automation and Design for Manufacturing & Assembly processes has defined the success of many SHoP projects, including the Barclays Center, Nassau Coliseum, and the Botswana Innovation Hub.  John was instrumental in the creation and launch of Assembly OSM, applying automotive and aerospace manufacturing processes to transform capabilities in the practice of architecture, engineering and construction, and he leads both SHoP and Assembly OSM, in collaboration with Dassault Systèmes, in transdisciplinary groups that include key companies from the automotive, aerospace and marine industries. John received a Master of Architecture from Columbia University and a Bachelor of Architecture from Miami University.

Summary

In episode 179 of the TRXL podcast, I sat down with Matt Wash and Konrad Sobon to explore the evolving landscape of data analytics in AEC and how its reshaping digital practice. We discussed how firms can leverage data to improve workflows, enhance team efficiency, and address challenges like burnout, training, and digital transformation.

Matt, recently appointed as CEO of Bimbeats, shares his journey from being a client to leading the company, while Konrad reflects on how the tool has grown beyond model health tracking to become a comprehensive digital footprint for firms.

Although Matt and Konrad have appeared separately on the podcast before (links to their episodes below), this marks their first joint appearance. Their different industry perspectives created a well-balanced discussion.

Key Takeaways

In this special Campfire Series episode, Ian Keough joins the podcast to tell us the incredible origin story of Dynamo. He takes us on a journey through its evolution from a simple idea to becoming an essential tool in computational design.

In this conversation, Ian shares stories about Dynamo's development, including the challenges of transitioning from an independent project to becoming part of Autodesk, the technical hurdles they faced, and how the community played a crucial role in its success. We also discuss how Dynamo has transformed careers, created a new class of computational designers, and helped countless architects and designers learn programming. It's a story of innovation, perseverance, and the unexpected impact one tool can have on an entire industry.

Watch this Episode on YouTube:

Episode links:

Connect with the Guest

Ian Keough, widely recognized as the "father of Dynamo," is a leading figure in the AEC industry. Most recently he serves as the CEO and founder of Hypar, a platform designed to transform building design through computational methods.

• Ian Keough on LinkedIn
• Ian Keough on GitHub
• Hypar website
• Hypar on LinkedIn
• Ian Keough on the Getting Simple podcast

Books and Philosophies

• Hackers & Painters by Paul Graham
  • Amazon Link
  • Discusses how programming is a form of craftsmanship, aligning with the development of open-source tools like Dynamo.
• The Lean Startup by Eric Ries
  • Amazon Link
  • Explores iterative development and innovation, relevant to how Dynamo evolved in the AEC industry.

AEC Design Tools

• Dynamo for Revit
  • Official Website
  • Learn more about Dynamo, its history, and how it has transformed computational design in BIM workflows.
• Dynamo GitHub Repository
  • Dynamo Source Code
  • Explore the open-source repository of Dynamo and see its development over time.
• Dynamo Forum
  • Official Dynamo Community
  • Join discussions, ask questions, and explore shared Dynamo scripts.
• Hypar
  • Hypar Official Website
  • The next step in computational design automation, co-founded by Ian Keough.
• Digital Project
  • Wikipedia Link
  • CAD software based on CATIA V5 developed by Gehry Technologies, a company founded by the renowned architect Frank Gehry.
• Autodesk FormIt
  • Official Website
  • FormIt is an intuitive 3D sketching and modeling application designed for architects and designers to conceptualize and iterate building designs during the early stages of a project.
• AutoDesSys form•Z
  • Official Website
  • Tutorial videos Evan created in 2024 coinciding with the release of form•Z Pro v10.
  • form•Z is a comprehensive 3D modeling software renowned for its precision and versatility, catering to architects, designers, and digital artists.
• Microstation
  • Wikipedia Link
  • MicroStation is a comprehensive CAD software developed by Bentley Systems, tailored for infrastructure design and widely utilized in the architectural and engineering sectors.

Parametric & Visual Programming Tools

• ParaCloud GEM
  • ParaCloud GEM (5) Elements
  • ParaCloud GEM was an early generative design software application designed to populate mesh components over design models, facilitating the creation of intricate 3D structures.
• Grasshopper for Rhino
  • Grasshopper3D Website
  • A major influence on Dynamo’s development and a key tool in computational design.
• Food4Rhino
  • Food4Rhino Plugin Marketplace
  • A repository for Rhino and Grasshopper plugins, expanding their capabilities.
• Generative Components by Bentley
  • Generative Components Overview
  • A predecessor to Dynamo, used for parametric modeling in large-scale infrastructure projects.

Autodesk & Industry Insights

• Revit API Documentation
  • Revit Developer Center
  • Understand the API behind Revit and how it enables computational design workflows.
• Project Fractal
  • Autodesk Project Fractal
  • A research initiative exploring generative design with Dynamo.

Related TRXL Episodes

For more Campfire Series episodes and insights on computational design tools, open-source development in architecture, and innovative AEC technologies, check out these related episodes:

• TRXL 003: ‘A Local Maxima’, with Ian Keough
  • An early conversation on TRXL with Ian.
• TRXL 048: ‘How it Started; How it’s Going’, with Ian Keough and Clifton Harness
  • A discussion on the evolution of startups focusing on new tools in AEC.
• TRXL 175: ‘Realtime Decision Making’, with Ian Keough and Keith Fine
  • Exploring decision-making in design automation.
• TRXL 144: ‘The SketchUp Story’ with Brad Schell
  • The story of SketchUp, another influential AEC software.
• TRXL 176: ‘The Rhinoceros Story’, with Scott Davidson
  • A deep dive into the history of Rhinoceros3d.
• TRXL 095: ‘Super Janky’, with John Pierson
  • John is a Dynamo superuser.

About Ian Keough:

Ian's early work at Buro Happold identified a need for mobile applications to leverage BIM data. His software goBIM was acquired by Vela systems for their Vela Field product, which later became Autodesk's BIM 360 Field. His open-source visual programming language Dynamo has a worldwide community and now ships with Revit. He co-founded Hypar with Anthony Hauck in 2018 with a vision to deliver the worlds building expertise to everyone, instantly.

Connect with Evan

• LinkedIn
• YouTube
• Twitter/X

Episode Transcript:

180: Campfire Series - ‘The Dynamo Story’, with Ian Keough

[00:00:00] Welcome back to the TRXL Podcast. I'm Evan Troxel, and in this episode I have a really fun conversation with Ian Keough about the incredible origin story of Dynamo. If you weren't aware, Ian is the original creator of Dynamo. He's also widely known as the father of Dynamo, and today he takes us on a journey through its evolution from a simple idea to becoming an essential tool in computational design. What began as a project to bridge the gap between Revit and visual programming grew into something much bigger.

In this conversation, Ian shares stories about Dynamo's development, including the challenges of transitioning from an independent project to becoming part of Autodesk, the technical hurdles they faced, and how the community played a crucial role in its success. We also discuss how Dynamo has transformed careers, created a new class of computational designers and helped countless architects and designers learn [00:01:00] programming. It's a story of innovation, perseverance, and the unexpected impact one tool can have on an entire industry. I.

Before we jump in, I have a bit of housekeeping to cover regarding the current state of social media's, algorithmic feeds, and so-called followers on these platforms. For those of you not already subscribed to the TRXL podcast itself or to my email newsletter, I rely heavily on LinkedIn's platform and therefore their algorithm to share episodes and attract new listeners. It's still the best social media platform for me to post on and try to connect with people who haven't yet heard of the show.

But there's a startling fact about social media and a creator's ability to connect with an audience. It's being referred to right now in the media sphere as the death of the follower, because only one to 5% of people who have actually opted into quote unquote following me on social media platforms even see my posts. And the crazy thing is that the bigger the [00:02:00] company and the number of followers, the smaller engagement gets, the current average is 3.8%. So in other words, for every 1000 followers I have, only about 38 see my posts. So why is this? You see, social media is now being optimized for discovery, which means they're putting short form new content like shorts or reels, for example, in front of their users on their platform Instead of the content from creators they've explicitly followed. And of course, this is all being driven by the need for them to place ads into their feed, which is their main business model. The goal is to keep you scrolling and therefore seeing more ads.

So posts like mine that include a link off of their platform don't play well with their goals. So if you weren't aware of this. Now, you know, so why am I talking about this? Because I would love it if we could just skip the algorithm entirely. How? There's two ways. First, subscribe to TRXL wherever you watch or listen.

And second on my [00:03:00] website found at TRXL.Co so that we can directly connect over email. That's it. Let's get on with the episode at hand. I had a great time talking with Ian, and as usual, there's an extensive amount of additional information in the show notes, so be sure to check them out.

You can find them in your podcast app if you're a paid member , and if you're a free member, you can find them on the website, which is once again, TRXL.Co. All right, we have arrived. It's time to crack open your favorite beverage, find a comfortable seat around the campfire, and settle in and enjoy listening to Ian Keough tell the Dynamo story.

​

Evan Troxel: Welcome back, Ian. You were just on the podcast to talk about the latest and greatest stuff with Hypar, right? And are you calling, do you have an official name for that? Like this new version? I don't know what you could even

Ian Keough: um, we, we're,

we've been referring to it as version [00:04:00] 2. 0,

Evan Troxel: Okay.

Ian Keough: I suppose we need something. Internally, maybe this is too much inside baseball, but internally we call it Pringle, because the shape of Pringle chip is a Hyparbolic paraboloid. which is where Hypar comes from. but externally we just refer to it as Hypar 2. 0.

Evan Troxel: Sounds like a great prompt for some AI video thing where it's like, I want to see me opening a can of Pringles and the idea forms right there that that's what we're going to base our startup off of. This is Hyparbolic

Ian Keough: you eat

Evan Troxel: power

Ian Keough: can as one does with, in one sitting, with a

Evan Troxel: as.

Ian Keough: and you feel bad about yourself for the rest of the day.

Evan Troxel: As one does. Yes. All right. So you were recently on the show talking about Hypar 2. 0. And this today, I want to talk about the story of Dynamo because that came before Hypar. And this is really, I think, where, I mean, one of your first marks that you made in the universe of AEC software for sure.

Right.

Ian Keough: Yes, I think that's, I think that's probably safe to say. I'm [00:05:00] trying to think if there was anything before Dynamo that was like, of note. No, there was not. That was kind of like the first thing.

Evan Troxel: well, let's go back to the beginning. let's talk about where. this came from. I mean, and maybe you want to go even back, like right before it started, where were you and what were you working on that kind of led into that project?

Ian Keough: I might get this history a little bit wrong. I'm going to try to be very careful here. Um, I was working at Buro Happold Consulting Engineers in New York City. So I actually have a, I have a Master's in Architecture, but I, but I saw some presentations by Greg Otto about Buro Happold stuff, and I was like, I want to go work there.

And so I like knocked on his door. And went to work at, at Buro Happold, like right out of graduate school. Cause they were doing all this like crazy, cool, complicated buildings. And that'll actually, that's actually an important part of the Dynamo story because like Buro Happold didn't hire a lot of architects at the time. And when they hired [00:06:00] me, the way the story goes is that Craig Schwitter, who was in charge of the New York office, told Greg Otto, like, we don't hire architects. Why are you hiring this guy? And he's like, if you can't figure out what to do with this guy, you have to fire him. So, so Greg just loaded everything on me.

I was like, I was doing models in Rhino and renderings for people and like Adobe Illustrator, like layouts for project presentations. I was just kind of doing everything. one of the things that the that Buro Happold needed because it, it worked on these like super complicated projects was they needed a lot of help like getting data from one piece of software to another piece of software.

They'd have like an analysis software where they were doing, you know, crazy load, cases on these, these shell structures that they were building and there's, um, you know, complex geometry and stuff, and they would have to transfer that stuff after they did that analysis over to some other application, and then they need to take some geometry and transfer it to another application. So I actually started writing code, just kind of like teaching [00:07:00] myself to write code as a way of like, helping to do that. So, fast forward a few years, I'm like in Buro Happold, uh, in the New York office, And now the Revit API, man, I'm trying to remember how this works. The Revit API is like well established at this point.

We had started banging on the Revit API when it first came out. Like I was making Revit API stuff and sending it to this guy named Wei Chu, who was like the head of the implementation of the API at Autodesk the time, for these crazy Buro Happold like structures. And he was like, the Revit API is not built for this, like this is not going to work, and, so, I had this like good relationship with the people who were working on the API and they were always looking at stuff that we were doing because it was really, really pushing the, the, the frontier of what the sort of Revit API could do. And there was a very specific problem that kind of led to the geometry library or the [00:08:00] utility library that would go on to become Dynamo. And it was that, you know, people who model in Revit know that if you have, we did a lot of stuff with beams, right? was mostly seconded to the, to the structural team at Buro Happold. And so, um, everything they did was like beams in space, beams in space. And it was all about like these complex structures that were made up of these linear elements and like, um, and, and then some nominal geometry. which those things were based would change and you would have to like update the whole thing. And, and there's this problem in Revit that like nothing at the time worked like that. There wasn't an idea of like two linear elements that you connected them together and like when some underlying shape changed like those linear elements would just change together.

And so, um, the first thing I did was actually make this like point object. [00:09:00] I made a point object in this utility library. And it was like a little, it was like a little gumball, you know, like with the axes and everything else. And what you could do is you could like, know, associate linear elements in Dynamo by IDs something.

I can't remember exactly how it worked, with a point that they would, they would associate with. And then all you had to do was move the points in like a marionette. It would move all the attached beams and stuff. So then I wrote a whole suite of utilities around that were all just about like moving points in space.

We started to use this. We had this hilarious, like, I think it was called the Buro Happold Tool Set or something. We had this like, know, uh, people who remember like the ribbon, when the ribbon first came out and you made add ins in Revit and they would like drop down and then you could have drop downs on the drop downs and you could have drop downs on the drop downs. This thing, it was like, you know,

Evan Troxel: You could go deep

Ian Keough: level tools that like resulted in 400 like nested, it was crazy. And so.

Evan Troxel: and, and you are [00:10:00] very organized. Let's just say it that way. You, you, you wanna make sure that the things are in the right place,

Ian Keough: Yeah, it was like so bad that, you know, it's like those, those, uh, those, those things that are so nested that as they fly out, you're worried about, like, dragging your mouse off just a little bit, cause you'll

Evan Troxel: because you're gonna, you get to start over, right?

Ian Keough: So that was, like, the interface to use all of these tools, and we were

Evan Troxel: Mm.

Ian Keough: these projects, so, like, engineers would engineer a, they'd create a geometry, and they'd use these tools to transfer data to analysis tools and back and forth, and it was, it was kind of cool, but it was, But it was very clunky, and I think, think around this time, I remember, um, maybe, maybe Explicit History was becoming a thing, but certainly generative components had been a thing.

Evan Troxel: Right.

Ian Keough: and so, and actually the little gumball point that I made was very akin to like the points, I mean this is like [00:11:00] really dating me because anybody who watches this thing and remembers or listens to this thing and remembers generative components and the points and everything else, um, it was very akin to what points, how you did stuff in generative components, in generative components you wrote these scripts to like create these points and then you connected the points with these laced sort of things, so, so this whole utility library for the geometry side of things was very much like Like generative components.

Um, and I remember I went to, um, Smart maybe? The Smart Geometry Conference, speaking of generative components. think I went to the Smart Geometry Conference in New York City, and for some reason I think I was at Cooper Union. something. So it was at, I was at Cooper unit and I remember I had been communicating with the, the Revit API team, I had met this guy, Matt Jeek, uh, my friend Matt Jeek, who, who, uh, at the time was just like, he was hanging out in the [00:12:00] forums and stuff, and he was doing this cool stuff.

And I knew he was a guy who like worked at Autodesk. And I was like, oh yeah, he knows what he's doing. And, and he would go to these events. And I, I remember pulling him aside at one of these events and saying, Hey Matt, I want to show you this library. And the library was literally like, it was just like scripts for making these points and connecting things to them. And then like editing the points and having the connected stuff, like update everything else.

Evan Troxel: Inside of Revit. Right. And so obviously there's, is that the connection with Matt at that point?

Ian Keough: Yeah, so, so, yeah, because it was connected to the Revit API, but the, but the library itself was built in a way that it didn't have to be attached to Revit, it's just

Evan Troxel: Okay.

Ian Keough: where it, it, it did its thing. So, um, and, and I think even at that point I had started calling it the Dynamo library, or something, and I, I, I can't remember exactly, but, so I show this thing [00:13:00] to him, and then, Um, and then I moved to LA. My wife gets a job in LA, and I move out here, and Buro Happold had an office in Culver City, which is where I live now, and, um, Otto, who had started that office, and who had hired me into New York, said, Yeah, just, you know, come out.

So, I came out, and I sat with the, um, There was this mezzanine in our office, the first Buro Happold office in LA, which was here in Culver City, it's now downtown, but, was this kind of mezzanine where the computational design people sat. now at this point Buro Happold has like a lot of architects working for it across the global practice It has you know, there were probably ten people sitting up on this little mezzanine here Who were doing computational design stuff most of them with backgrounds in architecture Um, or non, non engineering backgrounds at least. And then across all the offices around the world, [00:14:00] they started to have a lot of like, architects. Because, you know, projects were getting more and more complicated. Every project that BuroHappled was working on was some complex geometry craziness. And architects ended up being really, really useful for, for working in that way. And, um, and so I had this little library, and I had the, I had the BuroHappled tool, tools, and I had this little other library, but we weren't really using the other little library yet, um, uh, Oh, there's one other. Yeah, right. Okay. I'm remembering now. Sorry. And I'm, I'm, I'm going to remember this stuff in real time. One project that I did right before I left for LA, there was a project we were doing with Moshe Safdie's office. Moshe Safdie was working on um, museum in Northwest Arkansas for the Walton family. And I can't, um,

Evan Troxel: Well I'll look it up for the show [00:15:00] notes. I'll look it up and I'll, I'll include it in the show notes.

Ian Keough: the name of the museum, but it had all of these, um, it had all of these timber roofs, these really cool like glue laminated beams that would span like 40, 50, 60 feet. on top of those glue laminated beams were these, um, were these like adaptable plates and the adaptable plates each had like metal tie rods coming into them, making this kind of diaphragm of a diagrid of these metal tie rods. And so you can imagine you've got these like swoopy sort of timbers.

You've got little plates on top of them that are sticking off normal to the swoopy timbers. And then you've got tie rods coming in. on a set of diagram pattern as this swoop thing. So those adjustable plates like have all these angles and they have to like move around and stuff. And that was like the first application of that library that I had built.

So what I did was I embedded, you know, instances of these points inside of family that represented the kind of tie plate. then I associated all the strut connectors [00:16:00] with the points on this tie plate. So you could literally like update the underlying geometry of the whole roof and all of these, like, The glue lamps would update, the tie plates would update, the struts would move, and everything would stay connected.

And you wouldn't have to change any of your drawings, you wouldn't have to like, you know, Cause they were, at that point, they were tweaking the

Evan Troxel: Of course.

Ian Keough: of this

Evan Troxel: Yeah. Mm-hmm

Ian Keough: the time, you know?

Evan Troxel: Parametric.

Ian Keough: at that and be like, oh, that's kind of cool. It's like, it's actually like, it's actually like, um, it's parametric.

Evan Troxel: Yeah.

Ian Keough: and, right, like fully parametric. It's not just like

Evan Troxel: Right.

Ian Keough: parametric. And, and we had done that. Um, one of the reasons we had done that was because they also wanted to evaluate using, digital components, digital components, the Gary product,

Evan Troxel: Digital project.

Ian Keough: digital

Evan Troxel: Right.

Ian Keough: They wanted to use, I was also like a Katia guy and I was like, well, we could do it in digital [00:17:00] project, but I have this little software library over here that basically if we use that We could do this without all of the like 20, 000 add ons to like digital project to make it work. And it ended up working. That's the craziest thing. I basically told them, I was like, I think we just turned like your 5, 000 Revit or whatever it costs at the time, your 3, 000 Revit into a 20, 000 piece of software with this like one little software library, know, that gave it this kind of adaptability.

Again, before adaptive components, before any of this stuff was like a thing. So.

Evan Troxel: I, I wanna, I wanna break in right here because I, I wanna get back to the, the conversation you had with Matt, too. I, like, we'll pick up there, but, like, where did that name come from? You said you, you think you were calling it the Dynamo Library at that point, so where did that name, where'd that come from?

Ian Keough: I, I literally plucked it out of thin air. I was like, it's dynamic. Dynamo.

Evan Troxel: It's a superhero.

Ian Keough: like a little [00:18:00] engine.

Evan Troxel: Right?

Ian Keough: a magician. And there's a funny story about how I sat behind him on a plane one time. But, um, that's, that was it. It was, and I looked around, I was like, are there other software? I mean, also, remember, this is 2010? I mean, I think I was still, like, I was working on this software library, like, 2002. 2008, 2009, something like that. I can't remember. So this is before there's like a zillion startups out there. I mean, sure, I'm sure the name Dynamo is now like, you know, some startup has already like raised a hundred million dollars, called itself Dynamo and flamed out, you know, but like

Evan Troxel: Right.

Ian Keough: the time, you know, there was nothing else out there. So

Evan Troxel: So, so where did you get this proclivity to code yourself, to do things yourself, to make your own tools

Ian Keough: that was like, that was literally like that from the top down at that like, if he couldn't keep me busy. he'd [00:19:00] have to fire me. So, I had, I had written a little bit of, at the previous firm that I had worked for way back in the days, um, through graduate school, I worked at this firm called ESI Design, which is an exhibit design company, um, uh, that's run by Ed Schlossberg, and it was super, super fun.

We did interactive museum exhibits and all this kind of crazy stuff. They were a Vectorworks shop, I had taught myself VectorScript, which is the built in scripting language inside Vectorworks, to help lay out stuff we were doing there. But it was, you know, kind of scripty of stuff. And then through, through graduate school, I dabbled a little bit in Mel script on Maya,

Evan Troxel: Maya? Yeah.

Ian Keough: but I didn't really start programming until Buro Happold.

Um, and the, and the joke I always tell there is, Like I tell kids who are like learning how to program today, you have no idea how well you have it. Like

Evan Troxel: Right. Light years.

Ian Keough: endless hours of YouTube videos

Evan Troxel: [00:20:00] Right.

Ian Keough: coding tutorials. And now like AI is writing code for you. in the day, there were books. Like, you

Evan Troxel: And if you messed up one, yeah. And you would be there scouring it, looking for where you screwed up that one character. Right.

Ian Keough: now imagine on top of that, you, not only do you have these books, you gotta read, like, learn how to write code from a book. So I would like, go down to the Barnes and Noble below Buro Happold and sit in the aisles. I never bought the books, that was too cheap. I would just like, read the coding books,

Evan Troxel: Right.

Ian Keough: And then, um, uh, and then on top of that, when the Revit API first came out, there was no way to, like, interactively debug. Anything you were making. So like you would have to, you would have to throw up message boxes. Like you'd say, you'd throw up a message box that says I got here in the code or the

Evan Troxel: So you knew, so you knew where to look.

Ian Keough: so

Evan Troxel: Yeah.

Ian Keough: to look, you knew what the values were. or if there was like, I certainly didn't know how to do it cause I wasn't a sophisticated programmer in any way. So [00:21:00] yeah, to your question though, is really just about, I had to keep myself busy. So I kind of like went looking around. For things to, know, that were valuable to people that needed to be done with code.

And also because the engineers couldn't do it. The engineers were like super, super smart, but none of them like knew how to do any scripting, or

Evan Troxel: Sure.

Ian Keough: or anything else. So, um, and all the tools that they were using had APIs. we were using Robot for structural analysis, and it had an API way back in the day.

Like a beautiful API, you could do anything with that

Evan Troxel: Wow.

Ian Keough: And the, and the engineers didn't really know how to use it. You know? Let's take a break from the conversation to tell you about Arcol, who is helping make this episode possible.

Evan Troxel: Architects should demand more out of their design tools. Imagine working on a project where architects, owners and contractors are truly in sync. No miscommunication, no back and forth chaos, just seamless collaboration. That's what Arcol makes possible. Arcol [00:22:00] believes teams shouldn't have to waste time switching between apps and navigating endless email threads. Your tools should work for you, not the other way around.

With Arcol, you can validate ideas as you iterate your designs while keeping all your documents and people aligned. No more silos. No more guesswork. Just better results.

Ready to upgrade your team's design workflow? Learn more at arcol.io/TRXL That's ARCOL.IO/TRXL

My thanks to Arcol for supporting this episode of the podcast And now, let's get back to the conversation

about some of the other platforms that were out there. You mentioned generative components, obviously Rhino was around, there was RhinoScript, obviously there was AutoCAD for 2D stuff and some 3D, right? And they had their own programming language, like Lisp or whatever it was called, AutoLisp. And then there was, I mean, I remember applications like Gem.

Do you remember that [00:23:00] one? That was like a three dimensional, um, you know, it was kind of this idea of having parametric, you know, you would have voxels and those voxels would basically get filled, stretched,

Ian Keough: was based on AutoCAD?

Evan Troxel: I don't know what it was based,

Ian Keough: AutoCAD, on Excel? There was one that you like, filled in tables in Excel, and it would generate geometry that was, but it could only do basically like, facades?

Evan Troxel: that, I thought that was probably it, and then, and then there was like panel tools inside of Rhino, even the, I think at that date, like 2009 ish, and so where did Grasshopper even come onto the scene at that point? Because,

Ian Keough: not on the scene yet. Like, like now, the, the, the, the new hotness is still like, generative components. are also kind of playing around with Maya, Melscript,

Evan Troxel: right.

Ian Keough: had come on the scene for Maya at the time, so people were still doing that. Some people were trying to automate 3D Studio Max and everything else, but that never really caught on. and so, so you were either scripting in Rhino, which had a pretty good scripting [00:24:00] interface, and it's Rhino script stuff. Or VBA, I think you could write stuff in VBA at the time.

Evan Troxel: I think it was based on, on that, yeah.

Ian Keough: generative components, or this was when digital project was a thing and Gary was like trying to get digital project to become a thing.

So the people right out of the bleeding edge were like to evaluate whether or not we were all going to be working in CATIA in the future. So like I taught a CATIA class, I co taught a CATIA class at Columbia for architects using power copies and these like crazy stuff that's been around forever on CATIA, but is, Extraordinarily expensive and no architect would ever buy and, um, also incredibly complicated to use, which is probably why digital project, you know, doesn't exist anymore. So that's kind of the, the landscape and also like, and Revit is, Revit is just starting to kind of find its traction, right? Revit came out, think Revit architecture came out in 2001. joinBuroeau Happold in [00:25:00] 2005 and literally like day one, Revit. On my chair was a boxed copy of Revit's structure. like, there's this new thing, it's called Revit, we're building this cricket stadium, and you're gonna build it in Revit, it's gonna be the first project that Buro Happold globally has ever done in this software called Revit.

And by the way, all the drawings have to look exactly like all the drawings have looked for 20 years.

Evan Troxel: Yeah, good luck.

Ian Keough: I was so screwed,

Evan Troxel: Yeah,

Ian Keough: Um, yeah, we had this like really, really ornery CAD guy, who's great, Simon. He was fantastic, incredible CAD guy. he was like just riding me about line weights, and like,

Evan Troxel: always.

Ian Keough: couldn't Revit to look like your drawings had always looked, and it was, it was a lot of all nighters.

Um

Evan Troxel: Remember just the transition, like he worked in AutoCAD and he had, you know, however many colors and he was reading drawings through color, right? And then Revit comes along [00:26:00] and it's black and white. And it was like, you had this graphical representation with line weights and stuff, but you're like, it's a different language for people who are operating.

And who are these technicians operating these things? Like you actually learned how to decode. the, the drawing through color because you didn't see the line weight on the screen. And now you could.

Ian Keough: so frustrated that you had to build a model of a building to get the drawing. They were just like, just move that line over. And I'm like, well that line is a slab edge. me to change the shape of the slab? They were like, whatever, just move it over so that the slab edge line on the drawings is in the right place.

Like, was probably, you know, there was a, Happold where we literally, we had a floor in New York. of drafters and the engineers would like do their work and sketch out, sketch out what they wanted. Then they'd carry it down to the drafters and that's how they'd operated forever and ever. And the drafters would do the thing and the drafters were incredibly skilled people.

But when the, when BIM came on the scene, [00:27:00] very few of them made the transition

Evan Troxel: Hmm.

Ian Keough: to, somebody from BuroHab could probably call me out on that, but it seemed to me like we had a lot of drafters and like a small percentage of them actually made the transition to BIM because you had to learn.

Evan Troxel: Start over.

Ian Keough: just didn't know how buildings went together,

Evan Troxel: It's not starting over, but it's a huge learning curve at that point with, with all that muscle memory that you have built into the platform that you've been using for a long time, right? Then, then to say, you have to actually think about this differently. Like you said, you build the model and you extract the drawings rather than building, just creating the drawings and moving something and then coordinating all the drawings that that affected.

Ian Keough: and you're, and you're reminding me when I say that Buro Happold had now at some point by the time I got to L. A. hired a lot of architects, one of the reasons they had hired a lot of architects was because young architects Who weren't so interested in going out and working in like proper design architecture firms and wanted to know more about how buildings go together up coming in droves to Buro Happold [00:28:00] and they were great at BIM. They were really hungry about the new tools They wanted to learn Revit. They wanted to learn how buildings went together. So they were really interested in building models of buildings and That was a benefit for all the engineering firms. They started to hire architects to help Make the models of their buildings. Um, so that was a kind of an interesting, an interesting dynamic. Yeah. I remember at one point in New York, you know, I was working, all the people who were doing BIM at that point, lot of them had architectural backgrounds. They were going to NJIT or other schools and coming out with like, you know, BIM proficiency was starting to become a thing. Um, so, uh, so, so that is to say, like the landscape was still very much like, It's funny, the landscape looked oddly similar to how it is today.

Evan Troxel: Mm hmm.

Ian Keough: had come out too, but like, that wasn't even in our domain. That was, I think SketchUp had come out, got really, sort of, widely used, [00:29:00] uh, got acquired by Google for a completely different purpose than like, Architectural concept and then got spun out of Google again to, and got eaten up by Trimble at some point. We just weren't even tracking SketchUp cause it kind of wasn't in our orbit, but I know it was, I know it was out there and it was contemporary with that stuff. Um, but yeah, landscape very similar to today, Revit, Rhino, you know? Um, so, uh, so, so we do that project, we do the Moshi D'Safi project with the, with the cool roofs and everything else.

We kind of prove that like with this, layer on top of Revit, could seriously upgrade Revit, know? Um, and I think that got a lot of people thinking like, whoa, we can like, and we started doing, then at that point, we started doing crazy projects in Revit. We, we did this, um, for Morphosis, which is the Cooper Union, the new building of the Cooper Union.

If you've ever been in New York City, there's a, there's a, a Morphosis project that has this, [00:30:00] Lightwell that kind of goes up through the entire center of the building.

Evan Troxel: It's a beautiful stare. Yeah.

Ian Keough: yeah, it's this, it's a stair that goes up a few stories, and then it's this, um, this like cage sculpture thing, structural sculpture thing that

Evan Troxel: Right.

Ian Keough: That was all done in Revit.

Evan Troxel: That's crazy.

Ian Keough: People go back and look at the models and stuff we did of that, and they're like, what? But it was because we had these, like, points in space with all this association stuff, and like, uh, that we were, that we were able to do that. And I presented at tons of conferences and stuff about, like, this bleeding edge kind of stuff we were doing in, in Revit at the time.

And that was about the time when, when I showed Matt kind of library of dynamic points and lines kind of tools. And that's, it really just did points lines, points lines. and transforms of stuff. And it had a little, it had a pretty high level API for, for doing that kind of stuff. Um, so yeah, so then I move out to L.

A. and um, we, I don't, you know, I [00:31:00] honestly don't know how long I was in, I think I started working in it, on it right away, because if you look, this is 2010, I moved to L. A. and some of the first tweets about Dynamo are from the very first house that I rented in Culver City. So I know for a fact that I was working on what is Dynamo now, 2010. Uh, um,

Evan Troxel: was around, right? So there's another,

Ian Keough: was around

Evan Troxel: I started on Twitter in 2006, I want to say. So it'd been around for a while at that point.

Ian Keough: right

Evan Troxel: I was there when it was transitioning off of cell phones, literally SMS for tweets to, you know, like the iPhone came out in 2007, right? So

Ian Keough: so I was like, I, I was, I had a blog for some time and I was writing little things in this blog, but then Twitter came out and I was like, oh cool, I can post like little updates here. if anybody, I'm, I'm not really [00:32:00] on Twitter anymore, but if anybody wants to, my history is still there. If you want to go back and look at the history, like very, very early on, you'll see, I think, you'll see screenshots of like very old posts.

Evan Troxel: nice.

Ian Keough: um, and, and at the time it, it was the orange nodes period, um, which, which people who have been around Dynamo for a long time know that the nodes were orange for a very long time. And this is, um, it must have been, um, Explicit History was definitely out at this point because I remember thinking like, oh, I want my nodes to look glassy and bubbly that guy David's nodes. So there

Evan Troxel: And explain what Explicit History is real quick, just for those who don't.

Ian Keough: is the precursor to Grasshopper. It was what Grasshopper was called, and I don't know, maybe you'll get David Rutten on this show one of these days, and he can tell you if this is true or not, but my recollection is that Explicit History was [00:33:00] what Grasshopper was called before it was called Grasshopper, know?

So when architects were first playing with this thing, and it was very, very kind of like beta,

Evan Troxel: It was a plug in. It was a plug in for Rhino at that point. It was not bundled. They were not one and the same company.

Ian Keough: yeah,

Evan Troxel: It was just David, right, as far as I know. It was just David creating that.

Ian Keough: have had a UI because I remember thinking like, Oh, I like the way that they do that. And, and, but I did all kinds of like other stuff too. Like I'd never built a UI, like a software UI before. So it is just like hilariously bad. You go back and look at those like orange nodes. At one point I surrounded each, I made the node, I made the ports on the nodes kind of stick halfway off the node. And so they had these like, I don't know, they, they, they looked like nipples. On the sides of the nodes. Um, and, and I was like, Oh, this is really cool. Then like tact, it felt like very tactile and, you know, kind of skeuomorphic. Like these were at one point I [00:34:00] made the texture behind them look like a, like an actual workbench and I

Evan Troxel: This was the days of skeuomorphic design, like, for sure, right? I mean, iPhones, 2007, like, remember the fine Corinthian leather in the calendar app? And there was all of those kinds of things.

Ian Keough: Thank you. Thank you for that recollection because that is like totally in my defense. It was of the moment. It

Evan Troxel: Right.

Ian Keough: me

Evan Troxel: It wasn't just you. We wanted rich textures on everything, on website backgrounds. Like, finding seamless textures was, was like

Ian Keough: Yes.

Evan Troxel: art. back then it was difficult. Yep.

Ian Keough: and I was using, um, I was using WPF, which is the Windows Presentation Framework. So this is going to like, I'm sorry, like people in your audience are going to be like, Oh my God, Windows Presentation Framework. WPF.

WPF is actually awesome. It's been around for a really long time, and, and, and now it's, it's pretty great.

I think they have versions of it you can do cross platform development, mobile devices, everything else. But at the time, it was kind of like their new, [00:35:00] Their new interface they had had this other interface that they made for the web, which was supposed to place this was also the time when everybody was getting rid of flash Plugins or flash Steve Jobs Steve Apple basically killed flash

Evan Troxel: Yep.

Ian Keough: saying like it's

Evan Troxel: Thoughts on Flash. Thoughts on Flash was the letter that he wrote. Yep.

Ian Keough: Exactly, right.

So like this is several years into that right before the first iPad comes out everybody's trying to like, throw Flash overboard, and Microsoft had built this thing called Silverlight, which was the precursor to WPF, and they were, was like, around for a couple years, and they were shutting that down, and WPF was like, the recommended way to build new UIs for Flash. stuff.

Evan Troxel: Hmm.

Ian Keough: And so, um, and so I was programming this thing in WPF and it, until a couple years into it, I had no idea how to do things correctly in WPF. If you were to go back, and by the [00:36:00] way, all of this code, I think, if, if you have any, like, codey people who listen to this thing, I'm sure you do. You can go to the GitHub repository for Dynamo right now and go back to day one, like the first commit. You can probably find, like, this original, terrible WPF code that I was

Evan Troxel: Nice.

Ian Keough: Um, like, 12 years ago, like, 2010, 2011, whenever that was. Um,

Evan Troxel: So did you start publishing there immediately when you started this project? Or was this something you went back and kind of like backfilled at some point for the GitHub repository? Yeah. Mm hmm.

Ian Keough: I can't remember, maybe like the first beginnings of, I don't remember when GitHub started, or when I started using it. I do remember, um, that at some point I started pushing stuff to GitHub. [00:37:00] And I had another kid right after I moved to LA, I had my son also got for another piece of technology that I had bought, got acquired by this startup out of Boston, which subsequently got acquired by Autodesk.

But that whole process of that getting acquired and me getting acquired with it, me going to work for that company out of Boston, and then me getting acquired by Autodesk was like a two year period, maybe where I didn't have a lot of time to work on Dynamo. And I open sourced it, and Matt Jezik, again, was one of the first people that I told, I was like, Matt, I'm, like, I don't have time to work on this with this acquisition happening and like everything else, so like, I, I'm gonna open source it, cause I thought, even back then, I thought, this thing needs to exist in the kind of public domain. Um, There was just this, this was, this point it [00:38:00] must have been that GitHub was kind of picking up steam and the idea of open source was picking up steam. And, and the thing that I had definitely seen inside Buro Happold was that were just doing stuff over and over and over again. And my, my joke about this is always the stadium bowl generator. Every firm that I ever worked with at Buro Apple did stadiums, and we've worked with a lot of them. I've probably worked on four or five World Cup soccer stadiums. Like every one of the firms that we worked with on that stuff had their own little script to generate, you know, stadium bowl layouts. And they'd be like, Hey, you want to see our special script for generating the bowl layouts? And I'm like, Oh, so lame. so I think at that time I just like started to think like, this should, is not. IP, right? Like this should just be out there as something that we all contribute to. we all sort of vet that.

Evan Troxel: Because you actually know what it takes to create one of those, and you see [00:39:00] it happening copy after copy, and they're all from scratch, right? And so you see the waste, literally,

Ian Keough: maintain, you know, um, it's worth noting that two or so years after I got acquired by this other company and left Buro Happold, um, I talked to somebody who was working in Buro Happold, literally sitting in my old chair. And I said, Oh yeah, you guys still using the Buro Happold tools? He's like, yeah. Uh, no. I mean, those things, like, I mean, the installer broke at some point, and then we couldn't figure out how to, like, you know, YEARS of work,

Evan Troxel: gone.

Ian Keough: into these tools. Just basically, like, Disappeared, you know, and it was because it's because software is hard. Like, like software is a, it's like a garden and if you've ever gardened and you leave your garden for the littlest amount of time and the weeds start popping up, it's pretty soon you've got this garden full of weeds and it just becomes like totally unmanageable.

You got to like burn it down and start over again. [00:40:00] Um, that is software. Like, like, so, so, if, if any of you out there are like, in the midst of writing a mean comment on a, on a GitHub repository to an open source repo maintainer, stop what you're doing and consider for a moment that that person is thanklessly, like, developing this thing, updating this thing, maintaining it, deploying it, making sure that it doesn't break, like, they're doing this on their nights and weekends because it's not their primary job. You know, there's a lot of like love that goes into these projects, um, and, and, um, it takes a lot. So like, these organizations are not constitutionally set up to like, build software, maintain software, deploy software.

Evan Troxel: No, they're working on projects. Yeah.

Ian Keough: They're working on a project, right? Um, so, so yeah, so I, I think at that very early time I had this thought like, okay, this stuff is just going to have to be, and it wasn't like I was making money from it or anything else.

There was no market at the time for Revit add ins or [00:41:00] anything. And I think people had started to play with it. Like, cause from day one, I had started to put, I think on my blog, I started to put like installers, or maybe not even installers. It was just like a zip file full of all the files. I was like, put these in a directory somewhere in your rabbit hole. And, um, and so people had access to the code and they were actually responding to me and emailing it. They're like, wow, this is really cool. And like, starting to like, the kinds of workflows and at the time it had a very limited set of things that it could do like I could do all the things that that little library could do before very simple geometry stuff because I didn't have a proper geometry kernel And then I think I started latching into more geometry functionality inside Revit So it was kind of Revit's Geometry Kernel in the same way that Explicit History was using Rhino's Geometry Kernel.

Evan Troxel: Mm hmm.

Ian Keough: Geometry Kernel still wasn't great. It wasn't doing crazy, NURBS y kind of stuff. It was still like, you know, [00:42:00] conics and, you know, but it was, it was good enough. Um, so, uh, and so, yeah, that's where it was at the time. It was like Orange Nodes on Twitter and everything else, and then I, and then I open sourced this thing and I tell Matt, and he's like, you know, that's actually pretty cool because we have this, Autodesk has this great summer internship program where they bring people in from the universities and stuff to work for the summer. had this guy, Stephen Elliott, from, I think Stephen went to Northeastern? and I think Stephen still works for Google. Um, but he, um, at the time he was a student and he came in and Matt said, We've got this guy Stephen, we're really interested in contributing to the Dynamo project. Um, could I have him take a look? And, Stephen starts in the summer, looks at the like, the mess of things that I had built, and

Evan Troxel: this is during the time when you basically were saying you had to pause from this because you were doing this other [00:43:00] two year long acquisition period. Okay.

Ian Keough: this was never my job. Like, this, doing this was like a nights and weekends kind of thing, and so now I have like, a, I have a year old, or a three year old and a baby. And a full time job at Buro Happold, which was in and of itself, like, pretty hard. And, um, and so they have this guy, Steven Elliott, start to contribute to this thing.

Now, this is where the time, I'm gonna get the times, like, all messed up, cause I can't remember the exact sequence. Before I left, I will say this much, um, about like how this started to land in Buro Happold on projects. Before I left Buro Happold, there was a project that we were working on with HOK. It was called the, uh, it was called ARTIC, A R T I C, the Anaheim Regional

Evan Troxel: Oh, I remember.

Ian Keough: Intermodal Center.

Evan Troxel: Well, I used to live in Southern California. I know exactly the building you're talking about. Yeah.

Ian Keough: the big E T F E

Evan Troxel: Right.

Ian Keough: and so Greg Otto, So, HOK's office [00:44:00] used to be right across the street from us. He literally marched over to HOK and stole the facade package from Thornton Tomassetti.

Evan Troxel: Wow.

Ian Keough: I'm gonna get like, I might get in trouble for saying this, but like I think Thornton Tomassetti, they weren't happy with Thornton Tomassetti's work for whatever reason. was like, we're right next, we're right across the street, we should absolutely have this project. It was ETFE, it was a complex room with this diagrid, sort of, steel tubular structure and these,

Evan Troxel: Yeah,

Ian Keough: and so, he was like, we should, this is 100 percent a Buro Hatfield project. So to his credit, he just like walked over there and like, gave us that scope of work.

Evan Troxel: we'll take that.

Ian Keough: yeah, and the building was like, um, was like a toroid that had been like, chopped at

Evan Troxel: Like shunted. Yes, at both ends. Right.

Ian Keough: and, and, and the roof is like this section of a, of a, of a toroid, and they were creating that shape in [00:45:00] Grasshopper, Explicit History, Grasshopper, whatever it was at the time, and constantly updating that shape and everything else. Well, the structural engineers had to respond to that by like laying out the entire diagrid structure. And then laying out these like ETFE capture channels that ran along the steel structure and making sure that all the capture channels were exactly normal to the surface to capture the ETFE cushions.

And then the shape of these inflated ETFE cushions, all super complex. And I was like, let's do it in Revit. of course, everybody's like a hundred percent. No, we can't do this in Revit. It's like. But, but they, the thing was, at the end of the day, they needed the building model to be in Revit because they wanted to use Revit to do the drawings and stuff.

So I was like, we can do it in Revit. And I come to, I come to learn after the fact, after we had, had finished this project, HOK had actually taken that project to Autodesk and said, we really want to deliver this in Revit. Here it is. This like [00:46:00] super complicated building with the ETFE roof and everything else. And, uh, can we do it in Revit? And Autodesk told them, no, they were like, don't, you're not going to be happy if you try and do this building. Um,

Evan Troxel: of them to say that, actually.

Ian Keough: yeah, I think, well, every once in a while they have like a very reasonable, like, take. And at the time, like, this kind of geometry, like, yeah, 100 percent Revit was not the right tool for the job. But that's, I've never let that stop me before. So,

Evan Troxel: Yeah,

Ian Keough: I, this was where Dynamo really kind of started, was trying to figure out how I could recreate some of the geometry that the architect was doing in Grasshopper. At least enough layout geometry. That I could then lay out the diagrid kind of structure. And then I could lay out the little things that stuck normal. And this is very much like the Moshe Safdie project. That's why I kind of looked at it and I squinted and I was like, that's like the Moshe Safdie project.

Evan Troxel: no problem.

Ian Keough: Vastly more complicated than the [00:47:00] web specific project. Um, but, but we ended up doing it, and it ended up working, and to Revit's credit too, like, the geometry APIs had gotten good enough at this point that you could do, like, you know, shapes, like, subtly twisting through space, and you could do all this kind of crazy stuff.

So, um, we, we did that project, and that was really, that was when Matt and I talked about, Oh, okay, I'm, I'm, I'm being acquired by this other thing, I gotta go open sources. So, Stephen Elliott gets involved on this project, and he, um, he builds a library, so he builds a library of nodes, I don't think I had a library of nodes, I don't know how you got nodes into the graph, like, oh, there was like a search thing, search was, yeah, so there was like a, you could only get libraries, nodes in the graph by searching, there was a little search bar, you had to know what they were called, but if you found them, you like, press enter, and it would, boop, drop it into your

Evan Troxel: If you found them right.

Ian Keough: There weren't that many, right? It's not like Dynamo now, it's like thousands of nodes.

Evan Troxel: But you're basically [00:48:00] saying the UI was a search field. I mean, it was like, Google

Ian Keough: Yeah, because that was like the thing at the time. We were like, oh, everything, the world's information is going to be indexed, and

Evan Troxel: Look where we've come back to like, like look at a, look at ai, right?

Ian Keough: Dynamo is just going to be a chat interface at

Evan Troxel: right?

Ian Keough: in the near future.

Let's take a quick break from the conversation to tell you about Avail. Is your team struggling to find the BIM assets they need? Avail's content management system simplifies access to all of your firm's content in one easy to use platform. No matter where your files live, or what type of files they are, you can easily search and access them from Avail.

Evan Troxel: Now, designers can consistently find and reuse all types of content. So what does that mean? Well, standards compliant models and drawings are easier to create. The documentation process is less chaotic, new hires are easier to onboard, projects are delivered faster with fewer errors. [00:49:00] You get the idea.

Visit getavail. com to try Avail for free and request a free demo. That's getavail. com, G E T A V A I L dot com. My thanks to Avail for supporting this episode of the TRXL podcast. And now let's get back to the conversation.

Ian Keough: so I think he built this library where you could drag and drop the nodes out and then, and then he proposed to completely rebuild the engine of Dynamo. It's not fair to say that the first version of Dynamo actually had an engine.

It was event based. It was, um, for the programmers out there, it would mean that, you know, you'd do something with this node, it would calculate something, and it would trigger an event. the downstream nodes would listen for that event, and they would take the data from that node, and they would propagate that, they would do their calculation based on that data, and send it downstream. The beautiful thing about the event based system is that it was incredibly simple. Like, you could reason about it just by looking at the code, and then you could debug it. You could debug through a graph by just saying, like, okay, it [00:50:00] does this. Where's that event received? Okay, it does this. You could check values and everything as a, as a programmer, figure out what was going on. So, so when they came to me and they were like, we want to replace the, the Dynamo engine with this variant of scheme that Steven is working on. I was too young to really think about the implications of this. I was really too young to think like, wow, it seems like it's going to be vastly more complicated. Then the thing that exists right now, but Steven was a really really smart guy And he was studying computer science, and I'd never studied computer science, and I was just like okay He must he must be smarter than me So he goes off and he writes this engine based on Scheme. We can put it in the show notes what Scheme is But it's a language and and also based on F sharp which was a new language that Microsoft had started building which was a Functional programming language, and so he called this the Scheme This thing that he had built, F [00:51:00] SCHEME, and, um, for a time, while we had this engine in Dynamo, You could actually print a Dynamo graph as a giant algebraic expression. Um, I won't go into it here, but like this gets into Lisp and everything else. And you could, you could literally like print, you know, if you had 500 nodes in your graph, imagine printing that as like an embedded algebraic expression. That's like a mile long. And that's kind of cool, because in a way, like, All the computation is like laid out right there for you.

And it's super uncool because it's 100 percent unintelligible,

Evan Troxel: Mm-hmm

Ian Keough: you know. Um, and so, at that moment in time, like, you know, now with hindsight, just got infinitely harder to interact with. Not like from a UI standpoint, but from a coding standpoint. So now we [00:52:00] had to write, you were always like, shoveling data into a form that the F scheme thing could process, and then you were popping that data back out of the F scheme form into a process that's like the of manage.

net thing could process, and it was, it was just super complicated, but it was kind of neat, and it still worked, it still worked really well, so like anybody who used Dynamo for the first couple of years, that Autodesk was contributing to it, was using it this version of the engine. Um, and uh, and then I think, you know, that kind of planted the seed, then people started to really use it, like, um, Autodesk was now contributing to this thing, and I will say, to their credit, Autodesk has allowed that project to maintain, to be open source long after I've been involved with it. Like from day one, the Dynamo project was open source. And now it obviously has closed source components in the form of its kernel and everything else. at the time, it [00:53:00] was dependent on Revit for its geometry kernel. So like it, was a very, very short window at the very beginning when it had its own geometry kernel.

It was with like points and lines. And then it became Revit's geometry kernel. So That enabled a new kind of conversation with users.

Evan Troxel: Hmm.

Ian Keough: literally there was a shift at that moment. There was a shift in how Autodesk talk to its customers. Prior to that, you know, if you've been using an Autodesk product for a really long time, and this is not the fault of Autodesk, this is like all software at the time, there was some forum

Evan Troxel: Right,

Ian Keough: you go and post a question

Evan Troxel: right.

Ian Keough: and, and maybe somebody from the company would like. respond to your forum post. And maybe it would get elevated to some place where it got into somebody's backlog and everything else. But Revit was like, developing really quickly. It had this sprawling multi year long backlog of stuff that they were going to work on. Chances of your thing you know, [00:54:00] getting

Evan Troxel: Noticed

Ian Keough: noticed

Evan Troxel: even noticed

Ian Keough: yeah, let

Evan Troxel: Mm-hmm

Ian Keough: up um, were very, very small. And it engendered this relationship between the software company and everybody else that was like, software company's going to do the thing that it does on its own schedule You can ask for stuff, but it was like throwing darts at the side of a battleship or something, you know? It's just like, everything's just gonna bounce off, and people felt, you know, frustrated by that.

Suddenly, there's this little project that rides on top of one of those big projects, going a mile a minute, and you can talk directly to the dev team. And you can like go to the open source repository and start putting issues in there and saying oh when I did this this broke and like a fix will be issued and a new installer will be built and it's like the next day that thing and I think some of this vibe was also happening with Grasshopper at the time you know it was like just fixing super [00:55:00] quickly evolving really quickly and that built that community it built people who are like wow I really want to be part of this like

Evan Troxel: Mm-hmm

Ian Keough: thing, engaging with this company in this new way. Um, so that, that was fantastic. And, um, just kind of feeling that and being at a moment when, and starting to see the first projects that people were doing with the thing. And I think at some point in here, adaptive components comes on the scene and that became like a force multiplier because, um, You know, Dynamo up until then there was like. There were families, which were kind of smart, but they couldn't really talk to each other. Like, they could do smart things internally, but they couldn't talk to each other. And that was about it. And thing that Dynamo solved really, really well was that it made families be able to talk to each other. the value of this family, when it [00:56:00] changes over here, could be piped into this other

Evan Troxel: Mm-hmm

Ian Keough: you could have these responsive kind of workflows. And you could even use, like, You could even use stuff in your Revit family, or in your Revit model, as inputs, because Dynamo could respond. Like, I could go change a parameter on this family over here, and if there was a Dynamo graph, like, piping values from that to some other place, when I change that parameter over here, just manually in the Revit interface, the thing would magically update over here.

So it was like action at a distance. Kind of thing. And, and, Adaptive Components took that to the next level, because now Adaptive Components were much smarter, you could embed much more smarts in them, they were much more flexible, so there's like a year of like, there's a year where every single Dynamo example that anybody made was basically like some crazy facade. Because that's what, Nate

Evan Troxel: Yep.

Ian Keough: a fantastic, it was like, the Revit splat, or it was the Dynamo splash screen at some point because it was this fantastic, like, stadium bowl roof [00:57:00] that he took the geometry and turned it into points and turned, made it an adaptive component for this, like, louver shade. And then made some Dynamo script that would not only lay those things out, but then change the value of the aperture, the size of the aperture based on. It's very of the time,

Evan Troxel: Right.

Ian Keough: know.

Evan Troxel: Totally.

Ian Keough: um, and so, um, so yeah, so Stephen, uh, builds this new version of the engine. And then they brought on this guy, full time, named Peter Boyer. Um, Peter Boyer is, um, He's probably one of the smartest people I've ever met. Super, super smart guy. And also, incredibly nice. He now works, he's one of the co founders of HighArk. So if you guys follow the startup scene, um, residential home building, the automation of residential home building,

Evan Troxel: Mm-hmm

Ian Keough: cool startup. And, um, Peter was the author of the package manager. So, [00:58:00] so Peter, um, uh, we were talking about this problem of people being able to sort of bottle up their Dynamo scripts and share them with one another. And Peter built, basically by himself, the first version of the Dynamo Package Manager. And, funny conversation around that was that, I think, I haven't been to Dynamo Packages in so long. But like, hey wait, actually, I'm gonna do this live,

Evan Troxel: Do it live, yeah.

Ian Keough: this Dynamo Packages, I think it's dynamopackages. If it's still there. Okay, right. So I remember it looks almost exactly like it did on day one when it came out. So that's either, that either means that nobody has wanted to work on this UI or that this UI just works incredibly well.

Evan Troxel: It was good enough, yeah.

Ian Keough: Package Manager shows you, like, how many people have installed something. Um, and it shows you the most active packages, and it shows you the most popular packages, and everything else. But there's that one number at the top that is the number of installs. And I remember Peter had made it, you know, it only [00:59:00] had like three digits or five digits or something.

And I was like, give it more digits. Give it more space. Because at some point, like, imagine when this is a million.

Evan Troxel: Right.

Ian Keough: looked at me like, right, like, a million Dynamo packages, like, or a million installs, like, when's that going to be? So right now it's 6. 9 million installs. And the way that I always talk about that number is, like, that means 6.

9 million instances, somebody chose to use something that was built by somebody else, than rebuild it themselves.

Evan Troxel: Nice.

Ian Keough: You know,

Evan Troxel: That's pretty, pretty, pretty cool.

Ian Keough: you know, I hope, I hope what that represents is like some time savings. I hope it represents people getting home to hang out with their families at 5 p. m. instead of 10 p. m. Um,

Evan Troxel: also represents this idea of like, making. Like, like the [01:00:00] craft of architecture and actually tinkering with things. You know, I kind of think of it like, You're in a workshop, except it's at a computer, right? And you're actually tinkering with stuff. And you're, you're, you're opening the hood and you're looking underneath and you're doing those things and, and you're learning by doing that.

And to me, like, how many, how many neurons have you fired off with 6. 9 million installs? It's just gotta be like a logarithmic compared to that number. Right.

Ian Keough: think that to your point, I think architects are fundamentally tool makers. Um, and there's a very rich history of that right up until we start doing everything in the computer.

Evan Troxel: Hmm. Mm

Ian Keough: Um, there's even a future right when we start using computers of like imagining what we were going to do vis a vis

Evan Troxel: hmm. Hmm. Mm

Ian Keough: of computation. And that future is still totally unrecognized. You know, like, like, we're, we're, [01:01:00] we're doing the most surface level kind of thing with these supercomputers that we have, which is basically use them as like a digital version of a drafting board.

Evan Troxel: hmm.

Ian Keough: There's a whole other, maybe our third conversation, Evan, which is like, why Hypar exists, which is to solve this problem, but it's like, like, we don't use computation to design buildings right now.

We use humans to design buildings, we use computation to just turn that stuff into bits. You know, so we can represent it ultimately as drawings.

Evan Troxel: Abstract it, right?

Ian Keough: Yeah, Let's take a short break from the conversation to invite you to join the most influential technology leaders in the AEC industry at Confluence. Composed of in person events and a podcast co hosted by yours truly, Confluence is designed to foster conversations between AEC firms and technology companies so they can learn, share, and engage with each other to support industry innovation.

Evan Troxel: Software company [01:02:00] Avail, which creates content management solutions for the AEC industry, started hosting Confluence events in 2019 to understand what firms are needing, wanting, and thinking around technology. To learn more about Confluence, explore upcoming events, and listen to podcast episodes, go to confluence.

getavail. com. My thanks to Confluence for supporting this episode of the TRXL podcast. And now, let's get back to the conversation.

It makes me think of Steve Jobs saying, you know, like the computer is a bicycle for the mind, right? Because that was all based on this idea of this graph where it talked about different animals and their speed, right? And man was like way down here in the corner and the cheetah was up into the right, right?

And then there was a human with a bicycle, which was like this outlier, you know, edge condition that just was like incredible. And so like the story that he put to that was the computer is the bicycle for the mind. Back to your point, like, what can you do with this tool, and, and what [01:03:00] is possible, it, it is absolutely incredible, the potential there.

Ian Keough: and he was imagining the force multiplier of like, you know, If you, if you go back to the time when he was giving that speech, he was thinking about, like, VisiCalc, you know,

Evan Troxel: Mm hmm. Right?

Ian Keough: my god, you know how long it takes to, like, can people even do these kind of computations?

Yes, they do them all by hand, or with a calculator, and this big, like, tables of stuff. Like, the force multiplier was 100x for the person who was doing that, maybe 1000x. don't think we've ever achieved that

Evan Troxel: Mm.

Ian Keough: tools.

Evan Troxel: Mm.

Ian Keough: You could argue that there's buildings that we can build now that we just simply didn't build before because we can represent them now. But in terms of the actual mechanical act of like producing a building, know that we've had a hundred X.

Evan Troxel: Right. I mean, you look at, there's like a meme out there, right? It's like a dude with a pencil and then like all this computation and digital everything technology and it's like Sagrada Familia and the, the transportation hub in Anaheim, right? Like whatever those two examples [01:04:00] are, but it's like, those aren't a hundred X.

It's not, it's not even 10 X.

Ian Keough: Yeah, um, and even for day to day buildings, right? The 99. 9 percent of all the buildings that we will ever inhabit, know, which are the sort of run of the mill, what Daniel Davis calls the fat middle of buildings, right? Like, why are we not just like generating those? Why are people still manually moving stuff around on the

Evan Troxel: Mm hmm. Mm hmm. Mm

Ian Keough: but like you can consider Dynamo was like a step on a trajectory that's pointing toward what we're eventually doing at Hypar.

hmm.

Evan Troxel: Mm hmm.

Ian Keough: a lot of that started with also this idea of like the package manager, and, and people being able to bottle up the code that they were working on, and, um, and, and share it. And, and I, at this point, I think we were also still just aping a lot of what was happening in the nascent sort of grasshopper community. It was now fully grasshopper. didn't have a package manager, but they had food for rhino or whatever it was called back in the day.

Evan Troxel: Still there. [01:05:00] Yeah.

Ian Keough: were like, people definitely have to be able to do this on Dynamo.

So, um, so that's, so, so then there's some period where I get acquired, the company that I'm at gets acquired into Autodesk. And that was Vela Systems, and Vela's product would go on to become BIM 360 Field. So I worked a full year and a half, probably, inside Autodesk on a totally different project. Like, not involving Dynamo at all. And, um, it was like, AU, two years into my time at Autodesk. I don't even know when that would have been. 2014? 2013? 2014? I don't know. Couple years into my time at Autodesk, this guy comes barreling towards me. And I'm actually, I'm still going to AU and I'm like sitting in the back of the classrooms as Matt Jezik and Zach Krohn present Dynamo.

Evan Troxel: Right.

Ian Keough: And those were the first classes that like suddenly, like so the first year they did it, [01:06:00] they had uh, I think one of the classes was called Energetic Supermodels with Dynamo. Or something this kind of like in cheek sort of thing. And I think Zach and Matt led that class and there was like one classroom full of dynamo stuff, like a smallish classroom.

And I sat in the very, very back and I was just like, oh man, this thing's gonna crash. It's like not ready for this. Matt

Evan Troxel: Live, live demos, really guys?

Ian Keough: Yeah. Matt had asked, he's like, can we lead a a thing at AU on this? And I happened to be going to AU because now was, I was, think I was in Autodesk at that point or like maybe I was going to, no, actually that first one I was still going to au for this other company for Vela Systems.

'cause we were pre, we were presenting Vela and I was working Velas

Evan Troxel: You were just going to catch up on what they had been working on, on Dynamo so you could actually see it.

Ian Keough: And, and yeah, and I'm like in the back of the room, just like, Oh my God, this is really bad. There's, there were maybe 30 people in the room and I'm thinking, you know, Oh my God. Um, [01:07:00] and, uh, so that was the first class. And then the second year, I remember. The second year they had, like, a line to get into the classroom, and I was like, why is there a line to get in have they not opened the door yet, or something?

But there was a line to get in the classroom to learn about this thing called Dynamo that people largely, like, still didn't know of. But there was, like, at least a classroom plus a little bit of overflow worth of people who, like, Had heard about this thing and were like, they were members of that community.

Evan Troxel: The early adopters, yeah, for sure.

Ian Keough: I'm like, I'm going to, I'm going to be the first person in my area who knows how to do this. And it's going to, it's going to increase my value to my firm. And I'm going to be part of this community. So that's when you kind of get the sense that it's like an exciting thing.

So at that AU, I think this guy comes barreling towards me and he's like, Starts talking a mile a minute about Dynamo and how incredible it's going to be and what we're going to do and we're going to build this and we're going to have a team and we're going to do this. And I [01:08:00] was like, the guy talks for like three minutes, like without taking a breath. And I'm like, I'm sorry,

Evan Troxel: You're like, who are you?

Ian Keough: And it turns out it's this guy Abhijit Oak. Abhijit, um, had been an AutoCAD guy inside Autodesk for a long time. Um, and then he was put in charge of the Dynamo team. I can't remember what the org structure of Autodesk looked like at the time. It was always changing, but like Abhijit was somehow put in charge of Dynamo.

And so he was like really excited about this, and he found me. And he comes charging at me, telling me all these things we're gonna do, and I'm like, Oh, okay, but you know I'm not on, like, the Dynamo team, right? I'm working on BIM 360 Field in the construction thing. he's like, Yeah, yeah, let's, you're gonna be on the Dynamo team.

Evan Troxel: Let's fix that.

Ian Keough: What is the Dynamo team? And he's like, Oh, we've got, like, we're gonna make a team. So, they, they make a team. They make a, like a, it's like, Peter Boyer, and maybe Steven Elliott was still there for a little while. And it's Zac [01:09:00] Krohn, um, is, is kind of coming over from the Revit team, and myself. And Matt Jezik was kind of peripheral to it, but like, he was kind of shepherding this thing along, but I don't think he was ever like a full time member of the, the, that team. And then, they started pulling in, this guy, like actual Revit developers, who had gotten fed up with developing Revit. They, they were like, hey, I want to go work on that Dynamo thing.

Cause like, Dynamo was now like the cool Revit at that point was kind of just like, it was

Evan Troxel: Yeah,

Ian Keough: going to be.

Evan Troxel: were looking for a reason to want to go to work the next day. Right.

Ian Keough: so, I mean, there's a whole other podcast about this guy, Lev Lipkin, who is incredible. Lev was like an original Revit developer, super, super smart guy. I mean, just a brilliant guy. He came over and, and, um, we were, we were dreaming up all kinds of crazy stuff. Like at one point. We were going to embed the Dynamo runtime inside families that families could [01:10:00] have their own onboard computational logic, know, and it was

Evan Troxel: Nice.

Ian Keough: Like imagine like now,

Evan Troxel: Right.

Ian Keough: logic, like you could put any kind of Dynamo logic inside a family. And then you could also, on top of that, use Dynamo to, like,

Evan Troxel: Right.

Ian Keough: those

Evan Troxel: Hmm. Mm

Ian Keough: crazy. So, we built this team around it, and, and, um, that, then it was really, then it was becoming, like, a corporate kind of thing. Now it was like, this is an Autodesk project. And, and, um, you know, I had to work, at some points I had to work make sure that they understood that it was still open source. there was still enough, open source was still unfamiliar enough that people inside Autodesk didn't like get the, get the idea that Autodesk was contributing to this open source project. In other words, like they didn't own it.

Evan Troxel: hmm.

Ian Keough: That was confusing to them. [01:11:00] So

Evan Troxel: It would be the Is that the only thing like that in Autodesk at that time, probably?

Ian Keough: probably, I don't, I don't know for sure, but it's certainly like, it was certainly the only one that I knew of,

Evan Troxel: Yeah.

Ian Keough: and so Matt was always like having to defend. The open source thing and talk about how like it was a different way of engaging with customers And that's why it was like going in this way And I think he also although he never said this to me But I think he also like was much more connected to the higher levels of Autodesk I think he also sold up the idea that like this thing was valuable to Revit It was there to sell more Revit.

Evan Troxel: Yeah.

Ian Keough: could help them sell more Revit, you know? that was really the thing that they were concerned about. They, they, Autodesk wants to sell you more Revit, and so having this thing that could be of a flywheel for that, even though it was like a small thing at the beginning,

Evan Troxel: of the funnel, ultimately, right? And you're talking about the [01:12:00] thing that people are excited about using to alongside Revit, or on top of Revit. I mean, that's You have to capitalize on that excitement, right?

Ian Keough: Yeah, and so that, and one, one unfortunate consequence of that is And I, and I say all this with a big asterisk because I'm, I'm, I have a very soft spot in my heart for Autodesk. I worked there for a number of years, I have a lot of great friends who, who work at Autodesk. Um, so, that's a big caveat to a lot of what I'm going to say. They, um, Autodesk sometimes has this mentality of like, We're gonna go into the market and make a product that feature for feature like competes and we're gonna win Because we own the channel or whatever, you know, you saw this with things like Formit Sketchup. They were like we're gonna kill Sketchup.

Let's make something that does all the things SketchUp does and they actually made a beautiful product and I know the team who worked on it was kind of brilliant in many ways [01:13:00] But like I don't know. It's a troubling thing to try and compete like that, know instead of like really Differentiating on some other Vector of value you just say like we're gonna do exactly the same thing that you do But because we do it, anybody who uses Teams Microsoft Teams understands what this feels like in a product.

Meh You

Evan Troxel: Premium, premium, mediocre. Yeah.

Ian Keough: know, but it's just like, meh. And, and so one of the things that they tried to do, I think, they're still trying to do it. It's like, they were looking at Grasshopper, and they were like, this has to be Grasshopper.

Evan Troxel: I was going to ask you, like, where did that excitement internally come from? Uh, it was it, was it, I mean, it, maybe it's a combination of things, right? But the excitement from the user base and the poten the raw potential of, of this layer sitting on top of Revit, and the way that it can now interact with, uh, Other packages or platforms.

Maybe they didn't care about that [01:14:00] at all. Like I know Autodesk really likes to focus on, on themselves and what you can build inside their tools. But then also there are these competing pressures in the industry, a la Grasshopper, right? And so I was just wondering if you had, I'm sure you have thoughts, but that's kind of where you're going.

Ian Keough: two things. One, it turned a 4, 000 software, whatever it cost at the time, into a 20, 000 piece of software. Honestly, to this

Evan Troxel: Value wise. Yeah.

Ian Keough: they're incredible. Um, this thing gave Revit capabilities That it couldn't do, and, and in the way that it was implemented, just, I guess by chance, managed to up level Revit. and, that was not only just like the geometry stuff, the adaptive components, all the stuff I've talked about, it was actually much more of the like, mundane, day to day stuff. Like, people don't remember that back in the day, if you were working [01:15:00] on a project that was 30 stories tall, and you were like, oh, we put a mechanical level in here, now we gotta rename all our levels, Like, you had to manually go and rename like 30, so a lot of the early years of Dynamo was like people automating sheet numbering, level renaming, just this really, but tag placement, like scripts for placing tags on pages in certain ways and stuff, like really, really run of the mill kind of stuff, and they were doing it themselves. And that was the critical thing, like they weren't waiting for Autodesk or waiting for some other script provider or whatever, so like that kind of motion that when you see that happening, you're like, oh, wow, this thing could take off, because now you've turned, you've turned every one of your users, not every one of your users, let's say of all the people using, Revit at the time, let's say there were 10%, percent at a maximum,

Evan Troxel: Right.

Ian Keough: Dynamo users.

Well, I don't know how many people that is, it's a fair number though, tens of thousands, hundreds of thousands of people, [01:16:00] um, at the time it was probably 100, 000 people, who are now developers. Building tools on top of your software. That's an incredible

Evan Troxel: Yeah, totally. Yep.

Ian Keough: Um, that's one. And number two, which is a little bit less nice that, you know, when you're a publicly traded company, you need to represent that the products that you're putting into the market are, are continuing to deliver value if you are going to raise the price and when you have an ecosystem like Dynamo provided, creating more value in the, in, in the ecosystem of people, you know, working on Revit. You could represent that Revit was worth more. Because it wasn't, you weren't selling Dynamo. Dynamo was free. You were selling Revit. And on top of it was this thing that like added all this extra value. And the value in that thing was growing, growing, growing, growing, growing all the time. It's still growing to this day, you know.

So you [01:17:00] could represent that you could actually charge more for Revit. this community was building all this extra stuff that

Evan Troxel: It's crazy, right? Because you also have these people building tools that are in the, show up in the package manager, right? That are adding value to that ecosystem and not getting compensated for it, right? So like, that's, those are, that, that's crazy, right?

Ian Keough: We had a whole, we had a whole, we had lots of discussions Going back to the beginning of Dynamo when Autodesk first started contributing to it Like, could we get these people paid? Like, could the, could the, the

Evan Troxel: Create a marketplace or something. Yeah.

Ian Keough: whose, whose, whose tools have been on Dynamo Since basically the Package Manager existed And might still be on the front page of the Package Manager As one of the most, you know, popular tool sets over all time Has never gained a cent From any of that stuff and I think Nate should be a millionaire,

Evan Troxel: Yeah.

Ian Keough: if he

Evan Troxel: Yeah.

Ian Keough: for every time somebody downloaded or a nickel for every time somebody downloaded his package like

Evan Troxel: Or [01:18:00] Conrad or John Pearson or like, there's so, there's many, many, there's, there's many. Yeah.

Ian Keough: And and and so that's always been one of the vexing things about like that motion Yeah, we had all these people and they contributed all this stuff and it never changed the way that value flows through a you see

Evan Troxel: Right,

Ian Keough: Everybody's still compensated in the same way for their hours, you know. This, yet again, dovetails into what Hypar is trying to do, but, um. So, the last big part of the story of Dynamo is when we, when we mashed it together with DesignScript. So, um, you remember that I, I, I was working on Generative Components at the very beginning of my career.

Evan Troxel: right,

Ian Keough: Components was made by this, this brilliant guy named Robert Aish. And some of your older users, your listeners will remember Robert Aish. Robert Aish was the father of generative components, which was a, which was another plug in, um, like Dynamo, like Grasshopper, [01:19:00] but it ran on top of Bentley microstations. And, or Triforma, uh, Microstation, I think, right on top of Microstation.

Evan Troxel: I believe, yeah.

Ian Keough: And, SMART, the SMART Geometry Conference, at least in the very early days, was, was a generative components conference. It was the conference where, where Robert Aish would run around with like a USB key on a lanyard around his neck that had the latest build on it. he would like plug it into your computer and give you the new bits.

Evan Troxel: Give me the juice, man.

Ian Keough: he was sitting in the corner like fixing problems with generative components in real life.

Evan Troxel: Wow,

Ian Keough: so a lot of us have Robert Aish to thank for, for a lot of his stuff. But one of the things that Robert had done to, at some point Autodesk convinced him to come over to Autodesk. Uh, um, I can't remember where he was, but like they, they were like, You gotta come to Autodesk and we'll, we'll, we'll allow you to work on all these projects that you're interested in and everything. Well, Robert, since [01:20:00] Generative Components, you should probably get Robert on the show.

Evan Troxel: yeah.

Ian Keough: Components had this idea for DesignScript, which was a language, a textual programming language. That had affordances in it for the kinds of programming that Archonneks need to do a lot of like I've got a facade It's made up of all these panels.

Those panels generally look like an array and programming terminology I want to index into like this row this panel this mullion on that panel and do this specific thing And so the the design script language, which is still the language that's in code blocks in in Dynamo It was it had these things called replication guides You That allowed you to do all that stuff.

So it was pretty cool. And it was also this associative language. So it had forward and backwards associativity, which I won't go into here, but if you've seen like very early demos of design script, was like kind of mind bendy when you watched it work, you were like, how was, how would that work? Um, and so Robert was inside Autodesk working on this design script project and he had this team in [01:21:00] Singapore dedicated to him building the design scripts, interpreter, the design script. Uh, Virtual Machine. A virtual machine is like the brain that runs, uh, uh, uh, this, uh, language gets compiled into a, uh, code that the, the virtual machine can read and run. it runs that code, um, and a design script environment. Because Robert started going around and telling people about design script. Um, be like, yeah, you know what this really needs? a visual programming interface. And he hated that because he was like designing this programming language. This was going to be so easy to use and have all these affordances for architects. And every single person who had now seen Grasshopper, who had now seen Dynamo, they were like, yeah, you need to put an interface on this thing.

So he had this team in Singapore start building an interface for it, and they called it the DesignScript Studio. And there was this guy, Luke Church, who might still be at Google today. [01:22:00] He, uh, he was put in charge of building the DesignScript Studio. Luke was another really, really interesting and smart guy, um, and DesignScript Studio was, was very pretty.

It was like, you could, you could, nodes and wires, and then you could get like previews when you hovered over a node. You could get a preview of like the compute at that exact moment. You'd get this like little visual preview of what was flowing through the system at that point. So they did all these like kind of clever things, but now Autodesk has two projects. DesignScript, and Dynamo, which are basically doing the same thing. And, and, Dynamo was further ahead in its visual programming language, and it interfaced very deeply with Revit. Because that was the other thing that people asked for. They were like, this needs a visual programming interface, and it also needs to talk to Revit. So Abhijit, who was the guy who oversaw both of these projects, was like, we're going to bring these projects together. And he told us this, he told the Dynamo team this, and we were [01:23:00] like, we're like, what do we, what do we need that for? Um, and know, I was just kind of like, Oh man, like. I had gone through the whole, like, F scheme thing with Stephen Elliott, and I was like, I really don't want to make, like, another, cause I knew this was gonna turn into some, like, big architectural, software architectural, like, thing that we would need to do.

Um, so I kind of rejected it at first. And I think Matt and Zach probably calmed me down and we're like, look, we kind of got to do this. It doesn't make any sense that Autodesk has these two visual programming languages that are being developed by two teams trying to like, what, beat each other or something. we started to sketch out like how this would even work. And the core piece of that to use the design script virtual machine as the engine. So we're going to rip out the stuff that Stephen Elliot had done. a third version of the Dynamo engine [01:24:00] based on the, the DesignScript virtual machine. And, um, that would give us a couple of really cool things. thing that the DesignScript virtual machine did was it ran on DesignScript, the language. So we could have programming interfaces in nodes inside HypeBar that you could type DesignScript into.

Evan Troxel: Dynamo. He said Hypar.

Ian Keough: did I say Hybar? Oh, sorry.

Evan Troxel: Yeah.

Ian Keough: there's no design script in Hybar. Um, inside Dynamo. Um,

Evan Troxel: Right.

Ian Keough: and, um, that was cool because then you could use replication guides and all this stuff, and if you really were into design script, you could, you could do that. And, um, the second cool thing is they had built an interface called ZeroTouch. ZeroTouch enabled them to take any NET um, managed class library library. gonna say technical stuff, but like, library full of like, [01:25:00] methods and functions and stuff. And emit, well you could drop that onto Design Script and it would, um, uh, it could read all of the public methods,

Evan Troxel: Mm hmm,

Ian Keough: and, and essentially create nodes for you that expose those things. So people who use Dynamo to this day still understand the concept of zero touch nodes.

You can literally like, grab a, an off the shelf, like, C sharp library from someplace, And drop it on Dynamo, and provided that it has public methods with certain types of signatures, it will just show up as notes. I actually don't know if this is still true, because I haven't played with Dynamo in a while, but that was the idea. And, it made development of external libraries, for creating nodes really, really easy and straight forward. So that was cool too, but what wasn't cool about it was that we now owned a programming language. Like, I don't, I have subsequently learned a lot about programming languages. Programming language implementations, [01:26:00] How to make virtual machines, compilers, uh, all this stuff that I never ever thought when I went to art school I would ever have to learn about but I had to learn about because it's like design script and getting like very very deeply into There but the problem is you make a core technology like that that is so arcane You kind of put a can't a hard shell around

Evan Troxel: mm hmm.

Ian Keough: very hard for other developers to get in there and change things adapt things You know that the the story that kind of And I don't know if it's, if it's, um, if it's actually true, but they say about, like, the Excel, the core of Excel. They've tried over the years to, like, touch that thing and edit it to do other stuff, and it's blown up on Microsoft and they've just, like, backed away. And so there's, like, a core in Excel that, like, was written by some of the original developers. And like new developers just kind of like work outside of that shell [01:27:00] and that's kind of what the design script virtual machine is like There's like

Evan Troxel: Well, it kind of reminds me of your story about Burrow Happold, right? Where, where it's like, what happened with the Dynamo library? And it's like, uh, you know, like, it's too hard to maintain. Like we, we couldn't even like, this maybe is still being used, but it's the same kind of a thing where it's just like, well, we couldn't figure out how to get in there and what to do with it.

So we just, we don't touch it.

Ian Keough: people do the same thing to each other. You know, it's not just like we know how like any software like, developer can get in and mess with any kind of code. And there's two pieces of code inside Dynamo that basically function like that. There's DesignScript Virtual Machine, and there's the Geometry Library.

The Geometry Library is now the Geometry Library that sits at the heart of a bunch of Autodesk products. And that was another big part of this upgrade. gonna switch off the Revit Geometry Library and go to ASM.

Evan Troxel: Mm.

Ian Keough: is the Geometry Library. And it gave us all kinds of, like, really sweet geometry. That we couldn't make before because Revit just couldn't make that kind of geometry and it has [01:28:00] compatibility with Revit. Um, so these things, the geometry library was definitely beneficial, but that's also another one of these things that like, Very few people get down inside that thing and muck around with it.

Because like, geometry libraries are, There's like a whole team of PhDs in like Oxford or somebody that work for Autodesk who, that's all they do is like work on the geometry kernels, right? And so, um, you had these pieces now that were like central to the architecture of Dynamo that, core team, there were like one person per that could like work on this stuff. So it caused a little bit of, you know, a challenge, but we did, we brought this thing out. There was a, there was a period of instability, which people will remember like yellow nodes with band aids on them and stuff, or yellow warning messages with band aids on them, a little cartoon drawings of, because things were breaking all the time. Like. We'd made all these giant architectural changes. And so, people were really kind of pissed, [01:29:00] like, cause we were breaking their workflows. You know, there was like stuff that just wasn't backwards compatible. Geometry libraries were different. So geometry didn't work quite the same way, but you know, to Autodesk's credit, they weren't backing down.

Like they were like, The only way out is through,

Evan Troxel: Mm hmm. Mm hmm.

Ian Keough: we just like over six months or something we just like worked down like of these things until we got to a place where we were relatively stable, you know, and, and, um, back on, back in a place where this thing was, you know, part of people's production kind of workflows. Um, and that was the last big transition and that happened probably two years before I left. And then at some point I, I transitioned off the. The Dynamo team to go work with Anthony, my co founder at Hypar, to go work with Anthony, on a Dynamo based project, um, which was called Fractal, but which would go on to become, [01:30:00] uh, Autodesk Generative Design. which I think still exists, and you can use it on top of Revit. Um, to use Dynamo scripts basically as the language

Evan Troxel: hmm.

Ian Keough: to run in that thing. Um, so honestly, I mean that, and that was 20, I probably haven't been involved with the Dynamo project since about 2017? 20, maybe 2017? So, so take everything I say here, listener, a huge grain of salt, because that team has worked incredibly hard Since then, and have maintained that community and probably grown that community.

Evan Troxel: Right.

Ian Keough: knew like a few years after I even left Autodesk, I knew that this thing had reached a different level. When I started to see job postings that had Dynamo it's like, what? Like,

Evan Troxel: Yeah.

Ian Keough: like by name, like [01:31:00] a software that you worked on, like is, is like a nice to have for, for somebody who's getting a job at an architecture firm, that seems. Insane to me,

Evan Troxel: Yeah. And, and there, and then after that, like you, you search Dynamo. I mean, it was like 2016, maybe 2015, probably 2016 AU, right? Autodesk University. You search for any course with Dynamo that you could find in the title. And they were awful. Every single one of them, all the labs, all the courses. Yep.

Ian Keough: yeah, I couldn't, I remember Zach laughed at me one time because like, other funny story about Zach is that he um, he makes his own moonshine. Zach Krohn, the product manager of, uh,

Evan Troxel: a listener of this podcast. Yeah.

Ian Keough: is incredible. He makes his own moonshine. He grows all his own grapes, like on these trellises around his house.

And then he, he makes, I don't know that it's fair to call it moonshine. It's this very clear, very strong liquor. he brings it to Autodesk University in these Mason [01:32:00] jars. And we would sit in the back of these Dynamo workshops, which at one point we're no longer run by Autodesk people. Like this was the community straight

Evan Troxel: Right.

Ian Keough: Pearson, guys like that, like running these classes. And he'd pour us cups of this, like. Crazy alcohol. And we'd sit back there and just like toast to the success of Dynamo. And he

Evan Troxel: A job well done.

Ian Keough: like, couldn't get into one of the classes. Like I, so I went outside, like it was so packed and there was an overflow line and I went outside and stood at the back of this overflow line. some point, somebody who was in front of me in the overflow line, like turned around and was like, Shouldn't you be in there? I was like, I didn't sign up for the class. I, I can't go in. I think I eventually made it in, but like, yeah, now it's like, it's crazy. Like the number of Dynamo classes and like, I, and I will say that, I mean, one of the most gratifying things, there's really two gratifying things that I still hear to this day.

It's like, when I talk to people about their Dynamo experience, they'll [01:33:00] say things like Dynamo completely changed my career, like it enabled me to grow. do things and level up and provide value, um, to my organization that I wouldn't have been able to do without it. And like, that just, it put me on a different trajectory.

Like the whole thing about, I'm not going to attribute this all to Dynamo. There's, there's been a lot of motion in computational design over the last couple of years, but like the whole thing that there are computational designers now, that's Grasshopper at work. That's Dynamo at work. That, the fact that that's a title, there were no computational designers.

Evan Troxel: Right.

Ian Keough: Before Grasshopper and Dynamo and everything else. So that's like a new class of, so that's really incredible to hear. I, I still think there's a lot of work to be done there, um, to change things. But, um, and the second one is people will tell me that Dynamo is how they learned how to program a computer,

Evan Troxel: Mm hmm.

Ian Keough: which blows my mind

Evan Troxel: Mm hmm. Mm

Ian Keough: and in a way, [01:34:00] They did it because they started with Dynamo Visual Programming, and then they got really frustrated that their graphs were like, so big and messy spaghetti. So they would start programming in code blocks, and they'd probably start with design script. And then they were like, ah, but there's all these like, really cool, Mostafa makes this really cool like, Python library that I can connect in, so I'm gonna use a Python node instead. So they'd put a Python node in there. start reading up on like, how to program in Python, and over time, more and more of their code, their visual program, started to disappear

Evan Troxel: hmm.

Ian Keough: these Python nodes. And then at some point they were like, I want to go like, as fast as I can possibly go, I'm going to write my own C sharp library that I import as a zero touch node. And then, once they've done that, they're like, well, I want to build my own like, stand alone software now. And so they like, or I want to build my own Revit plugin that just does this one specific thing. So the thing started as like a DynamoGraph. And evolved into it's own stand alone kind of thing, and the person who worked on that went from [01:35:00] knowing nothing about programming to like,

Evan Troxel: Yeah,

Ian Keough: That's,

Evan Troxel: now, and you employ people, you employ people literally who, who have been on that journey, right there.

Ian Keough: mind. Yeah, like I, like Hypar is a lot of architects. Like it's a lot of people, Andrew Heumann who's on my team is like the pro to, the, the, the,

Evan Troxel: I was, I was directly thinking of Andrew. Yep.

Ian Keough: you know, he is beyond in terms of examples of, of this. A lot of people look at Andrew and they're like, I want to be that guy.

Evan Troxel: Mm hmm,

Ian Keough: you know, he didn't start knowing how to program

Evan Troxel: right,

Ian Keough: Now his trajectory went Grasshopper.

Evan Troxel: right.

Ian Keough: Grasshopper community, but I think you have very much the same thing, you know, and now he's like our lead developer. So

Evan Troxel: Incredible story. Thank you so much for taking the time to tell it, and to tell it here. You never have to tell this story again.

Ian Keough: I'm I'm looking at the time now and I'm recognizing how long it took to tell and maybe that's why I've never told the whole Thing from start to end because you [01:36:00] never have enough time at the bar, you know to tell

Evan Troxel: Well, I truly, truly appreciate it, and I think the listeners will enjoy it very much, so they appreciate it as well. So, thanks Ian.

Ian Keough: I appreciate the opportunity of it always a always a pleasure to chat

​

Matt Wash and Konrad Sobon are back on the podcast (together this time!) to talk about their personal journeys and evolving roles within Bimbeats, how firms handle challenges around communication, training, and accountability, the importance of understanding a company's "digital footprint" for decision-making and transformation, and their insights on using data to boost productivity and business performance.

Watch this Episode on YouTube:

Episode links:

Connect with the Guests

• Matt Wash on LinkedIn
• Konrad Sobon on LinkedIn
• Bimbeats website
• Bimbeats on LinkedIn
• TRXL 007: ‘Reinventing the Wheel’, with Konrad Sobon
• TRXL 093: ‘Continuous Improvement Culture’, with Matt Wash

Books and Philosophies

Eric Ries’s The Lean Startup

• Wikipedia Overview
• Amazon Link
• Learn about the methodology of iterative innovation, rapid feedback loops, and minimum viable products, mirroring the approach taken by BIMbeats in early development.

Measuring What Matters by John Doerr

• Official Book Website
• Amazon Link
• Insights into setting actionable metrics and aligning teams around objectives, relevant to the approach of BIMbeats’ implementation and measurement strategies.

Outcomes Over Output by Joshua Seiden

• Amazon Link
• Understand the core principle discussed by Matt Wash regarding prioritizing meaningful results over mere productivity metrics.

Tools for AEC

Bimbeats

• Bimbeats Official Website
• Explore this tool designed to enhance productivity, software utilization, and management insights by analyzing digital practices across various platforms in the AEC industry.

Autodesk Revit and Dynamo

• Autodesk Revit Official Site
• Dynamo BIM Official Site
• Key tools discussed, central to BIM management, automation, and data-driven workflows in architecture and engineering.

Affinity Suite by Serif (Alternative to Adobe Suite)

• Affinity Official Website
• Explore cost-effective alternatives to Adobe products (Photoshop, Illustrator, and InDesign) mentioned as effective alternatives for companies managing licensing costs.

BricsCAD as an Alternative to AutoCAD

• BricsCAD Official Site
• Discover BricsCAD’s licensing model and functionality as a replacement for AutoCAD, providing substantial cost savings.

Digital Transformation

Nate Miller on Digital Transformation

• Proving Ground’s Nate Miller on LinkedIn
• Nate Miller’s blog post referenced by Matt: Three ideas for developing digital strategies to support smart, healthy, and fit businesses
• Follow Nate Miller’s insights on digital transformation in architecture and its implications for practice, referenced in the podcast.

Harvard Business Review on Digital Transformation

• Harvard Business Review: Digital Transformation Articles
• Articles and research on how digital transformation impacts company culture, leadership, and productivity.

Community and Open Source Contributions

Archi-lab Dynamo Package by Konrad Sobon

• Archi-lab on GitHub
• Explore the open-source Dynamo package developed by Konrad Sobon, highlighting community-driven innovation and collaborative software development.

Dynamo Community Forum

• Dynamo Forum
• Engage in the Dynamo community, a resource that Konrad referenced for collaborative learning and skill-building.

Personal Development and Workplace Wellbeing

Burnout and Productivity in AEC

• Harvard Business Review - Burnout
• Explore articles addressing the issue of burnout mentioned in the episode, providing insights on maintaining workplace wellbeing and productivity.

Related TRXL Podcast episodes

Additional TRXL episodes that discuss digital practice, software utilization, professional development, and firm culture in the AEC industry:

Episode 163 – ‘Confusing Evolution With Innovation’, with Nirva Fereshetian

• Nirva Fereshetian discusses the complexities of implementing and managing digital practice within architecture firms, addressing challenges like tool fatigue and the importance of understanding business problems when adopting new technology.

Episode 166 – ‘Dirty Little Secrets’, with Parley Burnett and Chris Shafer

• Parley Burnett and Chris Shafer explore hidden inefficiencies in the AEC industry, emphasizing the significance of BIM model health, streamlining processes, and eliminating technical debt to achieve better ROI.

Episode 168 – ‘The Challenges of Under-Digitization in AEC’, with César Flores Rodríguez

• César Flores Rodríguez addresses the challenges and opportunities in digitizing the under-digitalized AEC sector, discussing topics like real-time monitoring, cost reduction, and energy efficiency.

Episode 177 – ‘The Digital Futures of Architectural Practice’, with Kristen Forward

• Kristen Forward discusses the impact of emerging technologies on architectural practice, including computational design, BIM, and the role of AI and machine learning in shaping the future of the industry.

Episode 144 – ‘The SketchUp Story’, with Brad Schell

• Brad Schell shares the story behind the creation of SketchUp, offering insights into building company culture, leadership philosophy, and the development of a product that continues to resonate with users.

About Matt Wash:

With 28 years of experience in the AEC industry, Matt has held roles as a Technician, Structural Engineer, and Design Technology Coordinator. From the outset, he has employed lean manufacturing principles to eliminate waste and add value throughout the project lifecycle.

Five years ago, as one of the first Bimbeats customers, Matt was excited by the opportunity to quantify inefficiencies within architecture firms and communicate opportunities to improve both employee wellbeing and the company’s bottom line.

In the last two years, as Chief Digital Officer at ADG Engineers, Matt has collaborated with key stakeholders across the C-Suite and People and Culture teams. He has used actionable insights from Bimbeats to enhance the organisational health of the business, demonstrating the benefits of data analytics that extend far beyond “Revit Model Metrics”.

In 2025, Matt takes on a new challenge as CEO at Bimbeats, aiming to empower other companies to replicate the success achieved at ADG.

About Konrad Sobon:

Konrad K Sobon is an architect by education and a software developer by passion. Co-founder of Bad Monkeys, Archi-lab, and Bimbeats. Formerly an HOK, CannonDesign, and Grimshaw's Design Technology Specialist, BIM Coordinator, and Software Developer. Currently, he writes code for Archi-lab and Bimbeats while making sure that he finds time for his two daughters.

Connect with Evan

• LinkedIn
• YouTube
• Twitter/X

Episode Transcript:

179: ‘Analyzing AEC’, with Matt Wash and Konrad Sobon

[00:00:00] Welcome to the TRXL Podcast. I'm Evan Troxel. I'm pleased to welcome Matt Wash and Konrad Sobon from Bimbeats back to the podcast. Though they've both appeared separately before, you'll find links to their previous episodes in the show notes today, they join me together to explore several key topics.

Their personal journeys and evolving roles within their company, Bimbeats, how firms handle challenges around communication, training, and accountability. The importance of understanding a company's digital footprint for decision making and transformation, and their insights on using data to boost productivity and increase business performance.

Real quick, before we get into today's conversation, do me a favor and if you're enjoying these episodes. Please subscribe to the show wherever you watch or listen, so YouTube or on your favorite podcast platform, and leave a review on Apple Podcasts or Spotify. That really does help people find the show, which [00:01:00] is important to me, so that I can keep finding great guests to interview. You can also support the mission here by becoming a paid member at TRXL.co.

Just click the join button in the lower right hand corner or the subscribe button at the top or the bottom of any page on the site. If you'd like to receive an email from me when new updates are published with all the links and other information as they come out, sign up for that by becoming either a free or paid member at TRXL.

And speaking of email and memberships, one of the perks of a paid membership is my Leadership Edge newsletter, in which I provide key insights for forward thinkers who are seeking innovation in AEC, but are short on time. They're designed to keep you updated, spark your interest, and encourage you to tune in to the corresponding episodes if the ideas resonate.

Leadership Edge newsletters are only available to paid members of TRXL+, and you can become one at [00:02:00] TRXL.co. To get a taste of what's on offer, search for Leadership Edge on TRXL.co for previously published examples, this was a great conversation with Konrad and Matt and there's an extensive amount of additional information in the show notes if you'd like to go deeper. So be sure to check those out. They're in your podcast app if you're a paid member or if you're a free member, you can find them on the website.

And so now without further ado, I bring you my conversation with Konrad Sobon and Matt Wash.

​

Evan Troxel: Today I'm joined by Matt Wash and Sobon. So It's been a while since both of you have been on the podcast on different Occasions, never together like this for the first time. So you guys are both working at BIMbeats. Konrad has been at BIMbeats for a while.

Matt was at BIMbeats, went away from BIMbeats. He's back at BIMbeats as the CEO. And I think we'll hear a little bit of that story in a minute. [00:03:00] Konrad, you were one of the, I, I want to say you were like episode seven or something. I didn't actually go back and look, but that's just what my memory says. And so it's been a while since you've been on the show. Catch us up on, on what life has been like for the last few years. This podcast is four and a half years old, so it's been at least four years since we had that conversation.

Konrad Sobon: Yeah.

Thanks for having us. Um, last four and a half years. So this was right after we moved from New York. So a little bit after the pandemic, right? So maybe just kicked off. We're very, very much a startup at the time. Um, a lot of things have changed since then. I mean, for me, Probably the biggest thing has been, uh, just growing as a company and hiring people. I've never done this in the past. So out how to kind of switch from just, you know, head down and coding and working in that mode a little bit more to managing, uh, that's been a big. [00:04:00] Um, so I'm happy to, I'm happy to have Matt with me now, so help out with that a little bit more. But,

Evan Troxel: Balance

Konrad Sobon: um,

Evan Troxel: right?

Konrad Sobon: yeah, yeah, so, so we've, so we've grown a little bit. Um, you know, work wise, I still pretty much do, um, similar things that I've done 4 or 5 years ago. It's just, you know, A lot more of BIMBEAT, a little bit less on the consulting side of things with ArchiLab. Um, and you know, I got two daughters now, probably, um, four and a half years ago, I only have one, a little baby, but now I got two daughters and the other one just turned five.

So that's, uh, uh, those are interesting times. Um,

Evan Troxel: you extra busy

with all that.

Konrad Sobon: Oh, yeah. Yeah. And I just, I mean, my wife and I recently looked at some old pictures when she was born and, I'm like laying on the couch with her and had a, I had a full head of hair, you know, I've, I've, uh, I've got myself up to the proceeding [00:05:00] uh, status. Um, and I definitely was not going gray at the time just yet. So that caught up to me pretty quick.

Evan Troxel: It happens to us all. And then there's those, those people who like to hide it, but not me. I just full, full silver streaks on this side of the, you can charge more. That's what I've, I've been told is that the more gray you have, the more you should be able to charge because it's, it's experience. It's

like right there.

Konrad Sobon: Yeah, the seasoned vet right now.

Evan Troxel: vet. Nice.

Konrad Sobon: it short because, uh, I look a little too old, maybe.

Evan Troxel: Nice. tell us kind of what has happened at BIMbeats from your, in, in your role over the last four and a half years since we talked last. Just, just in terms of maybe, maybe scale a little bit because I, that's one of the things I've always been so interested in with what you guys are doing specifically. and and so, like, historically, you started out by [00:06:00] providing You know, metrics into different applications on the computer. And, and so maybe just give us kind of a, a baseline for those people maybe who don't, aren't familiar with you at all. What, what BIMbeats is about and then how you've seen it change over the last four and a half years before we jump over to Matt.

Sorry, sorry Matt, I'm not, not trying to ignore you yet, but I think there's some, there's something here to just kind of set the table for this conversation.

Konrad Sobon: Sure, sure. So how about, how about I go back in time a little bit, jump into a time machine and, um, in my days as a BIM manager, that's really where the idea for BIMbies and, uh, kind of generally, some kind of data analytics platform, uh, came to my, uh, came to mind. So this were, these were my days of, you know, just. Regular BIM coordination, BIM management, jobs that I was doing, I think, with Grimshaw at the time. And we were a relatively small office, so I would have whatever, whatever projects were in the office, we're splitting that between [00:07:00] myself and my manager, Greg. And then, you know, just. Deadline after deadline.

You're working pretty much every Friday is a deadline. So, you know, you're running four or five, six projects at a time. and I was like, yeah, it's just, you know, it's too much. Like, I can't keep up with all of the different projects, all of the different models. How do you, how do you do that having to go into all of those different models?

And then, you know, at the time I didn't have much, um, What kind of programming skills to go off of and just build a platform per se. So we started off with Dynamo scripts, right? And that didn't scale too much, but then eventually over the years, um, build out some other tools. Um, when I worked at HOK, we spent a lot of time working. Again, with my manager, Greg, I've had a, I've had luck with Greg's. Um, so, you know, Greg Schleusner and I are working at something called mission control at the time. And, you know, that was a different spin and different approach of trying to pull data [00:08:00] automatically. So there's a BIM manager. You can kind of have a quick look into the models.

And at a time, the conversation was always, you know, You're kind of building the tools for yourself always. So the conversation was Revit, Revit, Revit, because as a BIM manager, that's what you're really interested in is, you know, but as the scale grew, um, and, you know, after, after HOK, uh, we started working on BIMBEADS with Adam and, know, the idea, the idea then kind of turned is like, you know, why don't we scale horizontally?

So it wasn't just about Revit and model health metrics, um, from. Revit files at a time, um, we started talking about pulling data from all sorts of other applications, right? And, you know, four and a half years ago, maybe, this was just Revit Dynamo and maybe Rhino Grasshopper at the time. then, um, We're probably up to, you know, a dozen different sources of data, uh, just recently pushed out, um, a new integration for [00:09:00] ArcGIS.

Um, obviously we do AutoCAD, Navisworks, um, all kinds of standalone applications that pull data from your computer about the hardware, about the processes that you're running on the computer, just, you know, a ton of different sources of data. Uh, so we kind of scaled that horizontally. So it's no longer just like a model, Health metrics, uh, platform, um, as, as it was originally, um, in order to aid managers, uh, right now it's more of a, you know, digital footprint for the company and you can use it for all kinds of different things.

Evan Troxel: And it really ends up telling a lot more of the story, right? Like, like, model health is not the entire story, right? And so you've got performance, like hardware performance, right? All kinds of additional insights that you're kind of pulling from to tell a broader story so that you can really understand, like, what's going on with the quote unquote health or maybe fitness of, The digital [00:10:00] of your company as you're working on delivering these projects.

Konrad Sobon: Yeah. Yeah. Matt, you want to jump in? Cause, um, so Matt before, uh, kind of assuming the role of a CEO, he actually worked on a, as a, on the client side of things. So he has a unique, um, perspective on, you know, the actual application and use cases, uh, for Bimbeats. So I'm gonna, I'm gonna let him.

Evan Troxel: throw it over to Matt, who is definitely the CEO because he's wearing the uniform. He's got his Bimby's shirt on. he's doing his marketing really well today. So Matt, yeah, give it, give us an update on, you've also been on the show previously and. you were at Bimbeats at the time, you went away from Bimbeats, came back, I'd love for you to hear a little bit behind that, but maybe we start with where Konrad just led, which was, you were actually, like, in a firm, using this kind of stuff, and I think, you know, go ahead and jump off and

let's hear it, let's

hear about it.

Matt Wash: [00:11:00] Yeah, okay, I'll do a quick summary of what we spoke about last time. So this was when, when I first got involved with BIMbeats was, um, I'm a good friend of Adam Sheather. Adam lives in Brisbane. We talk about this kind of stuff all the time and I was explaining to him a problem that I had. I was a design technology leader of BVN Architects and our challenge was really understanding why Revit was crashing regularly.

and how we could get to the bottom of that. And I just kept saying, look, it was taking up so much of my time trying to analyze journal files and work out, was it the RAM? Was it the infrastructure? Was it the model? Was it the competency of the user? All of these different things. And he's, that's when he said, oh look, we're building this tool that will be basically able to solve all of those problems.

So I'm like, well, sweet. Let's just implement that. So, we worked on, I think we were the first client of, of BIMBEATS. Uh, and back then if, if you've ever read Eric Rees um, the lean startup, these guys definitely achieved pushing out that, um, that minimum viable product. Um, in that It, it, it was [00:12:00] aiming to solve one of the biggest problems we had within the office.

Um, were the dashboards any good? No, the dashboards were not good. Did we really know how we were passing the data and all the different index patterns? No, not really, but having Adam there and getting regular feedback, we constantly iterated on the product and we got it to a point where We were automating alerts so that when Revit was crashing, it was automatically sending a help desk ticket to our IT team, which then told them, was the RAM, you know, at capacity, was the hard drive at capacity?

What was the user doing prior to the crash? So all of the metrics that I was doing manually. was now being captured automatically. Obviously, we didn't solve every single crash. There was too many variables, but we did get to the bottom of a few key things that we were then able to action, make some changes, and then use BIMbeats to look at frequency of crashing, obviously, as the key metric has that come down.

But then we really started unpacking, well, what is the business impact of what we're doing in terms of how much time are we wasting [00:13:00] Opening files and saving files. They were the two real key metrics. And to start with, when we would present back to leadership, it was all around model health and a traffic light dashboard, but didn't mean anything in terms of commercial aspect of the business.

And it didn't really talk about competency profiling and skills gap analysis, which were the two real things that we needed to address. So I did that for a while at BVN. And then because I started unpacking a lot of these insights, Konrad and Adam Settler. You've probably got the most experience of this tool in the industry, and with the use of it, how about you come and join us and start developing it with us and talking to our clients and doing exactly what you've done at BVM, but now for everybody.

So then I started working with a company called ADG, engineers in Brisbane, who were a client of BIMbeats, and they said, we've had BIMbeats for a couple of years now. We know that it's pretty good. Providing all of this useful data, but we're really not understanding what we can do with it. We're really not getting the benefit out of it.

Do you know someone that could come [00:14:00] into the business and play that role of really trying to analyze what it, what it's doing and how we can get benefits for the bottom line of the business? But really to address their biggest problem, which was burnout and retention of staff. That was like, and it's an industry wide problem, but it was also one of their biggest challenges.

So I said, Oh, wow. Okay. Yeah, I think we can probably solve this. It isn't going to happen overnight because this extends far beyond just the technology. Like, this is now talking about people and culture. This is talking about Like the three things that, ironically, this morning on my commute into work, I've just read Nate Miller's post, and if you haven't had a chance to read it, it is awesome.

It got posted on LinkedIn this morning. But he talks about three things. He talks about being smart, being healthy, and being fit. And the being smart bit is that you have the right tools within the businesses, you have your processes, you have your systems in place. Then you talk about health, and the health is all about the culture of the business.

And it's not relying just on a few individuals who are passionate about the technology. It's gotta be. The entire business supporting [00:15:00] this and then from fitness point of view, it's you've got to measure the success of this in order for it to have long term success. You've got to have those three components and the final piece, the fitness piece is the one thing that I think BIMbeats does really, really well that we can buy the software.

We can write the processes. And we can do the culture, which is the hard bit, but measuring the benefits to the business was the one thing that over the last two years, before I took the role as CEO, was how do I communicate this to the C suite within this organization, that, that those three things need to come together, but it's really about that measurable benefit at the end, in terms of people, so the health of the people and the health of the business.

So then it started looking, and none of this really was related to Revit, believe it or not. Because, because BIMbeats looks at every single process that's running on the machine in terms of software and web applications, what we actually started [00:16:00] with was, where are we spending our time across the entire business?

Let's look at where the effort is. And we found that 20%, we're an engineer, or we, I keep saying we, because I was only there a month ago, uh, an engineering consultancy that does civil, structural and construction services. And we found that we spent the entire business time in PDF markups. And we were like, there's got to be a better way to do PDF markups.

There must be ways that we can automate a lot of what we're doing here. So we then started drilling down in BIMbeats, like, what are we doing in Bluebeam? And we found out that we were doing slab reinforcement markups and wall elevation markups. And those two things were contributing to a significant amount of hours.

And in fact, in terms of total billable hours, we're 250 people. Bluebeam was costing 10 million dollars of billable time every year. And it's like great, Bluebeam is an awesome tool for doing digital markups, but what of those digital markups could we do differently that [00:17:00] doesn't mean an engineer is marking something up, giving it to a technician, the technician tracing that and then giving it back forwards, backwards and forwards.

So we looked at the slab reinforcement markup process and then we started chatting to people that were doing that process in terms of the engineer and the technician. And then we started revealing all of this duplication of effort and frustration around that process. So we got one of our developers, who was a previous, or is still a structural technician, who's been doing reinforcement detailing for 20 years.

He's learned how to code, so he knows the problem we're trying to solve. And he built a tool that exports the contextual background from Revit. into what we call SmartMark. The engineer comes into our SmartMark application and does a markup as they would do in Bluebeam. But because it's come from Revit, it's got the intelligence of the context of the slab.

And as you go to mark up that slab, it understands what type of bars you need to apply, where you need to lap the reinforcement, where you need to crank a bar, because it's got the context to Revit. [00:18:00] Then when the markup's finished by the engineer, it just gets sucked directly into Revit and it turns it into Revit componentry that is fully scheduled law reinforcement.

So we then started tracking the uptake of, well, okay, we now need to train everybody in the new application. So we've written 10 two minute tutorials that go on the intranet. Within BIMbeats, we can see who's using the application. We can see who's done the training. So, I think the most insightful part, and this probably comes back to the cultural piece, is we identified the problem.

We solved the problem with the software. But then the next point was, well, how do we integrate this and adopt this as business as usual? So we did, we did a national update to the entire business on Teams. And I had a 10 minute slot to talk about this process and why we were doing it, the metrics behind where we were spending time in Bluebeam and how we could save that time.

And I get 10 minutes of an hour slot of like a town hall for 250 people, and I'm probably about 20 minutes into this presentation. [00:19:00] So anyway, we deliver the, we deliver the message. We tell them that. On the intranet, this is where all of the tutorials are, this is where the application is, like, here's the expert, we created a Teams channel for feedback, so anything, bugs, whatever, here's where you provide the feedback.

And the uptake in the first month was almost non existent,

Evan Troxel: crickets,

Matt Wash: I'm like, Too weird. And I'm like, what's, what's, what have we done wrong here? We've identified the problem,

Evan Troxel: grail.

Matt Wash: And I'm like, there must be something we're doing wrong here. And I'm like, I know what I'm going to do. I'm going to look in Bimbeats and look at that Teams meeting.

And because we get the title of the screen of the active window

Evan Troxel: What was

Matt Wash: that presentation,

Evan Troxel: time?

Matt Wash: we can see the, we can see the engagement. So, For the first two minutes of our town halls, we have up to about 160, 170 people of the 250 from the company. And then as the minutes go on, it drops off.

Evan Troxel: the window

that's [00:20:00]

Matt Wash: Everyone, everyone's got multiple monitors.

And then I go and check everybody's typically back in Revit, back in the structural analysis applications. Or anything but, and by the end of that meeting, 5 percent of people have actively engaged with that content from start to finish in terms of it being the active window. So that made us think about what's, what's our communication strategy here?

Like, what is that meeting about? What's the intention of that meeting? Is it to inform people? And it's, uh, if you listen in, great, you learn something, but if you don't, you, it's, it's okay. If we're trying to communicate a message in there that needs to change business behavior, that is going to affect an outcome, that platform is obviously not the right platform to do it.

And we've got to think of a different way of doing it, but we would like, we would never have known that if we didn't look at the data. There was anecdotal evidence that we thought that certain people would, you know, I do, I go off and do other things, but it was actually really insightful [00:21:00] to see that like 95 percent of people tune in to start with.

And then I obviously kind of tune out. As the presentation goes on.

So that was when it's like, okay, reinforce the message regularly and the BIMbeats dashboards were then looked at over time. So month by month, how many people are using the tool? How many people have done the training? And it's, it's taken longer than we thought it would.

It just showed that we've got to continuously reinforce that message and continuously measure it because if we assume that we've done all we need to do. Really, it's, it's got to be that continuous measuring and managing that process. It doesn't just happen. It really comes back, and I guess that comes back to the cultural piece as well.

But having our intranet and having BIMbeats capture who's using our intranet and what content on the intranet. That's been really insightful too, because we have one page Gems. And the one page gem is a summary of something that's really important and critical to the business. And that one page gem can be read in like two or three minutes.[00:22:00]

And the engagement with that content is great. Like, everybody reads the gem. When we record Lunch and Learns and put them on the intranet, Literally no one goes back and watches them. So like, now, so I guess my point of view in terms of BIMBEATS and what I was trying to do with the last two years is, as Konrad kind of alluded to, it's not a model health checker tool anymore.

Yes, it does all of that. But this is like this digital footprint of your organization and is measuring the success of your digital transformation. And that for me was when I went, Wow, like this tool is so powerful. And that was when I said, Hey, Konrad, I'm really keen to come back again. What do you think?

And that, and Adam had grown Autonomation, his consulting business from when I started, there were four of us and that consulting business is now up to 18 people and Adam's like, Oh, mate, please. Please come in and do it because I am just like exhausted. I, I, I just can't do both. So that was when I said, yeah, I'd love to come in and do that.

And then in the last, [00:23:00] so I've only been in the role since mid December and from mid December until now. I talked to all of our existing clients and everybody says the same thing. You don't do anything on social media. There's no presence online. When we talk about you, no one knows who you are. He's laughing.

Um, and then we, so I said, okay, well, we're going to get someone into help with marketing. And then she's come in and she's like, how have you grown to the size that you are with these clients with no marketing at all? And I just said, it's just word of mouth. Everything to date has been word of mouth.

We've done a couple of conference presentations, but like very, very little social media presence and such. And she's like, right, that's got to change. We've got to tell people what you guys are doing because I did, I did, I did tell her that and I told her I'm going back on it again tomorrow. And she was like, Oh, that's great.

When was the last time you did it? I was like, uh, 2022, I think. She's like, yeah, you probably need to tell people what you're doing. So that was, I mean, and we know that, right? And [00:24:00] it's great, like the fact that we have grown to probably, what, 60 clients now at Konrad?

And pretty much through word of mouth, which is great because obviously, you don't need to sell a product if someone's telling someone else how good it is.

Um, which is, which is amazing. Um, and big shout out to, um, Alex from Woods Bagot who actually did a presentation at AU this year on, um, Data metric tools or data capture tools for um, Revit. Um, and if you haven't seen it, I'd advise watching. It's a really good presentation that talks about all the different methods of capturing data.

Um, but yeah, we're relying on other people to do our marketing and sales for us, which, which is great, but. I think we want to extend our 60 clients to, to be a bit bigger than that. Um, and I think the other thing that we probably haven't touched on it. Well, Konrad did a little bit about the purpose of BIMbeats.

So I often like reflect on what's my purpose and what I want to do. And I, and I think it's stemmed from being that frustrated BIM manager, that frustrated [00:25:00] computational designer. And Konrad and I had a bit of a chat about this in the, like, when I first took on the role. And then we started unpacking, and Konrad can probably elaborate on this, about how Konrad used to be on the Dynamo forum asking, answering all of these questions, and building ArchieLab package, and giving it away for free.

And I'm like, There was no commercial gain for any of what Konrad was doing there. And he can, again, he can elaborate on this, but it was like the fulfillment of helping someone and someone else feeling like you were helping them was far greater than any financial gain that you could make. And that was the frustration that we were having within organizations was the matter how much effort we put in, we didn't feel like what we were doing was being recognized and rewarded for.

And I guess it's probably because we didn't have a tool to measure what we were doing. And that. message didn't get up to leadership about the benefits of those actions that we were doing. But I guess for me, I really want to give back through Bimbeats so that all of those frustrated BIM managers and computational [00:26:00] designers of the world do get recognized and rewarded, because we will be able to measure and the benefits that they're having for businesses, and also start looking at, they are the people that are typically the ones that are burning out and doing the longest hours, which is ironic, because they are the most efficient people within the business.

They are your 80 20. They are your 80 20, yet whenever I look at the wellness dashboard on any organization, typically the most overworked people are are the most efficient people and the ones that are really making a difference, but it hasn't been scaled across that business, but I'm going to hand back to Konrad because I've been talking for too long.

Maybe you want to elaborate a little bit more about why you created Archilab and Dynamo, the Dynamo forum.

Evan Troxel: Let's take a break from the conversation to tell you about Arcol, who is helping make this episode possible.

Architects should demand more out of their design tools. Imagine working on a project where architects, owners and contractors are truly in sync. No miscommunication, no [00:27:00] back and forth chaos, just seamless collaboration. That's what Arcol makes possible. Arcol believes teams shouldn't have to waste time switching between apps and navigating endless email threads. Your tools should work for you, not the other way around.

With Arcol, you can validate ideas as you iterate your designs while keeping all your documents and people aligned. No more silos. No more guesswork. Just better results.

Ready to upgrade your team's design workflow? Learn more at arcol.io/TRXL That's ARCOL.IO/TRXL

My thanks to Arcol for supporting this episode of the podcast And now, let's get back to the conversation

Matt Wash: forum.

Konrad Sobon: Oh, the package? for me it was always, the learning, um, You know, like you were explaining, there's an [00:28:00] awesome sense of gratification. You can go on the forum and answer someone's question. That's part of it too, but you also get so much from it yourself. it's not, um, you know, back in the days I was working as a consultant, so it wasn't anything monetary, but, um, but, you know, someone asked a great question that you don't know the answer to.

You know, it's, you know, just finding out. Oftentimes, you know, I would just, like, come into the office in the morning, and I was still, you know, back in my Grimshaw days, and, um, I would come in early, and I'd just, you know, spend the first 30 minutes or so, uh, just looking for an interesting question on the forum to answer, right?

And that was, know, that was, like, something new to me. Uh, Tulare, it's like, you know, I don't know, when you wake up and you go out for a run or stretch or something else, just for me to stretch my brain a little bit in the morning.

Evan Troxel: like, it's like doing the crossword puzzle in the morning,

right? It's like,

Konrad Sobon: On your right, yeah, on your right at work, yeah, you read a book or you do a crossword [00:29:00] puzzle or whatever. for me, that was just, you know, like a little mental stretch or workout or whatever. Um, know, you learn something new and, um, and that at that time is, uh, a lot of, a lot of the crowd, the people that I was hanging out with, um, you know, people like Mustafa, David Vance, um, they were all super keen into open source software as well.

So that's, that's why ArchiLabs has always been, um, open source and available to this day.

Evan Troxel: I think back to kind of something that you both touched on, which is like you, BIMbeats exposes the problems, problems, plural, right? I mean, it's challenging. And I think we probably talked about this on both of our previous podcasts with each one of you, respectively, about of people. are scared to kind of even understand what the problems are because they think they're going to get in trouble, right?

And, and so we've always kind of couched [00:30:00] this in, no, we're looking for opportunities to improve. And if things need to be improved, like this exposes that, and now we can improve those things, right? Um, I mean, that makes a lot of sense, but I think a lot of times, and you both have alluded to this today, and, and I mean, I know we've had conversations about this as well, where just seeing that information is usually where people stop talking about this stuff, and, and because the doing it is the hard part, right?

It's like implementing new software, easy, getting people to do something differently. Very, very, very difficult. And Matt, you talked about communication and kind of always bringing it up till you're sick of bringing it up, probably beyond the point at which you're sick of bringing it up, but that is literally the only way things actually happen is if things are like at the broken record, right?

It's, they're just on repeat. think it's, it's interesting from a communication standpoint, something that I heard. Yeah. was that you basically have six minutes to [00:31:00] engage with people to get them to interact in an exchange for it to have a meaningful outcome. Otherwise, they do what you talked about, Matt, they click on something else, they pull out their phone, they're doing email, they're, because there's no engagement there.

And I think we can all look at, you know, social media or other online behavior. Like you said, Matt, even like I could look at myself and see how I, what I do. Right. And, and, and you were literally do what everybody else does. And we all know this. And yet we still have like this really terrible Microsoft Teams interface that we communicate over with bad cameras, with bad microphones, with bad lighting, with people stumbling through 1800 bullet points in a PowerPoint. Right? We don't change any of that stuff to actually engage people, and then we wonder why nobody wants to do anything, and it's because they're busy, and it's because they're distracted, and it's because of all of these things. I'm curious from, uh, like, like, number one, yeah, you guys make a [00:32:00] tool that really tells a story that you can then, Come up with strategies to overcome that.

And that's where the, it's like, it's like you did the work and now the work starts after you've done the work, right? Like that's when the actual work starts. And I'm curious from your standpoint, like, it sounds like you got some traction in your firm, Matt, but you guys touch 60 different companies. What's working for those companies? What are you hearing? Because it's like, yeah, you can keep coming up with ways to show. Where issues could be and maybe connecting those dots. It's like sync times and model health and computer hardware and all the, you know, internet connections and it's all these things. it's personal behavior, but like, how are people actually addressing these and getting positive outcomes because the bigger the firm, I, the harder it is, right? Just because of this stuff can be so available on an internet for somebody to just completely ignore, right? And it just gets lost in the, in the feed at some point.

So really curious, like, what [00:33:00] are you finding as ways that are actually making Firms are finding success trying to come up against these challenges, solve these problems.

Konrad Sobon: Yeah. Um,

Matt Wash: Whoa, that's a big question.

Konrad Sobon: I would, I'll tell,

Evan Troxel: be a handful of things.

Konrad Sobon: I would try,

to answer, although I was, I always, I always keep telling Matt, um, or not keep telling that. Like I, I, I've told Matt a few times and probably a couple of other people in the past that, you know, I'm in a, in a weird situation, um. Because, you know, working, working on a product and, um, then working with clients in the, in the support world, I only hear from people when they having, uh, some kind of trouble or something's not working.

So I have a,

I have a skewed perspective. if someone asks me, maybe this is like the worst software ever, cause that's literally what I get. I get, you know, I only get bugs and I only get issues, but. Um, that aside, um, every now and then, usually, usually in person, [00:34:00] uh, when we're like at a conference or an event like AU, mentioned Alex, so like, even this year when Alex did that presentation, he also came over to our booth, uh, we had a little stand booth thing at the, uh, at AU, um, you know, that's when you hear some, some of the stories and how people are actually, um, using the tools and how they work, how they work in. so, um, Couple of couple of different ways. I think there's that the people actually action or utilize this data and it's like. What Matt was trying with, what Matt was saying with ADG that there's, you know, you implemented some kind of solution and then you're trying to communicate to people and kind of ask them, or the other approach is you're just kind of forcing people into some kind of solution.

Like, you give them no choice, but to adapt to it.

Evan Troxel: Mm hmm.

Konrad Sobon: what that could look like. It's, um. Um, let's say like Adobe, I don't want to rain on Adobe, but Adobe, uh, the way the licensing software has been a hurdle for a lot of companies. [00:35:00] So this, this is a, this is a, this is a problem that comes up with, with majority, if not most of our, um, you know, most of our clients that we work with when it comes to BIM, it's like, what do we do about these rising costs of licensing for Adobe products? So there's a couple of different approaches that people usually take. So when we were at HOK, um, I remember we had the exact same problem, no BIMBIs at the time. So we send out questionnaires and ask people, it's like, hey, there's this new product by Affinity, um, called, uh, Design, Photo, and Publisher. Those are three competitors to Photoshop, Illustrator, and InDesign. And they're only 50 perpetual license, as opposed to 25 per user per month. So a massive cost difference, Functionality wise, they're very similar to each other. So at the time at HOK, I think we sent out a bunch of questionnaires, like, you know, Google Forms and ask people, Hey, how much do you use Photoshop?

And can we swap you over to an Affinity photo product? You know, everyone just, you know, [00:36:00] blanket tells you, you know, they write to, if they touch the questionnaire, they'll tell you they're using it every day. And, you know, they don't want you messing with their productivity. Standard answer.

Evan Troxel: yeah, right.

Konrad Sobon: It's like, don't touch me.

Right? So I see over the years, uh, You know, different companies take a different approach to this, right? So, we've seen the strategy where people just automatically disable someone's license. So they use BIMBY's data, right? To look at how much have you been using a given product. if you haven't been using your product for the last two, three weeks, whatever you set that metric to be, um, there is an automatic action that disables your license. Right. And then companies have been trying to, you know, uh, software center, uh, is one of, one of those solutions where they can use, uh, to kind of give you ability to download or install any other software as a replacement. Right. So, even though they pull in your license, they've given you an option to, uh, to replace that. So that's, uh, Kind [00:37:00] of, you know, they leave you no choice, right? You're like, you're not using the product. We're pulling your license and you swap and we're swapping you over. The other one is they pull in your license and they give you an option to get it back. So you can always, like if you're on a vacation, let's say it's like a false negative, you can get that license back, right? Or, um, they just switch you over to a different product altogether. There's no in between, right? So, so we've seen companies like, but there's Adobe issue. either kind of switch the low productivity or people with low usage of a given product to a competing product because they know they're not using it a whole lot. Um, so then, you know, like if you're opening Photoshop to resize images and change levels on an image, you can do that with, you know, Photo app or Paint for lack of a better product. can do it with Affinity as well. Like all of those functionalities still exist there. So if you're not using that product a whole lot, there's a cheap alternative. Um, and then you just leave alone. You know, your marketing [00:38:00] department, basically, right? Because they, the high users, and that's going to reflect in the data, like, you can easily spot someone who isn't, you know, publisher a lot, you know, that's your marketing person. So you usually just don't touch them. Um, and then, you know, everyone else just can switch over or, um, You know, you just switch the whole company and they don't have a choice of getting their Adobe license back.

You know, I've seen that happen as well. All right, so there's, you know, so you, like, like Matt was saying, you get a couple of options, right? Some people, you know, ask nicely and you kind of hope that they're going to switch over, go to Software Center, download the software. just automatically pull the license for them and, um, and force them to move over.

Um, so yeah,

different approaches.

Let's take a quick break from the conversation to tell you about Avail. Is your team struggling to find the BIM assets they need? Avail's content management system simplifies access to all of your firm's content in one easy to [00:39:00] use platform. No matter where your files live, or what type of files they are, you can easily search and access them from Avail.

Evan Troxel: Now, designers can consistently find and reuse all types of content. So what does that mean? Well, standards compliant models and drawings are easier to create. The documentation process is less chaotic, new hires are easier to onboard, projects are delivered faster with fewer errors. You get the idea.

Visit getavail. com to try Avail for free and request a free demo. That's getavail. com, G E T A V A I L dot com. My thanks to Avail for supporting this episode of the TRXL podcast. And now let's get back to the conversation.

I

would say it's kind of, it's sometimes, it's

it literally is a

business decision. I think everything that you mentioned there, It says this is a business decision, but people are attached. At least they, they think they're attached to, and they might even [00:40:00] think that they're a power user, but they're just doing levels commands and moving layers around inside of Photoshop, right?

Like, like you said, you can do that in Affinity Photo, no problem. But there are a lot of people, I think, think that they're more attached to these things than they are. And the business actually has to make business decisions. I mean, when SketchUp changed their licensing, it was a big deal. Adobe. Autodesk, there's all these companies that have made this very expensive, you know, from a, a software purchasing standpoint or just subscript through subscription models and businesses have to deal with that in real time or it gets away from you.

I mean, you could just get to the point, I guess, where you won't pay the bill, but, but it's like, then, then you're in a real hard place because you have had no ramp up to using to give your staff an option to use something else. And now you feel like you're kind of a prisoner in the these You know, in these software packages because you, you literally can't have anybody use anything else because they don't know how to use [00:41:00] anything else and, and all that downtime costs way too much money. it's, it's really interesting that these are the things that BIM managers and IT managers have to deal with. Right? And I think one of the things that I wanted to go back to that you mentioned, Matt, was this 10 million in Bluebeam usage, right? Like, like time being spent in Bluebeam doing a lot of repetitive things that maybe don't need to be done so repetitively.

Maybe those can be automated. I'm just curious, like, what did you want to get that number to? Do you have a goal? Did you have a goal at ADG to get that number down to? Some percentage of that and, and then, and then like then, then you kind of extrapolate that naturally across different software packages in the company.

Right? It's like, well, you know there, there's a lot of reasons why Bimbeats really

helps businesses understand these kinds of issues.

Matt Wash: Yeah, our goal was 10 percent and it was obviously a nice number because we were at 10 million. Let's save a million bucks. Like, it was pretty easy. Um,

Evan Troxel: just just save 10%, not get down to [00:42:00] 10%

Matt Wash: just saving 10 percent is, is a million bucks. So nice, easy numbers that everyone can understand. And, and in six months time, when we've done a year worth of SmartMark, I'm going to be really interested to see what the total time and the knock on effect. So it will be how much reduction of time we're spending in Bluebeam, but then also the reduction in time in Revit, because that's obviously the reinforcement detailing.

example, that was the duplication of doing it in Bluebeam and doing it in Revit. So it's going to be a reduction in, in Revit as well. Um, but to Konrad's point around Adobe, two examples that I'll give on that. So every time we have a license renewal, I go into a BIMbeats dashboard that has every piece of software that we have that isn't a named user.

And we compare running time with active time. So you can see on BIMbeats, pieces of structural analysis software, of Strand 7, as an example. It's not used very regularly, but it's used by a wide group of people, and we've got to get that [00:43:00] number of licenses based on concurrent usage. So, what typically happens is that those users will open Strand 7 at 8 o'clock in the morning, leave it open until 5 o'clock at night.

So, in terms of our metric of, is it running on the machine, we have a and then right alongside it is how active it's been used.

Konrad Sobon: you know why they're doing that, right? They're kind of putting a hold on the license.

Evan Troxel: Right?

Konrad Sobon: If it's a floating

license solution, right? They just reserved the license. Like I remember when we used to have, you know, a couple of floating,

Evan Troxel: Mm-hmm

Konrad Sobon: couple of floating rider licenses. And all of a sudden we out and the emails start flying

through the company.

It's like, Hey, can someone give you a rider license?

Matt Wash: Exactly the same thing. So we have that in our intranet across every piece of software. So when someone does try and get into a piece of software that they can't get into, it just shows who's actively in the software and who's had the software open the longest, so that we can say, okay, this is probably someone that might be able to jump out of that software.

So there's two reasons for doing that. One is the psychological [00:44:00] impact of the frustration of not being able to get into the piece of software that we're trying to reduce that to. And the other one, just the saving of money every single month that the CFO is now like, I love BIMbeats because you are saving me money every single month on software licensing.

Sometimes it goes the other way. Sometimes when we are adopting a new piece of software and the traction is good, we're actually increasing, but we're increasing when we need to increase and we're reducing when we need to reduce. And it's based on the strategy of. Are we moving to a piece of software that we know is in the direction of the strategy of the business versus a piece of software that we're not?

So as an example, we decided that we were phasing out AutoCAD to move to Revit years and years ago. So we said, right, this is the date that we're going to do that handover. And from that day onwards, everybody that is a structural technician will do everything in Revit. And we gave a period of time where training was provided and everybody was up to speed.

But then at a certain date, to Konrad's point, we shut it off. And it's like, [00:45:00] now you're only in Revit, you're not in AutoCAD. And we have a number of engineers that would always go into AutoCAD to just have a look around the model, do a few markups, make a few measurements. And we said, right, BricsCAD, everything that you're doing, you can do in BricsCAD.

So we did this comparison of how much it was costing us in AutoCAD when they moved to named licenses. We looked at the flex token system and we ran this comparison and we have 78, 000. regular users of BricsCAD and we, I can't remember what the number was, but it was tens of thousands of dollars every year that we saved by making that switch from AutoCAD to BricsCAD.

But it did need the transition, it did need the training, it did need the

piece around if there's things that it's not doing that you were doing in AutoCAD, please let us know, but we feel that we can make that change. So, Again, it comes back to the cultural piece around, we didn't just tell people right from tomorrow, you've got to go and learn this, you know, there is a training job number or an innovation number that you can book time to that [00:46:00] you can learn how to use the new piece of software.

And I think from a financial standpoint, It's this, what is the long term objective of what we're trying to do? We can't look at this in the short term and we can't put it onto a project. So if you were on a project and your project manager says, hold on a minute, I know he's really competent in AutoCAD and now we're switching to BricsCAD, he's going to be charging to my project and my project's going to look bad.

So the structure of billing is also like very different. And I think just changing tact a little bit. But timesheets versus actual work is probably the thing that I touched on at the end of my tenure at ADG, where we were really

Konrad Sobon: Matt, hold on, hold on a second. Cause on that AutoCAD, uh, to BricsCAD story, I think you're leaving out a, uh, An important piece of information there, because this, this one touches on, um, this one touches on a piece of information that you can get by seeing, by [00:47:00] seeing actively who's using a certain software and measuring how much time the software is being used.

You can tailor your licensing strategy, right? AutoCAD didn't offer you floating licenses. BricsCAD did. part of, part of the reason you're switching over is because you have people jumping in. What you were saying is like they jump in to do a few markups for a few minutes and they're jumping off. The way flex tokens work is that you jumping in into that model for two minutes, that gives you a license for 24 hours.

You paying for 24 hours, even if you're using it for a couple of minutes. So the big chunk of savings here is just realizing how the software is actually being used. You have 78 users, but you could get away with, I think you were telling me 15 concurrent licenses for BricsCAD and you saved from, you know, I think you used to pay 90, 000 a year for your licensing of AutoCAD because it kills that 24 hour, like it gives you that token is 24 hours worth of time that people only use a fraction of it and the BricsCAD it went down to like 23.[00:48:00]

1, 000 a year because now you can float them and people use them only for a few minutes and they put them back into a pool. So just being able to realize how you actually use the software, even from just the perspective of, you know, how often or for how long of a period of time allows you to tailor your licensing, uh, decisions towards that.

And that goes with, you know, that goes for any other software out there. So like, you know, the Adobe story that I was telling, you know, that's, that's a story about how much you're using it. And then you can, you can, you know, you can be, you can safely transition people over to some other piece of software, leaving the high, uh, productivity people alone, so to speak, right?

So you don't get what you were worried about. You're like, oh, they're going to be billing all this extra time, uh, because now they're less productive. They're going to be billing into my project. They're going to look my project bad. no, we switch over people that are less productive anyway, because they're not using the software too much.

It's not going to be a big impact, but you can do other things around this. And I remember when we were at HOK and we were doing this [00:49:00] thing, um, you know, with manager Greg, I think at the time, they actually cut a deal with, uh, with Affinity, with Surf, going back to Adobe, that they, you know, we would switch over.

It's a big company, we'll switch them over, but you guys got to put someone on cold, you know, available.

All day, 24 seven, to support us. Right. So we're going to start

pooping, start transitioning people over to your software, you're going to help us with that. You know, going to get

yourself

a couple of thousand licenses from us.

Right.

Matt Wash: Yeah, no good point. And definitely when I looked at that dashboard in terms of the time that those BricsCAD users were spending in there, we'd color coded it from, you know, 10 minutes to 2 hours, 2 hours to 4 hours, 4 to 8, and then more than 8. Like, there was literally nothing more than 2 hours ever. So that 2 hours for the TokenFlex system, I think it worked out to like,

25 per hour per user.

It's like,

Evan Troxel: Wow.

Matt Wash: we can't, we can't afford to do that. So,

Evan Troxel: Right,

Konrad Sobon: And with other software, it's similar, similar story. Right. So like you mentioned Bluebeam, [00:50:00] right. There's an inherent assumption that working in Bluebeam from an engineering standpoint of view is actually being unproductive because we know what people are doing in Bluebeam. It's like, it's manual, like laborers work, um, that then gets to be redone again.

So you're doing some kind of markups and somebody else has to redo that work, in Revit or some other like altering tool, right? AutoCAD, whatever that is. Right. So. Inherently, you're assuming that that's being unproductive. You can actually measure that, right? So, like I said, some of our clients, uh, come back to us, and they're, you know, they're telling us a story where they're looking at what it is they actually, that people actually do. Do they do markups, or do they just, um, uh, do they just look at PDFs? Right, because, because now, you can open a PDF in a browser. software on any Windows machine, right? You don't even need Bluebeam to do that, So even when they do a markup that's, You know, [00:51:00] that's from an engineering standpoint of view, maybe unproductive, but from a software purchasing standpoint of view, Markups is actually what Bloomium is supposed to be used for.

And if they're in the studio session, that's actually great, right? So if they're using the software, how it's meant to be used, then that's not as bad as just looking at PDFs, right? So there's like gradations to how bad, how badly you can, you know, you need to switch people over or, you know,

retrieve licenses back or whatever.

Evan Troxel: right. One thing I want to go back to is this idea of how granular you guys can get. And you were just talking about it, Konrad. So, I mean, you're talking about using an app, you're talking about using a computer, whatever. specs are. You, you guys have visibility into that, but, but you, I, I think it, it makes sense to take a minute to talk about the depth at which you can actually see what's going on, because you both have talked about, okay, is the program just open on the machine?

Are they actually using it? All the way down to, [00:52:00] like, what are they doing in Bluebeam? So maybe you can give an idea of the spectrum of granularity that you're actually looking into on, on these machines

Konrad Sobon: Yeah, so it really depends on the application itself, right? So we have a couple of tools that generally at any software that's running on your computer. And like Matt mentioned, the, uh, the active window app that we have. So that can tell you, um, you know, what kind of software you're running on the computer and whether it's actively being used.

So how much time you're spending in it. To an extent, it can tell you, um, you know, what are you, what are you doing in it, uh, depending on, uh, like, you know, if it's a browser, we can kind of tell you which, uh, which products in the browser you, in the browser you're using, um, but it's not a whole lot of detail, right?

Like, you know, how much time you're spending at, you know, I don't know, ACC hub or something like that, right? But it's not going to be a whole lot of detail specifically of what you're doing inside of an ACC hub. That would require a specific integration, so we do have certain packages that we've been rated [00:53:00] with outside of Revit, obviously, so Bluebeam's one of them. and if that given software allows you to look into specifics of what people are doing in the application, Then we have that data available as well. So Bluebeam is one of those where you can see, um, you know, all of the actions, um, or transactions as they call them, um, that you execute in the software.

So, you know, for Bluebeam you can see, you know, every markup, every comment, every document that you, that you edit and modify, all the single actions, um, basically your mouse clicks in an application. Um, You know, we can do the same thing with things like AutoCAD, Revit, Rhino, Grasshopper. So like all of the integrations that are very specific to a software, like if you go to our website and we have a list of like specific integrations, those are the ones that we can see a lot more detail, given that the application actually allows you to dig into it through an API integration or some kind of log file that we can parse all

of

those actions through.

Evan Troxel: [00:54:00] Nice.

Matt Wash: Sorry, just touching on that further with the Bluebeam example. So, in terms of the

granularity, we have VivaEngage within, and I keep saying we, ADG. So, a knowledge sharing community where we have channels set up to, if you've done something cool and you want to share it with someone, you put it into the community.

So, as an example, someone will say, Oh, I found this really cool tool in Bluebeam. to do legends or whatever it might be and they can type it. Hey, this is how you do this thing and it's saved me a heap of time. I used to do it like this and then people will like the comment or reply back, going, Oh, I didn't know about that.

That's really cool. But inside of BIMbeats, we can see, well, how many more people are now using that tool based on that community interaction and people sharing their knowledge. So I think that's probably one component that. We hadn't dived deep into until I started doing this at an organizational level.

It was, yes, we're capturing all of this data, but what are we going to do with it? So, if you know that legend is being captured in Bluebeam, ah, well, if [00:55:00] someone's just put in the community that they're using that feature, who else is using it? So then we can create a dashboard of, well, let's have a look with inside the business, who's taking advantages of all of these different features.

Like productivity gains. And okay, well, let's run a session on that because right now that comment that was made in the Viva Community channel is only being used by five people within the business. Let's do a little session on that. And what is it? So that insight from um, Active Window. Inside of Veeva communities, we'll then start looking at, well, who's engaging with the Veeva community?

What do we need to do to create more engagement inside of the community? Because we can see who's interacting with each of the channels within Veeva communities. Um, so that's really insightful. But I, I think the other one, just touching back on time sheet data because of the active window, essentially I do my time sheet at the end of the week using my active window to look at where I actually spent my time.

And I've got two examples from clients where one client came to me and said. Um, I'm using, uh, I've got my [00:56:00] timesheet data and it's showing that this person here is 90 percent billable. So they've billed to 90 percent of their time to this billable job. Whereas this person here is, is billing 50 percent of their time to this innovation job number.

And I need to increase their utilization. They need to be back on billable work. Like, can BIMbeats help me with that? And I'm like, well, yeah, absolutely. Because we can look at exactly what those two people are doing. And is this guy automating what he's doing or trying to automate something that would be Useful on a billable project and what it turned out was that the guy that was billing an entire day to billable work Wasn't actually spending that time on billable work and some of that time was spent surfing the net.

Now Obviously, BIMbeats is not a tool that our intent is not Big Brother to check up on people, but it's worth raising because the perception of the leader of that business was that the person that was booking to the billable work was the good member of staff, whereas what was happening was the other member of staff, when they weren't busy, were looking at ways to innovate and [00:57:00] looking at learning new tools.

and on their timesheet was recording exactly what they were doing versus someone who was a little bit more fictitious about what they did at the end of the week. I found it really insightful that the comment back from this project manager was, I want to get more people like this guy who's billing to my job, so I know I'm charging, rather than this guy who's wasting his time, well not wasting his time, but spending time on innovation.

And I was just like, wow, like, once you unpacked what was actually happening there, there's So much more to that story than what you saw in the timesheet.

Evan Troxel: truth.

Matt Wash: that, that was, that was one interesting one. And the other one was around, um, a computational design leader of a business. The job was to go and look at each of the different departments within the business and look at ways of automating their traditional workflows.

And he would come in and take a job on a project and bill the time that he spent to do that task. And project managers were coming back and saying, He's not billing enough hours to the job. For us to, [00:58:00] on charge to the client. So, like, if it takes you two hours, can you make sure you book what it would normally take you to do that task?

Because we're billing by the hour. And it was like, hold on, hold on, hold on. Like, this is crazy. You're almost saying, can you slow down? Because if you're doing these things more efficiently and more effectively. It's not looking good for us in our traditional way that we bill for the work that we, we, and I was just like, okay, there's two really interesting examples that I'd never, ever thought I would end up having to unpack through Bimbeats.

And like, obviously that then comes back to, you know, the whole charging model and, you know, are we billing on value versus billing on hours? So that's, that's a whole

Konrad Sobon: Yeah,

Matt Wash: complete new,

new topic, that one.

Konrad Sobon: it always makes me laugh when, when clients, I think you were telling me about the, I never even knew the software existed, the jiggle software

Matt Wash: Oh, yeah.

Konrad Sobon: So some, some people run that on, uh, on their computers

Matt Wash: I [00:59:00] think the int

Evan Troxel: a

Konrad Sobon: just to make themselves look alive.

Let's take a short break from the conversation to invite you to join the most influential technology leaders in the AEC industry at Confluence. Composed of in person events and a podcast co hosted by yours truly, Confluence is designed to foster conversations between AEC firms and technology companies so they can learn, share, and engage with each other to support industry innovation.

Evan Troxel: Software company Avail, which creates content management solutions for the AEC industry, started hosting Confluence events in 2019 to understand what firms are needing, wanting, and thinking around technology. To learn more about Confluence, explore upcoming events, and listen to podcast episodes, go to confluence.

getavail. com. My thanks to Confluence for supporting this episode of the TRXL podcast. And now, let's get back to the conversation.

there's a way to game it, somebody will figure it

out, right? And [01:00:00] imagine the conversations going back to those people who are trying to do something innovative or actually tracking their time right, and like delivering this message to them and what it does to their morale, right?

It's like Like, there's that level of this too, right, that it ultimately gets down to, and then all of a sudden that person's looking for another job, right, you just took, like, the person who's actually doing the thing, Konrad's raising his hand, that was me, right, they're actually doing the right thing, for the right reasons, and, and they're getting punished for it, right, uh, it's, it's absolutely incredible, and people wonder why, you know, The top talent doesn't want to stick around in, in,

many cases, right?

It's like, well, right there, there you have it.

Matt Wash: Yeah, no, it you, you're spot on. And, and that's why

just before I left a DG, we, we now have the time sheet data with the Bimbeats active window data and that project manager or a project manager can look at what was billed versus what was actually [01:01:00] worked on. So it's very, very clear between the two, you know, what the time sheet says and what was actually done.

Evan Troxel: Konrad, do you want to tell your story? You raised your hand like you, I know you were just saying, yeah, yeah, that

Konrad Sobon: But this,

Evan Troxel: but

Konrad Sobon: yeah, I mean, it happens to a lot of people, right. I

Evan Troxel: yep.

Konrad Sobon: guess. The problem is with that billing model, right? I mean, that's just not sound like, I mean, I understand why managers would look at it this way, right? I mean, their project, the people that work on their projects need to bill for their projects, the full amount of hours that they allocated. Um, cause that's, you know, that's how you invoice the client and that's. That's how you get paid. So people like us that we're technically overhead or people like us that, you know, built to an overhead, you know, design technology project number, we're not always welcome. So it's hard to measure, um, it's hard to measure the increase in [01:02:00] productivity, you know, when you're working on something that's going to automate a task, right?

It's just, know, it's just one of those, uh, it's just one of those things that you just You know, it's helping, you just have to take to take the other person's word for it.

Yeah, and that, yeah, but I, I've definitely lived through that story

Evan Troxel: Yeah,

Konrad Sobon: where you asked to build to a project, proper project number. um,

not some kind of research project number.

Evan Troxel: I think that this topic overall just really dovetails nicely with an episode that I did recently with an old colleague of mine around the idea of dedicated technology training in a firm. And you guys have mentioned the term a few times, digital footprint. it, it's like we're getting more and more to the point. where like that's the only footprint that we're actually measuring, right? Like it's, it's all digital all the time, all the tools. I mean, of course, there's the human resources side of things. And there's, there's all, there are other parts to a business, of [01:03:00] course, but so much of the business of AEC depends on the digital. Right? Like a hundred percent, And so, at some point, we don't call it digital footprint, we just call it footprint. Just like, I think at some point, you don't call it digital practice, you just call it practice, right? It's like, it's so obvious, I think, to people like you guys, who are working in this every single day, that like, this is how we do it, and it's the only way that we do it.

We're never going back to an older way of doing it, and this only progresses forward. So, dovetailing into this, Training idea. I'm just curious from your standpoint, how often are you guys, you know, because we talked about the struggle of implementation, and I'm curious from your standpoint with a view into many different firms. you could kind of give an overall health metric to the, firms that are out there that are actually are proactively taking it upon themselves to train their staff for new workflows, for [01:04:00] new ways of doing things, for getting rid of the problems that you are identifying with tools like BIMBEATS, where it's like, well, man, there's way better ways to do this to your, to the communities example that you were talking about, Matt, right?

Where it's like somebody posts a tip and then you can actually see. If people are, you know, first you get like kind of the thumbs up responses to the tip and then you get actual usage of, okay, there's a new way to do this. That was way better than I knew because a lot of times it's just people don't know what they don't know.

Right? So from your standpoint, kind of a window into different firms. Where would you kind of grade us on a scale, I don't know, A through F, let's just even say, or 1 to 10, of, of, training their staff so that they are progressing, so that they are developing professionally, but also raising the level

of

what's achievable in these businesses.

Matt Wash: I guess the short answer to that is that. We're 1 to 10 and A to F, and there is no [01:05:00] middle ground or there is no kind of happy medium. I think there are companies that are doing it really, really well, and I think there's companies that aren't addressing it at all. I think a lot of people think that having Bimbeats in solves all the problems, and that just by having it, all the problems go away, and that that training component isn't necessarily a problem.

as important as they thought it would be, or the additional work that's required. It, like, BIMbeats is not you put it into the system and everything magically improves. Like, it, it still needs that training component. Um, I would say that, For BIMBEATS, us partnering with organizations that provide that training is probably something that we should probably consider because that isn't something we do, and then if that training is effective, then BIMBEATS is a mechanism for measuring.

that effectiveness. So if companies are worried about the amount of time it takes or the investment in training, I guess there's the investment in software and new software, there's the investment in training, but then [01:06:00] it's that, well, measuring what was the effectiveness of the training, like, are we actually improving based on whatever that training is?

So if we take the example of in place families, you can go to the BIM Beast dashboard and say, right, these people are the most frequent. Uh, in place family users. These people are in the interiors team. They probably need some training with loadable families.

Evan Troxel: Matt. Get specific.

Matt Wash: It's not like, it's not like it's a true story.

This is,

Konrad Sobon: names.

Matt Wash: know,

this, this, this, yeah, like, so,

Evan Troxel: I'm talking to you. I'm talking to you, Konrad

Matt Wash: but

the, but the bit, the bit that we don't do is then have that automatic, well here's the training you need to do to improve on that thing and then come back to say, well okay, you're no longer doing in place families or the reduction of in place families has come down.

So I think we rely on the training component within SiteEach. And I think it comes back to looking at short term financial success versus long term health [01:07:00] of both your business and your bottom line. And I think a lot of people get scared by the upfront investment that's required because it isn't a quick fix and it does take time to embed that into the culture that this is about continuous learning organization, etc, etc.

I think a lot of people say that's what they do. But I think. a lot of the time it comes back to, it takes more than just capturing the software, providing the insight, the action, really comes back to training, um, for competency, uh, and increasing the skill set of the individual. I think to a point, um, Nerva, who was on your podcast a while back, said,

Evan Troxel: Mm

Matt Wash: um, the difference between innovation and evolving.

I think sometimes I possibly have made the mistake in, Continuously talking about innovation and people believing that that's a nice to have or only, you know, a small part of the business does this. And I think it needs to change to the language needs to be it's, well, this is evolving. This, this is an evolution of every role.

It is not a design technology groups job to do [01:08:00] this. This is the future of an architect. The future of an engineer is complementary digital skills. That's what it is. And, and it's not, we have an innovation team that does that and we have an architect to. is creative. We have an engineer who engineers. We have a technician that draws or models.

Like, I think those lines have got to blur, and they are blurring, um, particularly with the, the ability to adopt new technology and how much easier it is now than it, than it was before. So I think that's, that's really important, that training aspect, but in answer to your question, 1 to 10 and A to F, like it's, it's really across the entire board.

Konrad Sobon: So one more thing I want to expand on, um, a little bit when it comes to training, cause I remember again, back in my BIM manager days, I was responsible for, um, and I remember doing this regularly with, with staff in the office, uh, when we were training people on, you know, Revit is an example [01:09:00] at the time, right?

We were Just, you know, we'll grab four or five people that were on any given project, pick a topic for that day. know, keynoting today, or, you know, you mentioned in place family modeling and like good practice for family modeling, or parametric modeling, whatever the case was, right? And you put them in the training room and, you know, talking through a topic and then they go off. A couple of things that was, that was bothering me ever since then that was wrong with that image that kind of, you know, right now with BIMbies you can, you can vastly improve on, right? So first thing is, A, we're just blindly training everyone, right? People that are actually really good with, with Revit already knew, Those things, there was no need to waste their 30 minutes or an hour of their time by putting them through the same, same training session, right?

So, like you were saying, now you can see specifically, you can run through the entire and see who is making in place [01:10:00] families on a regular basis, right? Pick top 10 of those people in the organization, organize training for them specifically, right? And that's the difference. You're actually training where there is a need to be trained, right? then the other side of this is those people were now trained, you know, you know, when that training occurred, can track the progress from that point from that day forwards, they actually changing their behavior? If they're not.

Bring it back into the training session until it sticks,

Evan Troxel: off that license.

Konrad Sobon: kill or kill that license, but so, so it gives you to, you know, that upfront, you figuring out and you not, so it wasn't just like, I would run through separate specific topics that I had, but there were the same topics and with every team, I just kind of ran through the same thing over and over again. if in place families were never a problem? And I just kept training everyone on.

in place families. I would, I'd never even knew [01:11:00] if that's what they needed to be trained on.

Evan Troxel: measure something in order to come up with a strategy to address it. Right. It's

Konrad Sobon: Yeah. Yeah.

Evan Troxel: have the ability to do. And I think something that

Matt, you said earlier was like, everybody read these gems. Right. And, and it's like, you gave it the special thing, this designation on the internet. And it was also probably just like a really short and to the point kind of a thing. And again, like, think about people's behavior, think about their attention span. And. I also think about the preciousness in which a lot of training material is created and it's like polished and it's edited so perfectly it doesn't have to be like that.

Like it literally, I think, in order to be effective just needs to be done fast. And, and, don't try to solve everybody's problem. Don't try to explain all of it. leave room for that engagement part that I talked about earlier. Ask questions afterward, ask follow ups, where do we, and then we can decide where we want to go next with this, but don't [01:12:00] be super precious about creating this content, but I do think you need to create.

Training material that lives somewhere so that people can look it up when they need it, because live training doesn't work all the time for everybody. It's not always the right place, not always the right time. And, and I think, you know, a lot of our business is like that. Like, we're just filing stuff away, waiting till the day that we use it, but it's still nice to have those resources. In addition to that, that maybe aren't so precious, but they're timely because they're there when I, I just need to look things up and figure out how to do things better. Or somebody posts about it and says, man, this worked for me. here was a quick screen recording, like. Run with this and just see what happens, but I think I think all of these things kind of lead to like it's it doesn't even sound like effective training, but it totally is effective training.

This is how people consume media these days, right? It's like the doom scrolling. It's just flipping through videos. And if you have the ability to do that in your organization with training, like that's a valuable thing for people to be filling their brains with when they're when they're

out looking [01:13:00] for. You know, trying to fill a little bit of time.

Matt Wash: Yeah. And, and I think with this podcast, it's going to be interesting if I talk to clients saying that we've done this podcast to then look to see who listened to it for the entirety and who listened to the first 10 minutes

Evan Troxel: Bimbeats analytics on the

podcast listeners. I love it.

Matt Wash: walked out after 10 minutes because the attention span was too short.

Evan Troxel: Impossible. You're way too engaging, you guys. Well, and, and back to that point, like, like delivering, like, this is very conversational. It's like, I'm not doing a monologue and there's no agenda to this podcast, right? We, we literally don't know what we're going to talk about next. I've said that many times on this podcast.

I don't know the next words that are coming out of my mouth and you probably don't either. And I think that alone makes it way more listenable because it's authentic. It's a conversation. And actually that now that reminds me something that you were talking about, Matt, and I think we can wrap up. With this was just this whole idea of accountability in the system, right?

It's like you, you identify the problem, you [01:14:00] produce a little bit of training, and then you watch and you see if the behavior is changing. And kind of going back to maybe, you know, when I was a BIMbeats customer at HMC, right, back in the early days of BIMbeats, and it was like, just getting the software is not enough.

Okay, now we, we identify these things and now we go proactively to people and we say, hey, I noticed that this isn't working for you. How can we help? Um, that to me, built, starts to build personal accountability because now that we've addressed it, now we're going to be checking in on it. Right? And in the organization, like, as a business, we're not a family, like, have accountability, and they're not a business, are not, like, my son is not responsible for doing business development and bringing in money every month, right? But there's accountability there. It definitely should apply in the business. Right? And so when it comes to like spending the money on the software, spending the time to do the [01:15:00] training, following up on that, making sure it's actually landing and working and we are getting better at doing what we do should be totally normal. And I think like that, it's just kind of a call to action to, you know, a lot of, there's a lot of people who work in these businesses who want to see accountability, but it's so hard to get that to actually happen. Um, and I just wanted to bring it up, see if you guys had any ideas around that, because I, I do think that you're building a platform that enables accountability, right?

I don't know how. That's actually working out. I'm sure it's working. Again, it's probably all across the spectrum, right? Uh, there's some that are really good at it and some that are really bad at it. But, that is a, it is something to, to really take notice of and, and, and learn how to use that leverage in the business

to make, so that things actually do get better over time.

Matt Wash: Yeah, I totally agree. And I'll go back to Nate's article that he published this morning, uh, where he talks about the accountability isn't just on the tech [01:16:00] people or the person that is responsible for innovation within a business. Like, that's not enough. And I think it's 84 or 86 percent of digital transformations fail.

And I think it comes back to that accountability where, yes, the accountability for the strategy sits with the tech people. The Chief Digital Officer. Executing that strategy is the accountability of everyone within the organization, and it has to be both bottom up and top down. And I think quite often the bit in the middle gets missed.

I think at kind of leadership level and C suite, you come up with what you think is a business strategy that aligns with your digital strategy, and everybody is in agreement with that. You have young, passionate people at an individual level who want to do it. But then the project directors and the national discipline leads who have all these other things that they have to worry about and, you know, but essentially all of this still comes back to commercial gain and commercial gain, whether that is retaining someone that hasn't left the business and the cost [01:17:00] of retaining them.

Like getting someone else in. If someone leaves for me, everything still comes back to a commercial benefit to the business, but it's, and, and this is probably a good, good, good way to finish. And this comes back to what we spoke about last time, Evan, about it's the health of the business and the health of the people.

And if you've got healthy people, you have a healthy business.

Evan Troxel: Well said. Conrad, any, any final thoughts when it comes to this? Thanks.

Konrad Sobon: Yeah. I mean, so you guys, you guys said a few times that, you know, you get the data, but it's up to you what you're going to do with this, right? So this transparency, um, cuts both ways, right? So there's, it's,

you can do positive things or you can do negative things with it. You know, and often, oftentimes in some of the examples that we've had with, uh, that I've seen with clients, some of the stories they tell us is, you know, people get used to it, right?

It's, you know, it might feel like, um, you know, it's a little, [01:18:00] I don't know, a little too much in the beginning, but I've had some clients tell us that, you know, they had this, uh, They had this workflow set up where IT was getting emailed with a list of computers that need to be updated because they're on the outdated version of some software or whatnot.

They were, and they were getting these automated emails from BIMbeats every, um, every week. And originally they would get. a little annoyed, a little pissed off in the beginning because it's like, hey, you just keep sending me this stuff. I know I have to do this, but, but that, you know, over time they got used to it, but it created that accountability that we just talked about, right?

It's like, yeah, you're not going to keep getting those emails if you actually get out there and, uh, you know, get those updates pushed out and, know, get used to it, right? So it's not, um, I'm actually only, uh, personally, I think that, um, You know, that you can, you can throw more responsibilities at people in there.

Um, that's a good thing. You know, they usually respond in a very positive way. so, [01:19:00] having, having that kind of data, having that kind of information that allows you to, expect and demand more, uh, from people is a good thing. That's a positive. I like to see that, you know, the companies that I worked at back in the days.

Um,

I'd be excited.

Evan Troxel: Agreed. And I, I think it, it, uh, obviously people want to show up. I, I mean, I shouldn't say obviously, but I think most people show up and they want to do a good job

Konrad Sobon: Yeah. Yeah, exactly.

Evan Troxel: how they can do their job better. And so kind of

going into those conversations with that attitude and just saying, Hey, like I noticed this and this is a struggle.

Yes. No. Like, give me some feedback. Tell me what you're, what, what this is like for you. Yeah. That's a great way to enter into these conversations, right? Give them the benefit of the doubt, of course. And I know a lot of people, there's definitely IT people out there. I mean, there's people You blamed the interior designer for making in place [01:20:00] family, so I'm blaming the IT people for the way they approach conversations sometimes.

Like, Konrad, you even talked about this with your role emerging and evolving through time. It's like you, you, you You had to deal with people in your role at BIMbeats, right? And it's like, Oh, how do I do this? Right? It's, it's not natural necessarily for people on the technology side to, for communication skills or for interpersonal skills or soft skills or however you maybe want to put it.

And there's, there's training out there for that too. You can learn those skills. And so I think just saying a few of those things out loud, it's like, let's just actually step back and remember, like, people do want to do a good job. Give them the benefit of the doubt. Let's all get better together kind of a thing.

And, and understand your purpose in this business. Like getting, getting back to this business use case that we're all on the same team pushing forward. I, all of those are kind of like regrounding kind of. You know, maybe cliches, but at the same time, like, I think it's worth saying those [01:21:00] because I think a lot of times some technology people lose sight of those things and they just go in guns blazing and they, they, you know, they're because they're fed up and, and they've keep having to deal with the same things over and over again, or they're only dealing with the crap, Konrad, right?

Like all I get are bug reports. All I get are the negatives. Um, and so like, let's just remember like people that is, talking about people we're talking about. People who in architecture generally are up for a challenge, like you were just saying, Konrad's like, man, I, you want to start every day with a little challenge, right?

And, and get your brain working. So all of those things, I'll get off my soapbox now, but I think those are all we're saying, you know, especially if you're in a leadership position, like to really instill in your team, who's going to be having these conversations with people as well. Like, treat, treat people with respect, treat people as people, and, and, and build accountability the right way.

right?

Not just the guns blazing kind of a way.

Konrad Sobon: Yeah, presenting these things as opportunities and, you know, [01:22:00] just being able to recognize them afterwards too. That's like an important part of it too. Like people will step up to a challenge, they'll try to do a good job. That's, that's, I don't know, that's like a default mode of operation for, you know, with the folks that I used to, um, work with.

And I believe that's, that's how most of the people are. Uh, but you have to be able to recognize them afterwards too. So,

Evan Troxel: Absolutely.

Konrad Sobon: so long as you're doing

that. They're going to be, they're going to be just, fine.

Matt Wash: I just, sorry, I just wanted to end on one thing just because it made me think about the hybrid work situation and flexible work of should we be in the office, should we be at home? And I don't have the answer to this, but I want to give a shout out to Havad, um, because Havad put me on to a book called Outcomes, Not Outputs.

And I think if we look at that, then using BIMbeat's data and anecdotal evidence as well, that measure on outcomes, don't measure on outputs. Like, because there are stories of [01:23:00] you're working from home. You're only doing six hours a day today. You're not doing the eight hours when you come in the office.

Who cares? What's the outcome? And I think we need to move forward looking at outcomes, not output. And it probably relates back to that booking two hours to the job rather than six hours because you did six hours worth of work. I think focusing on outcomes needs to be the way that we, we move forward. Um, and if you're judging hybrid working, judge on output.

Oh, sorry, Outcomes, not Output.

Evan Troxel: Yeah, it goes right back, another dovetail into our previous conversation, Matt, right? Healthy people, healthy business, right? So, well, thank you both for taking the time to catch us up on what's been going on with Bimbeats, and it's been a wonderful conversation. I hope we can do it again in the future.

Let's not wait four and a half years, Konrad, till the next time. But, Matt, congrats on your new role. I hope you can do wonders with, uh, with scaling Bimbeats, and, uh, I wish you both the best. Thanks for

taking the time to [01:24:00] hang out with me​

The architecture, engineering, and construction (AEC) industry is evolving rapidly, and staying ahead requires more than just keeping up—it demands active participation in shaping the conversation. TRXL exists to accelerate this evolution by bringing together thought leaders, uncovering emerging trends, and fostering a dialogue with the people pushing our industry forward.

TL;DR

TRXL+ Paid Membership: Support the Future of AEC

The AEC industry is evolving fast, and TRXL is at the forefront—bringing thought leaders together, uncovering trends, and driving meaningful conversations.

Why TRXL+? Your paid membership fuels:
✅ In-depth, ad-free podcast episodes with industry leaders
✅ Thought-provoking Leadership Edge newsletters
✅ Directly contribute to sustaining independent, high-quality conversations about architecture, technology, and innovation.

By joining TRXL+ as a paid member, you’re directly supporting independent content that shapes AEC. Ready to be part of the movement? Become a paid member today.

The Value of TRXL+ Paid Membership

TRXL+ is more than just a membership; it’s a way for you to directly support the ongoing work of assembling the bigger picture. Members aren’t just paying for a single piece of content—they’re investing in a continuous exploration of the ideas, technologies, and strategies that define the future of our industry.

How TRXL+ Fuels Industry Evolution

The work I do on TRXL is expressed in several ways:

On the TRXL Platform

• Podcast Episodes – Long form, in-depth conversations with industry leaders, innovators, and disruptors. Podcasting provides the unique opportunity to make these conversations public and accessible to all.
• Leadership Edge Newsletters – Thought-provoking analysis and insights that provide clarity on the shifts happening in AEC that are exposed through conversations on the podcast.

Beyond the Platform

• Speaking Engagements – Bringing these discussions to industry events and conferences.
• Advisory Roles – Helping companies navigate change and implement forward-thinking strategies.
• Industry Event Coverage and Participation – Engaging directly with key players and sharing insights in person.
• Collaborations with Brands and Companies – Connecting AEC with industries outside our own to spark new ideas and innovation.

Your Support Makes It Possible

By becoming a TRXL+ paid member, you are directly contributing to the creation of valuable content and the ongoing dialogue that drives the industry forward. Your membership enables:

• More high-quality podcast episodes featuring the people who are shaping AEC.
• Deeper research and analysis for Leadership Edge newsletters.
• Increased presence at key industry events to bring real-time insights.
• Expansion into new collaborations and content formats that accelerate industry-wide impact.

Join TRXL+ Today

If you believe in the power of storytelling, insight, and connection to drive change, TRXL+ is for you. Together, we can build something that not only benefits our community but also accelerates the evolution of AEC as a whole.

Become a TRXL+ paid member and be part of the movement.