Ron Heims has spent his entire career at RDG Planning and Design, moving from architect to IT director to his current role as Director of Practice Innovation. It’s a role dedicated to a question many AEC leaders are sitting with: who is actually responsible for making the firm better at how it works?
In this episode of the Smarter by Design podcast, Christopher Parsons talks with Ron about what a practice innovation program looks like from the inside. The conversation explores how Ron discovers and prioritizes innovation projects across a firm with too many good ideas, how he uses process mapping to diagnose undocumented workflows before any technology gets involved, and how he brings people with competing opinions together to build consensus around a better way forward.
Ron also explains how RDG decides when to buy software and when to build it, and how he and his team have developed a suite of custom tools tailored specifically to RDG's workflows, including a project management platform built with agentic coding tools that connects project teams to RDG's Synthesis intranet knowledge in the flow of work.
A big part of what makes the innovation program work is what happens after a tool gets built. Ron talks about his approach to change management and adoption, including how he keeps early adopters close, responds to feedback quickly, and creates the conditions for people to actually want to change how they work. Building better tools is one challenge. Getting them adopted across a multi-office firm is another problem entirely, and Ron has learned a lot about both.
If you lead or manage an AEC firm and you sense that someone should be focused on innovation on a more dedicated basis, this episode is for you.
▶ Watch or Listen
Watch or listen to this episode via YouTube, Spotify, Apple Podcasts or wherever you get your podcasts.
📺 🎧 YouTube
📺 🎧 Spotify
📺 🎧 Apple Podcasts
📚 Show Notes + Resources
Heims, Ron. "Low-Code, High-Impact: Solving Real Business Problems with Custom AI Apps" KA Connect 2025.
📃 Episode Transcript
This transcript was lightly edited for clarity.
Chris: You are Ron Heims, Director of Practice Innovation at RDG Planning and Design. Welcome to Smarter by Design.
Ron: Thank you. I'm excited to be here.
Chris: Yes, we've known each other a very long time at this point, pre-Knowledge Architecture, actually. So it's fun to have you here on the pod.
To that end, I'd love to talk a little bit about your journey from being an architect, and then an IT director, and now a director of practice innovation. How did that happen?
Ron: Okay. My degree is in architecture from Iowa State University. When I graduated from Iowa State University, I got hired at RDG, where I still work. I was hired, I think, largely because of my technical skills back then in the world of transitioning into AutoCAD.
When I started at the firm, our Des Moines office only had about 25 people. We had three Sun SPARCstations, and I came in helping transition us over to Windows PCs with AutoCAD, because we could buy a lot more for the same amount of money. So as I came in, I was researching technology. I was always interested in the technology side of things.
For about four to five years or so, I was really managing all the technology for the firm, as well as teaching and educating people on AutoCAD, and doing architecture work, all together. And after about four or five years, it became evident that either we had to hire someone to do technology or I was going to transition and do it.
So I thought about that a lot and decided that I wanted to take a slightly different route than most people do through our profession, and transitioned to overseeing the technology for the entire company at the time. And so I grew in that role through managing the technology and becoming the IT director overall.
And then, oh, it was probably 2022, I think, when we went through a reorganization internally as a company through some merging of different positions. And at that point, I also wanted to make room for some of my staff that I'd grown on my team, and we transitioned my role to director of practice innovation. So we handed the IT side of it off to Adam, and then I became the director of practice innovation.
Chris: Okay, so what is that?
Ron: The director of practice innovation is a role that is about innovating process. As IT director, I did a lot of it too, but as IT director, I really managed servers, hardware, software. But I also did innovation, bringing in new technology, new systems.
When we transitioned this role, those more hardware- and software-based responsibilities went to Adam, and then my role became more about looking at process. I work a lot with project managers. We work a lot with our QA team and our design technology team, looking at how we can improve our processes to streamline how we work, and allow us to have tools that are better and get more done.
A lot of that really rolled into data quality, too, because we see the value of the data that we have on our projects that we aren't always very good at collecting, and being able to manage that, use that, and then help our company make better decisions based on that data.
Chris: I can clearly understand the line between you and Adam, and traditional technology. How about design technology? Because that feels like it gets mixed in with process and innovation.
Ron: It does. So design technology is a key part of my team, in that we work together a lot, and we work a lot with IT as well. But design technology really does fall into design process and performance. So it's kind of a gray area when you go between Revit and Bluebeam and all these different tools, as well as the hardware and software side, I guess, or the server side. So DT, design technology, is really integrated with the practice innovation team.
Chris: I'm assuming you haven't worked on a project in over 10 years. Is that a fair assumption?
Ron: I have from the standpoint of the data side, but it's really just more like building Power BI dashboards for data we have. So yes, I haven't really worked on projects in a long time.
Chris: How is that? Because I've talked to people about this before. You're helping people innovate practice, but having not worked on projects, do you find that that helps or hurts? What's been your experience with that?
Ron: It can be a detriment from the standpoint that when you're not doing all the different things day to day, you don't understand what the pain points might be. So you just have to listen a lot, I guess, and ask a lot of questions in the process.
And we'll even use process mapping when we go through to understand the flow of data and the flow of process, and that helps to get that information from the people that we're working with.
Chris: I'd be curious to know some of the more recent innovation projects you've worked on, and maybe we can just talk about process mapping and your whole approach to innovation.
Ron: Okay. So, some of the more recent innovations we've done: I spoke about one last year at KA Connect, which was the receipts app. It was just a process that was really broken within our company. And that wasn't necessarily project management, but it's something that really hit a lot of people.
So in that case, quite honestly, I'd had the idea to build something like that for quite some time, because the chore of getting your receipts from your company credit card to our accounting staff was always a pain, right? People would email them, or they would hold them in a folder or envelope or whatever, and then turn them in and try to match them up to projects.
And then you realize that we have the tools with the mobile apps that we can build today to just integrate that with our accounting system, so you can pull a project number that's active, add it, take a picture of a receipt, let AI do the work of uploading the data, and then submit it, and it's out of your hair. You don't have to think about it.
And that app, when we launched it, just took off really fast, because it made everyone's life easier, from the person submitting the receipts to the accounting staff, all the way through.
Chris: So for someone that didn't attend KA Connect last year and hasn't seen your talk, why are you building a receipts app and not just buying something off the shelf?
Ron: I think it's making the process as simple and intuitive and painless as possible. We actually had people that were using some other platforms, and one of the guys that I had test it was using another platform. His comment to me was that using this receipts app that I built, he was able to save about two or three hours a month.
Mostly because the other platform wasn't integrated, right? He had to take his projects and upload them into this other platform, and then he had to enter his stuff in there, and then he had to export it out and put it in a spreadsheet to give to accounting, because accounting couldn't see it.
So I think what makes it really valuable is that we're integrating with our accounting system. Our accounting staff can see the data pretty much instantly once you've uploaded the receipt. So it just took the friction out of the process.
And because it was so easy to use, people use it, versus, "Oh, I'll get to that later, because I've got to go look up the project number and then put it in the system and then put in the data and track it all down." So when it became simpler and easier, people just started using it very quickly.
Chris: Yeah, simpler, easier. And the integration, I think, is what you're saying is the key part.
Ron: Yes. Totally.
Chris: Is some of it also that you could build only the exact features and functions that RDG needed? Whereas when you buy commercial software, they have to cover a wide range of markets and user types.
Ron: Right. Yeah, I think that's what makes it so valuable: it was customized to just our project list and the 10 different ways we categorize our receipts in our accounting system. You take a picture of the receipt, and then the AI tool reads the receipt and fills in the name, the amount, the date, all that for you.
So it was very customized to ours, and I was even able to build in a favorites list, which basically pulls in only the projects that are on the person's timesheet, because that data is in Deltek as well, so they have that list right in front of them.
So yeah, it's because it was totally customized to our process specifically, versus having to try to shift our process into somebody else's tool that had way more than we needed.
Chris: So for somebody listening who's saying, "Okay, cool, you're building apps. We don't have that capability." And this was pre-Claude Code that you built this, or any of these new agentic coding tools.
Ron: Yes.
Chris: Can you talk about how you were able to do that as an architect turned technologist turned director of practice innovation?
Ron: Are you talking from a platform standpoint?
Chris: Yeah, from a platform standpoint.
Ron: Okay. So I had actually had the idea to do something like a receipts app a long time ago, because I had tried several different platforms over the years. I had tried about five or six different platforms to build it in, and nothing could do it the way I needed it to.
And then I was trying to build a different app one day, and again, I tried that in several different platforms. And it was interesting, because I was building the app, and I couldn't do something as simple as putting a dollar sign on a field that should have a dollar sign. And I was so frustrated that day, I was like, "There's got to be a better way."
I just went out to the web and started searching again, and I came across the Glide platform, which we've used to build that app and several other apps internally. And I was able to build the guts of the receipts app in less than a week, and then we've improved it a little bit since then, because the platform had all the key pieces I needed. It had an easy, simple interface, it had the ability to integrate with external databases, and it had a simple way to post or publish a web app.
So I found that platform and was really impressed with it. I've built several different apps in that platform, and it's been a really solid platform for us from the perspective of the needs that we had.
Chris: So if I said the reason it's possible for you to go so fast is that you found a low-code, no-code platform, but you understand the business process. You've done the process map, you understand the pain points. So you're just dragging and dropping components to build an app with the screens and the UI that you need, branding it according to your firm, and then publishing it. It's more like assembling a kit of Legos. Is that a fair summary?
Ron: Yeah. That is a fair summary. Because it integrates well with platforms, and it is low-code, no-code, so you don't have to know how to write the code. Once you learn how to use their platform, it's pretty simple.
Chris: I'm guessing, though, the integration was the hardest part of that for somebody who isn't a programmer.
Ron: Yes. Because you've got to understand databases, and database synchronization is what we used.
Chris: That was a great example of how you're working and the tools you're using. What does a typical month look like? Are people coming to you with inbound, like, "Build me something"? Are you going out and doing listening tours? How are you finding projects, and then how are you prioritizing where to spend your time?
Ron: When I went into the practice innovation role, I basically started meeting with different groups of people. So we had a project management group that I'd meet with. I'd meet with the QA/QC group, and with the design technology group, and we would basically go in and say, "How can we make our processes better?"
So it was really meeting with groups, and we would brainstorm about ways to make our company better and our processes better, and then we would prioritize from there what we wanted to do or build, and then we would go and work on building that and putting it together with a team of people.
Chris: How do you make decisions in terms of what gets green-lit and what stays on the back burner?
Ron: I think part of it is that through leadership, we will talk about the different things that we've thought about. I am the kind of guy that likes to jump in and get my hands dirty. So I love to tinker and play with things and see if I can create something. I love just going in and learning and creating something, and then running through testing ideas and thinking, "Okay, this really could work." So I will see if I can take that further.
But from a group standpoint, we would literally try to prioritize what the group's needs were and what the biggest pain points were for those different groups, and then talk with leadership about that and prioritize from there.
Chris: Do you end up doing design research around the process and building a prototype before you make a go/no-go decision? Or do you decide before you even spend any time researching?
Ron: It depends on the project. Some that are smaller things, I may just jump right into, but for other things, I will build a process map, right? So I'll use a whiteboard technology, and I'll literally sit down with somebody and walk through it, like, "Okay, what's the first thing you do?"
And we'll walk through it several times, because many times you get a real general version first, and then you've got to get a more detailed version down to the individual steps. So laying that out, I think, was really valuable from the standpoint of knowing where the repetition happens, where the double entry of data happens, where the pain points and the frustrations were.
Literally mapping that out onto a whiteboard has been very valuable, and we've done that on many of the different tools that we've built.
Chris: I'm curious about that. You said you do multiple passes. Is that multiple passes with the same person, or does that mean multiple different people?
Ron: Both. Some of the processes that were a little smaller, I would literally map out and sit down with the person, because as I went through the first time, you feel like, "Okay, I don't feel like I got everything," right? And so we'd go back and have them review it, and then review it again with them and go through it.
Other things, we'd do with a team of people. So we'd have a shared whiteboard, and everyone could put their information into it and share how they were doing it, and then we would just refine that down to a simpler process that worked for everyone.
Chris: Yeah. So what's interesting is what's going on here, in addition to you building software, is you're having to get people at RDG aligned on what good looks like and how we're going to work, right?
Ron: Yes.
Chris: Because people might have seven different processes for doing a project management task, and you have to say, "We're going to agree to consolidate." Yeah?
Ron: Yes. That is probably one of the biggest challenges of this role, because you do find people have their ways of doing things, and bringing that together to get consensus on how we can do it better is really valuable.
In fact, in about the last year and a half, we really kicked off a process within our company for project management improvement. And one of the reasons we did that was because we were getting a lot of feedback from our younger staff that would come in and work on one project, and they were like, "Okay, I've got this all figured out." Then they would jump to another project, and they were totally lost, because the project manager did things totally differently.
Chris: That's only an RDG problem.
Ron: Yes.
Chris: I'm just going to let you know that that is...
Ron: Okay. I figured that was the case.
Chris: I've never heard that exact story before.
Yeah, and you're multi-office, right? So that's another wrinkle on it too.
Ron: Yes. Yep. We are multi-office.
Chris: So did this really truly come from younger staff? You're hearing feedback like, "Hey, I'm going to different projects," and so in order to make their experience better, you have to go a level up and standardize?
Ron: Yeah. I mean, it was from that, and also just from knowing that there were no standard processes in place. We obviously knew that, because everybody does things their own way. But we did hear from younger staff in some of our employee surveys and things like that.
So we said, "Let's see if we can solve that problem and make it easier for our staff to be able to change between different projects or different project managers."
Chris: So what were some of the things you were tackling? Because obviously project management's a big ball of things. So how did you get started trying to simplify?
Ron: So we kicked off a team of people through an initiative we call Project Pando, based on the Pando tree, which has interlocking roots underneath the ground. And so we basically pulled a group of people together to talk about what we could be doing to make things better.
And really we started off with something as simple as, "Hey, you've got to understand your scope and share that with your team. You need to establish roles and responsibilities on your projects." Because we've got people that come onto a project, and they don't understand what they're supposed to be doing, because the project manager didn't communicate that with them.
Chris: They just start giving them tasks, but they don't understand the bigger picture.
Ron: Exactly. And so we've gone through a whole process of defining what the different roles on the project are and what the responsibilities are for those people, and now we're building that into tools so that people know those up front.
Then one simple thing we got to was project schedules. People didn't understand the schedule on the project, when the deadlines were, and when the milestones were.
And so, interestingly enough, one of the first things I built from that standpoint was just a spreadsheet that did a simple Gantt chart, but it had formulas in it to make it halfway automated. And people loved it. It was one of those things like, "Oh, wow, this makes my life easier, so I'll use the tool."
So we did that, and we got into even things like, "Hey, you need to have regular team meetings. You need to have design reviews. You need to have BIM model reviews and QA reviews and things like that." So we've gone through over a year now of different training classes for our PMs to walk through a standard process.
And the hard part is that we're building some of the tools as we're doing it, and so it's a moving target.
Chris: So we started with something as simple as a receipts app, and then it sounded like there was a middle tier where you were working with maybe smaller teams, where there was one subject matter expert or leader. I know that you built a parks app, where you have logging features. So I'm guessing that didn't require as many stakeholders to design.
Ron: Right. Yes.
Chris: And now you're getting into more business transformation that also happens to have a technology component to it. You're having to standardize the process and how we're going to work, then you're training people on that, and then you're building technology and tools to make that easier to comply with.
Ron: Yeah.
Chris: Because I'm guessing in RDG's long history, this isn't the first time people have gotten together and tried to say, "This is how we're going to manage projects," right?
Ron: No. It's not the first.
Chris: So what would be different this time is... Actually, what is the answer to that? Why do you think this time you'll get it?
Ron: I think this time we're a different company than we were in the past. In 2022, we did an internal reorganization. We used to have separate business centers in different offices, and now we've switched to more of a studio model, where we have studios of people, but they can be across offices.
And so that caused people to work together between different office locations, and I think that really started to show that, "Oh, wow, the people in this office used to do things totally differently than this office." And so that highlighted those differences. Because the people that you were around were probably the people you followed the most, and when we started working in studios across offices, it became more apparent that there were differences.
Chris: So the ability to work share across offices just really made that clear.
Ron: Yeah. It drove it to the next level.
Chris: And from the tech perspective, it sounds like as you're working, you will build something as simple as a spreadsheet for scheduling. I happen to have gotten a really cool demo yesterday from you of something that you're building. And now that's more like software versus a spreadsheet.
Ron: Right.
Chris: And I'm curious if that's a typical process for you, to start with a lower-fidelity thing like a spreadsheet to validate the use case, or not?
Ron: In that particular case, I thought about trying to build an app first, but part of it was that we were on a timeline, and I didn't have time to build the app that I wanted to build. So I just went with what most people were using anyway. I already knew that they knew how to use Excel, and I just made a better version for them of things they would have.
I gathered several different scenarios of how people were doing it, and then took that and built a tool that they already knew how to use. I thought about going back to make an app, but because of the timing of it and trying to get the training out, we said, "Well, we'll just do this, but we'll come back to it later."
Chris: Now that they have something in Excel, which is a tool they already use, how do you imagine getting them out of Excel and into the app that you're building?
Ron: I think it'll be easy, because when I built the Excel tool, I was like, "This is better than what they were using," but I could see the holes in it right away, just because of some of the capabilities that you can't necessarily integrate into Excel the way I can when building an app.
And so we're starting to test the new app that we're building, and people are really liking it because of the integration, again. Because when you go into it, all the data that we have in Deltek is already there. We don't have to go type it in manually. So because we integrate, that makes the barrier to entry a lot lower, because they just walk in and their data's already there.
Chris: At a high level, what else besides scheduling? Are you building the scope into this app? Are you building roles and responsibilities, some of the things you talked about that you need now?
Ron: Yes. So it started off with scheduling, and then from there, because of the project management training process that we're going through, we were like, "Oh, we need to have roles and responsibilities." Some of our team members, as they're building tools, are building these really complicated spreadsheets. We're going, "Oh gosh, that's just so hard for people."
So now we've added in roles and responsibilities and assignments of those roles, and the goal is that this all becomes available and visible to people. Because one of the challenges of having everything in a spreadsheet is that it's stored somewhere, and you don't always know where. And even though we do have a standard process for where you file your files, people don't always follow it exactly. Surprise, surprise.
So we've started putting in roles and responsibilities. We started looking at scope. We started looking at deliverables. We're even going now into notes and information that normally would be kept in... We've used OneNote a lot to put that information there. So we're starting to put all this context in, and the whole goal with that particular app is that you can go to one spot and at least get to the information, or have a link to where the information is, from one location.
Chris: Right. And I would imagine from a company perspective, you'll also be able to make sure that teams are all putting their scopes in, they're all doing their roles and responsibilities, they're all building schedules.
Ron: Yes.
Chris: And so you can help ensure quality is happening systemically.
Ron: Yes. Right. Because when you put something into an application with a database behind it, now you can start to see what is there, what is done, what is not done, and then that helps from the standpoint of holding people accountable to follow the processes and best practices.
Chris: How do you make a change... So I'm guessing the people at RDG follow the distribution curve of the people in most companies, where you've got some early adopters who are excited to use this new tool. You've got some other people who are like, "All right, seems like it's working. Denise and Sarah said it was good. I'll try it out." And then you've got some people that are going to fight to the death to not let go of their spreadsheets. So how do you think about introducing these new tools into the company?
Ron: Right. So I'll share some tools that we've done in the past. We go through a professional development process with our staff, and one tool we built was actually for continuing education requests.
We had a process for continuing education requests where people would go fill out a Microsoft Form, and then they would download this spreadsheet where everyone would look at what was requested and try to put together a budget. And then of course, you ended up with every studio having its own separate spreadsheet, and then they would come and say, "Hey, can we put all this into one report so we can pull it all together?" And I'm trying to take all this mess that they create, because they can create whatever they want in there.
And so we actually built that into a Glide app, so employees could go click and fill out a request for continuing education, and it goes into the database. The studio managers could go in and see their studio's requests, and they could just click a button and approve or deny them based on the budgets that they had and what their priorities were for their studios.
And when we launched that, the studio managers came back, and the first time they saw it, they were like, "This is easy. This is simple. It's so intuitive." And so it made their life easier.
And so my goal in building apps or even applications has always been to try to make it as simple and easy and intuitive as possible, because then people will want to use it. And if it makes their life easier, then they'll use the tool. And if they use the tool, the huge benefit, I think, from a company standpoint, is that we gather the data, and that data becomes very valuable over time to look back and look forward on what we're doing and how we're doing with different project processes, or even continuing education.
Chris: Yeah, that's right. I mean, back to your project management app, what are you calling it? Is it the PM app? Does it have a cool name?
Ron: Right now it's the Projects app. Although there have been some questions about whether we can name it something cooler.
Chris: Okay, got it. We'll call it the Projects app for now.
Ron: Projects app for now.
Chris: Yeah, but that's so interesting, because you're pulling together some structured data, like roles and responsibilities, scope, and schedule, as well as some of what was unstructured data before, living in OneNote and those kinds of things. And I'm guessing that's going to be things like design decisions and the client's priorities, almost like a notebook internally, right?
Ron: It is. A project journal.
Chris: Project journal, right. Similar idea. So then the ability to search across all that structured and unstructured data seems like an awesome opportunity.
Ron: Yes. In fact, within that app, we've built in a project assistant, which is really a chat window against our project. And because we have all the data in the database and in the project notes there, as well as other things we look to bring in in the future, now I can ask a question, and it knows all that data, and it can surface that information for the questions that I'm asking and want to know about my project.
So it's been really valuable. We haven't launched it fully. We've got about five or six different projects on it already, but it's already seen results.
Chris: So the project assistant is one way to go at it, like, "I want to converse with this project." But it seems like you also have an opportunity to cut across projects and say, "I want to see the last five scopes that we've done. Can you help me learn from that?" Or maybe even fold lessons learned into your Projects app at some point.
Ron: Yeah. Lessons learned is on the roadmap already, because we've been talking about that with our QA team, like, "Hey, how do we capture lessons learned?" And what they've been doing in the past is putting it into either a OneNote notebook or a spreadsheet, right?
Chris: Well, nobody knows where it's at.
Ron: Yep. So what we're planning to do is make it so we could tag an item as a lesson learned, and then that will go through a filter for, is this something that needs to go company-wide, or is it just something specific?
And then the idea is that as we're working on a project, we're going to say, "Hey, what are lessons learned from other similar projects?" And then it would bring these up and say, "Oh, here are things that we learned on another project that was similar in scope or size to this project." So having all that in the database will become incredibly valuable as we move forward.
And so part of the challenge is getting people to see that, like, "Hey, if you'll put this here, we can give you this here later," right? But that goes back to making it easy to do.
Chris: So if I'm listening to this podcast and I don't know you or RDG, I'm kind of squinting my eyes, like, scheduling, scope, roles and responsibilities, even lessons learned to a degree, these seem like general, generic problems. Isn't there off-the-shelf software you could have bought to do this?
And I'm curious, as you've been on this journey of building some of your own... I know you buy tools also. You bought Synthesis, you bought Deltek, OpenAsset. You do buy, you do build. When you came to the Projects app, did you even go looking to see if there was a precedent? Or at this point, did you just say, "I know we want it to be so tailored to us that we're going to build it"?
Ron: I have looked at different project tools over the years, because I've known it's been an issue. I've looked at several different tools, and what I always ran into was, this tool looks like it can do what we want, but it's a separate tool. And unless we can integrate it, we're going to have to hand-enter data into another system. Now, a lot of the tools out there can do some of that integration today as well, but then you also have a licensing cost on top of that.
So as we were going through this, honestly, a year ago, I never would have thought of building this. But because of the technology changes that have happened, quite honestly, since January of this year, we started realizing that more is possible with some of the AI coding tools that are out there. So a year ago, I would not have considered building...
Chris: So having Glide apps a year ago, you wouldn't have tried to tackle something this big.
Ron: Not this big. No. Because Glide is a great platform, but something this big would be a lot of work to build on their platform. So yeah, last year I wouldn't have considered doing this app. I would have considered that we would have had to purchase something and then try to integrate it, which is a lot more work too.
Chris: So given your timeline, it sounds like Project Pando, that improvement project, was already underway a year and a half ago. So you were probably coming up to the point where you were looking... Did you start researching and thinking you were going to need to go another direction before Claude Code became really available? And then did you just pause all that work and start trying to build it in code? I'm just curious how that went down.
Ron: I looked at some platforms probably a couple of years ago, and I had come to the conclusion that none of them would do what I wanted them to do. And so it was just on hold. And then we started that process, and we started building the individual tools. But then when I started to realize what Claude Code could do, that opened my eyes to the power of the things that we could build ourselves.
Chris: Was this project super app the first big project you tackled with Claude Code?
Ron: Actually, yeah, I'd say it's the first big one. We've done some other smaller pieces with it. We've done some agent building, tools with agents, and we built some internal chat tools as well. But yeah, this is probably the biggest one that we've built.
Chris: What was the learning curve like for you? How technical does someone need to be? How much of the success you've had so far with this Projects app you're building in Claude Code was that Ron knows architecture practice, he knows RDG, et cetera, and how much is that you're comfortable with technology, do you think?
Ron: I would say it's been a process. I understand the processes that we go through, because I've been running them in our company for many years. I understand Deltek Vision and the database structure and how all the data gets stored there. I've built all kinds of Power BI dashboards off of it. So I do have a good understanding of all the project data that is in that system, as well as other platforms that we have.
As I started to see what was possible... you go through those times where your eyes open to what's possible. And that actually happened with my project schedule spreadsheet. It's interesting. I was starting to play with different AI tools. I've been using Perplexity actually for quite a while, and it's a fun story, because Perplexity had come out with Perplexity Computer, and I hadn't played with that. That's their AI coding tool.
And I think that's the thing that really opened my eyes to what was possible. It was funny. It was a Friday afternoon, and I was actually leaving work early to go pick up my mom's car, because we had taken it to the shop for her, and we were going to deliver it back to her.
So we'd gone over to her place, and when I was there, she asked me a question about something I didn't know. And like I do many times, I pulled out my phone to use Perplexity as a search engine. And as I opened my phone, Perplexity said, "Hey, Perplexity Computer is now available on your iPhone. Do you want to install it? Do you want to update it?" I'm like, "Yeah." So I clicked yes.
We left her place, and my wife had to run some errands, so we went to the grocery store. As we got out of the car, I was walking in the parking lot with my phone, and it said, "What app do you want to build?" And I was like, "Hmm, I don't know." So I literally jumped onto the Know from my phone.
Chris: The Know is your Synthesis instance.
Ron: Yeah, that's the Know, our Synthesis. So I jumped onto our intranet, and I downloaded the project schedule template that I had built previously and that we had put on there. And as I walked into the grocery store, I said, "Build this," and I let it go.
And we walked through the grocery store, and 15 minutes later, when we walked out of the grocery store, I had an app on my phone that worked and was doing what the project schedule tool I built in Excel did. And it was impressive enough that I went home and spent the rest of the evening playing with it. Much to my wife's dismay, I guess.
Chris: And by playing with it, what does that mean?
Ron: So I was like, "Oh, wow. What can I do?" Because it did such a good job of putting together an app. Then I started trying things like, "Well, can I do this? Can I make it so I can drag and drop my Gantt chart bars in my schedule tool?" And literally by tinkering with it for a couple of hours, I was able to build a tool that was way better than the Excel spreadsheet I had built, which I'd probably spent a week on, right? I probably spent 40 hours building that tool.
And I was so impressed with that, and that actually is what started the whole process of like, "Wow, what else can we do?"
Then from there, I really got into understanding what you could do with AI and agents. In fact, I took a course on how to build agents, and that was one of those things where you get into it and it was kind of self-directed. We met with somebody every week for about six weeks, but they gave you assignments, and then you just had to go figure out what to do.
And in the process of that, you learned. It was one of those things where I felt like I was way out over my skis, because I didn't know what the heck I was doing. But through that process, I really learned a ton about how agents could work and how agentic coding could work. And then I took the app that I built with Perplexity Computer from my spreadsheet, moved it into Claude Code, and started developing the app that I shared with you.
Chris: So the Projects app, to be named later, the app known as the Projects app, is eventually, if everything goes right, going to be a core enterprise tool for RDG...
Ron: Yes.
Chris: ...that you have built with Claude Code. And you go on LinkedIn, and you can see very strong opinions on two sides. On one hand, it's like, Claude Code and vibe coding are here. You can build anything you want. Why would you ever buy software again?
And then on the other side of the spectrum, you see established software companies saying, "Sure, you can build a cute prototype that will work for five people, but how is that durable? How does it scale? It writes a bunch of garbage code that you can't support and maintain."
And I'm curious, as someone building something that is going to really matter to your company, how do you think about using agentic coding to build durable stuff for RDG?
Ron: Right. Well, first of all, I would say as a company, we've never been afraid to customize to our process, right? We have customized so many things. We've customized Deltek and Power BI dashboards. We've customized lots of different tools. We've customized Revit to do the things that we want it to do. So we've always been very much about customization within the tools.
And I think Claude Code is now allowing us to customize to a whole other level, because we can get the tools to do what we need them to do and integrate well with the other platforms that we're using.
I know I've been in rooms where people are like, "I don't want to build anything. I just want to buy it, because then they support it."
Chris: Is that at RDG, or in rooms with other leaders?
Ron: Rooms with peer leaders. And I guess we've never been afraid to do that. Now, there's a cost to maintaining and managing them, and this is probably one of the biggest things we've ever done, so I don't know what that means long term, because we haven't been there. But we're willing to find out, I guess. I don't know if that answered your question or not, but...
Chris: Yeah. I guess I'm thinking, is 100% of the Projects app agentically coded, or is your team also building components of it? Are you reviewing its code? I guess the question I would ask as a board member at RDG is, do we know how this thing is built, and how are we going to support it?
Ron: Yeah. It is all built with agentic coding. We do run reviews on it and try to inspect the code using the agentic tools. So in some respects, I do feel like, okay, I'm doing things where I don't really know what I'm doing at times, but the power that we've seen from the customization and being able to develop the tools has been phenomenal.
We do have some people on staff that are helping look at that as well, and looking at it from different levels of security and capabilities, and so we'll continue to resolve that in our minds, I guess. But again, we've never been afraid to customize.
Chris: So as you're moving forward, how has this changed? I presume that it has changed. What are we in, September? In the last eight months of 2026, since you and the company got into agentic coding, how has it changed your approach to build versus buy?
Ron: I would say that the Glide platform was low-code, no-code, and we integrated with it. So I feel like that was a hybrid approach, right? We were building tools on top of other tools or integrating with other tools. We're still doing that, but I feel like we're going into an era where the tools are only going to get better at this.
And so I believe that we'll be able to create tools specifically for our processes that are better than the tools we can buy elsewhere, because they're customized only to what we need and not what everybody else needs, right? And I think that's some of the value in it.
I'm excited about where it's headed, and the agentic tools themselves, agents and all that, are creating incredible efficiencies for people as far as research and being able to review information and create information. So I'm excited about where it's going, and yes, it has changed. I feel like we're capable of so much more, because the tools work so well.
Chris: Have you replaced any software? Like, "Why are we paying for this? We should just build it the RDG way and retire that software." Or are you trying to fill in a space that isn't currently covered by somebody?
Ron: There is one. Actually, this was an app, and it's almost an application, but it is built on top of the Glide platform. It's not one that I built. It's one that Sean, one of my coworkers, has built.
We do a lot of furniture procurement, and our procurement process started in Revit with an add-in tool, with an export to a spreadsheet, which then went into another platform for tracking the furniture orders, and then it came out of there and went into a spreadsheet for invoicing, because we couldn't put the invoices into Deltek, and then we had to import stuff into... So we touched five different platforms to do this.
And we built a tool for procurement that allows us to streamline that process. And because of that, we are eliminating one of the tools. We're still on it because we have some lingering projects there, but no new projects have been started on it since probably March. And so that one will sunset at the end of the year if all goes well.
There are other platforms that I've started to look at, going, "Wow, if we can build the Projects app to where we want it to be, I think we could eliminate some other tools, too."
Chris: From a risk management perspective, in terms of building this technology, how does the company think about, if Ron wins the lottery, who knows how this whole crazy machine is held together? Or do you feel like because it's agentically coded, it's actually pretty well documented, and someone could just take it over and keep running it? I'm curious about the risk piece of this and that conversation.
Ron: Yeah. Well, again, we've got a couple of people on staff that know some programming as well, so there's their experience. But also, with some of the things we're doing with Claude Code, as we build and make different commits to GitHub, we're actually documenting it probably better than we would've documented it ourselves, because the tool can do the documentation for us. So we're saying, "Hey, write this to documentation," and it's documenting it.
So I truly think because the tools are there, someone else could pull that in and look at it and then basically add to it and maintain it. They may not understand exactly how it was all built, but with the tools, I think they can figure it out. I don't think it's a huge risk from that standpoint.
I think some of our older stuff is probably more at risk from that standpoint, because some of that is very custom coded and maybe harder to understand than some of the AI coding.
Chris: I want to talk about integrations a little bit, because that's been a theme of what we've been talking about.
Ron: Yes.
Chris: And obviously... When I say obviously, I mean for you. For our audience, there's a new technology called MCP, which is Model Context Protocol, which has made it easier to connect agentic systems to each other. And Synthesis has an MCP server, as do many other technologies that you're using, I'm sure. I'd love to hear your thoughts on MCP so far, both from a Synthesis perspective and more broadly, on how it's changing the way that you're thinking about building software.
Ron: So I think MCP connections can be incredibly valuable. In fact, when I was doing some of the agentic coding, building my own strategy agents and different tools to do things, I did connect to a couple of MCP systems.
We haven't actually allowed it to connect to our own email system yet in that tool, just because of all the unknowns of what it can and can't do. When you're building agentic tools, you've got to put good parameters around them so that they won't do things you don't want them to do. And so we've learned how to do some of that, although from a security standpoint we're like, "Oh, do we let all that into the agentic tool, and what's it going to do?" So we have done some testing in that area, connecting it to some email...
Chris: Like creating drafts of email, that kind of thing, but not sending?
Ron: Yeah. Or even searching your email and responding to it, yeah. Creating the draft but never sending. As well as just finding information within it. So that is working really well.
Of course, we're playing with the MCP tool that you guys have created, and I'm very excited about that, because last week you and I talked and you asked me if I had any feedback, and I said, "Well, let me see if I can integrate it into my Projects app."
Chris: Let me go to the grocery store and figure it out.
Ron: Yeah. Fifteen minutes, we'll have it up and running. And actually, I have integrated it into the platform now, which you didn't see. And it's very exciting, because I think it's opening up a whole new realm of potential for my Projects app. I was able to integrate it. In fact, I started last Friday, and by literally Tuesday, I had it up and running and doing things for me that were not possible before.
What's really nice is that our Projects app allows us to have all the project context in the app that I built. But MCP, through Synthesis, now allows us to connect out to Synthesis to get best practices and processes, and we actually have our whole project management guide for Project Pando on our intranet.
And so I can now start asking a question in my project assistant and say, "Hey, what are best practices for a QA/QC checklist?" or whatever, and it will literally go out and search the intranet and bring back relevant information.
I've also integrated it into a journal that we have, so that if I start typing about a topic, I can click a button now that says, "Go get..." Actually, it's called Project Pando Guidance at this point. Go get Project Pando Guidance, and it will go out to the intranet and pull in relevant information for the key points on that page and the topic of that page.
So it's using that technology and basically putting key information right in front of them, like, "Hey, here are best practices on how to do that," with a link right back to the intranet. So I see lots of potential with this from the standpoint of being able to get best practices inline inside the app, just in time, right when I need it most, when I'm doing the work.
Also, because it knows what project I'm in in the Projects app, I can say, "Go find anything about this project on the intranet," and it will go and pull all the relevant information, including posts about the project, the profile sheets, the clients, the team members that are working on it, and all that data now comes into the app.
Chris: What's so cool about what you're saying is, going back as long ago as before Knowledge Architecture, 20 years ago, we would talk about this idea. We didn't have the language for it, but I think you and I were in an IT roundtable together up at my firm. It's this idea of a project brain and a company brain.
Ron: Yes.
Chris: You've got a set of technologies around executing individual projects, and then you've got systems of record for your best practices, your policies, learning, your project stats, and those were usually two completely different worlds. And what I've seen in the technology you're building is that you're able to bring part of the company brain into the project brain, in the flow of work, in a way that... This is what we've talked about in knowledge management forever: how do you get knowledge into the flow of work, right?
Ron: Yes. I would agree, and it's so exciting to see the project context tied with the best practices context, bringing that together. I think there's incredible potential and value in being able to do that.
Chris: Yeah. One of the things you showed me was just so simple, but it goes all the way back to Project Pando and your junior people not knowing what they were doing, and to roles and responsibilities. Okay, you're a job captain on this project. Great. What's a job captain?
And so I saw you dropping links to the role descriptions next to the role assignment that's happening. But that's linking back, again, to your intranet, because that's the standard place where that information lives.
Ron: And interestingly enough, that is actually through the MCP server.
Chris: Right.
Ron: And I basically just said, "Add the links in." It's looking up what that role is in process and going and finding the right page.
Chris: So you're not having to hard-code a bunch of links to pages.
Ron: I haven't hard-coded any of those links. They've all been found in process from the context, through the MCP server.
Chris: Super cool. Yeah. I love that. Generically, are there any other core platforms where you're finding really valuable use cases for MCP?
Ron: I think the one we're interested in connecting... We don't have the licensing yet for Egnyte's MCP capabilities, but we're excited about testing that, where we could literally connect the project folder so the project assistant could search and find any files within that project folder and be able to read those and use that information.
The other one I think we're interested in is Revit, which has an MCP server, although I'm not sure exactly. It sounds like with the first version, you have to have Revit on your machine and Claude Desktop on your machine, and it will connect to it. But we're looking to see if we can do that maybe through their web interface and connect to it that way.
Chris: Yeah. That sounds super exciting. What other hopes and dreams do you have as we're starting to wind down 2026 and you're starting to look at 2027? Is most of it just taking the Projects app and adding more functionality and going deeper and scaling it, or do you have other projects that are starting to creep up for you?
Ron: Yeah, the Projects app is a big part of that. And then I think as we're starting to roll this out to some team members, change management will become a focus as we get into rolling it out company-wide.
History tells me that we can build a really cool tool and people still don't use it, because they run into one problem, right? And then they're like, "Well, the whole thing must not work." We've run into that many times. You follow up with someone like, "Hey, how's that app working?" And they're like, "Oh, I don't use it." I'm like, "Well, why'd you quit using it?" "Well, it didn't do something right." "Well, I can fix that."
So it's one of those things. So change management is a big part of it.
Chris: Wait, let me pause there. So what did you learn from that? How are you preventing that from being the thing that slows down the adoption of the Projects app?
Ron: Well, right now I'm meeting weekly with my PMs that are using the app. So we're meeting weekly to follow up and find out what bugs they're seeing or what challenges they're having when they're using it. And then we're typically fixing those within a week, and coming back and showing them what it can do, and sometimes adding additional features to it. So it's really the checkpoint, right? Touch base, follow up, make sure that people are using it.
It's interesting now, because we also have people that have been in the app that I haven't even talked to about it yet, because PMs are having other people get in there and start to do things. And sometimes you're like, "Oh, I didn't think they would use it that way." And then you learn.
In one case, something happened, and I was like, "Okay, I've got to prevent that from happening, because that would literally cause issues." Because one of the things that we're having to do is, I am putting a sync back into Deltek from a schedule standpoint, for revenue projections and staffing projections too, so that we can adjust the schedule here and then click a button. But if they mess up the phases in there, it ruins all that. So I had to put some controls in to keep them from doing it.
Chris: When you meet with these early adopters, are you meeting with them one-on-one? Are you meeting with them as a group? How do you do that?
Ron: Starting off, I did meet with some people one-on-one, and then I got a core team of about three PMs that I worked with, where we started meeting weekly to do this. I still have individual one-on-one meetings. In fact, I did one this morning with somebody, because they were saying, "Hey, can we please do this?" And so he came, and we had a conversation this morning about it.
So I do both. I want to make things easy and simple and better, and so I'm always open to hearing the feedback they have to offer.
Chris: I'm curious how you... So, I totally agree. And if you listen to 10 people, and each of them has an idea on how to make things simpler and easier and better, and you do all 10 ideas, then things are not simpler, easier, or better for anybody.
Ron: That is true.
Chris: Every product manager learns how to say no in the friendliest possible way. How have you learned to do that?
Ron: Well, that's funny, because we had that exact issue when I had three project managers in the room, and we were talking about how we were going to display some information by department and phase, and all three of them wanted it different. So in that case, we said, "Well, we can't have..." Actually, I did make a toggle where you could flip the way it shows, right? So that solved most of it.
But then we're like, we've got to be thinking about this from a company-wide standpoint, and just try to point them back up to the big picture: everybody's got to be able to use this as we go down the road. And if everybody does, your life is going to be better, because everyone will have visibility into all the data that we have there.
Chris: That's interesting. I feel like change management has always been around as an important thing for as long as I've been working. But I feel like in the last 12 months, the number of mentions of change management in any given conversation has rocketed up. And one of my favorite quotes about change management is that people want change done with them, not to them.
Ron: Yes.
Chris: And that sounds like what you're talking about in working with those project managers. Even if they disagree, they were in the room, you talked it through and realized that for the good of the company, we can't do all three things.
Ron: And I've also found that individual conversations and group conversations can make a big difference. I learned this in the IT world years ago. I remember this was way back when we had two different business offices, and they were on two different versions of the same software. We upgraded every other version, and so they were leapfrogging each other.
And I was like, "This is ridiculous." And it was funny, because what I ended up doing was going and talking to one group and saying, "Hey, what do you really want out of this?" And then going and talking to the other group separately, because there was a little bit of competition or head-butting going on, and asking, "What do you really want?"
And then I brought them together and said, "Well, hey, this is what you want, and this is what you want," which was really the same thing. "So we're going to go here and do this now."
And so it's learning how to communicate that, to listen to them individually, but then bring them together to have the overall conversation and make the final decision.
Chris: Yeah, I think that's a thing that, as a former IT leader, I can say took me a while to learn. It's hard, because in defense of our IT friends, there is so much that comes at you all day long. It's just inbound all day long, and sometimes you're just like, "We're just going to do it this way." I'm just trying to simplify my life. I can't have 12 different options.
And so I think the way that you just said it is nice. You're trying to lead people toward a simple solution, but you're involving them in the process of figuring out what that simple solution is, which I like quite a bit.
What are your thoughts around... I've seen you speak at KA Connect. I've seen you involved with the Jaggaer Tech community, and probably other communities. And I know that people in our community say, "I want to do what Ron's doing." So what's your advice for people who want to start going down the road that you've gone down, whether it's building your own apps, having an innovation team, or agentic coding? What are you thinking?
Ron: I would say the first thing is to be curious about what could be better, and always be willing to listen and learn about what we can do to make it better. But then also, I would say to jump into some of the tools that are out there and start playing with them.
For me, I learn best by doing it and playing with it. I love learning, right? I love learning and figuring things out. And I love connecting dots, and I love making people's lives easier. So it's the problem-solving of that that I like.
So I would say really jump in and try to play with the tools that are available. I took an agent course that was out of my comfort zone, but looking back on it, I learned so much that has affected the things I'm doing now and has been really beneficial.
Chris: Why was it outside of your comfort zone?
Ron: I think it's because it was so unknown at the time, right? Like, what's this agent thing going on? This was in March, when I started taking this agent course. And a little bit of it was like, what's this going to do? Is this secure? Is it not secure? There was that aspect of the agentic tools at that time as well. And then there was setting up the interface for it.
And I think one of the best things that course taught me was, if you're playing with these tools and you don't know how to do something, create an agent that you can just ask questions to, and it becomes like a tutor that will walk you through specifically how to do it. And you can literally try something, paste an error into it, and say, "Hey, what about when you get this error?" And it'll walk you through that process.
Chris: So the first agent you built was an agent to help you build agents?
Ron: Yeah. It was an AI builder agent that you basically use as a very patient tutor, right? Because if it would tell you to do something and you're like, "That's not how I do that," you just say, "Slow down. Show me step by step what to do." And then it would literally walk through each individual step if I didn't quite understand what it was asking me to do.
Chris: What were you building in during this course? I'm just curious.
Ron: That was actually using Claude Code, in the CLI, the command line interface version of Claude Code. And so that was all new to me. I was using VS Code with Claude Code plugged into it.
Chris: Have other firms come to you and talked to you about both what you're building and the innovation role? Do you think firms should have one? At what size should firms have one? What do you think about this job that you're doing?
Ron: Yes. I think that because of how fast things are changing in the industry and in the technology world, you have to be thinking about where it's all going. And I remember, this was years ago, when I was still in the IT role, I got so busy just doing IT that I couldn't do strategic thinking, right?
And so I voiced that concern with leadership at the time. At that time, we had three people on the IT/DT team, if you will. And we decided that we'd actually double the size of the team in a short amount of time, because we couldn't be strategic about where we were going.
Chris: And also still keep the lights on and do all the stuff that needs to be done, right?
Ron: Exactly. Yep. And so I believe it's very important to be thinking ahead about where we're going. I think every firm should have some kind of strategic thinking. It may not be a full-on role, but maybe part of someone's role. Just looking at, hey, where is this stuff going? Go investigate, go play.
I think actually playing with it will teach you way more than just reading about it, because you're learning. You go, "Wow, when I do that, this happens," that kind of thing. So I think it's very important in the world that we live in today, and as fast as all the technology is changing, it's even more important.
Chris: I really like that. It mirrors my personal journey a lot. When I was in IT, I had to fight very hard to be able to work on the important, non-urgent things, the things that were going to make a difference 18 or 24 months down the line instead of today.
And that was always really important, and I'm glad that you said that, because what that means for RDG, right, is that Ron wakes up every morning thinking about how RDG is going to be better in 12 or 18 months, versus just how we're going to get through the day. Because that's a lot of what day-to-day technology is.
Ron: Right. Yeah. And that's probably the biggest change going from IT director to director of practice innovation: that's my full-time job now, right? Versus it being part-time. I had to keep everything running before, but now I can be more strategic.
Chris: Actually, let me ask you about that. That seems true for a certain amount of time, until you've got a receipts app, a Projects app, a parks app, or whatever. You start stacking them all...
Ron: Power BI dashboards and these things.
Chris: ...Power BI dashboards, and now all of a sudden, 90% of your job is maintenance and operations again. So is it true that more of your job has been consumed by supporting the things you've built? Or have you been able to transition those to other folks to support them so that you can keep building new things?
Ron: That is a little bit of a hard thing, because a lot of the customizations we've built over the years, I'm the one that built them, or built them in coordination with consultants that I've used. And so I know how they work, and transitioning that to someone else is a hard thing. It takes longer to do.
I've started transitioning some of those things, but as you look down the road, somebody's got to know all of that when I retire, right? So it is a little bit of a challenge. I would say that because I know things so well, I can fix them fairly quickly. But I do have some other people that are starting to do some of that.
So it's probably 25% of my time that goes to that, and 75% is more strategic thinking and/or...
Chris: Building out is strategic thinking, in my mind.
Ron: Sure. Yeah. There's the execution part.
Chris: No, that's great. That's a good ratio. Maybe my final question: what part of this role do you like the most?
Ron: I love figuring out and solving the problem to make things simpler and easier. I'm a learner by nature, so I get excited, and I get really excited about knowing that we can make the process better, and helping people see the potential of what it can be. It's the problem-solving and learning piece that I absolutely love.
Chris: Let me break that down across the life cycle of a new thing: the early discovery meetings where you're process mapping, prototyping the app, working with users and getting them to adopt it. What part of that journey is the best for you?
Ron: I do like all of it. I would say I do like having my hands in it, and the discovery of, "Oh, wow, we want to do this." And then you realize as you're programming things, "Oh, wow, could I do that? Let me try it." And then you're like, "Oh, wow, I didn't realize we could do that." So that's probably the most exciting part: actually building the tools, just because I think it's so fun.
And then also, I think it's sharing that with other people and them seeing, "Oh, wow, this could be really valuable to me." With the Projects app, every time I've shown it, I've had people going, "When can we start using this?" Right? And I'm like, "Well, we're getting there."
So we've had that excitement around it, and again, my goal is always to make the tools so easy to use that people want to use them. And we're seeing that already with this particular tool as we get it going.
Chris: Yeah. I've always thought... I've drawn it out as, there's a really great part early on where you're first seeing that this could be a possibility, and then there's a bit of a valley of despair where it's like, "Actually, this is really complicated, and I have to think about how all this stuff comes together." And then you solve that, and then you start building, so you're high again. And then it's like, wait, there are all these edge cases and this quality assurance, and then you're down again. And then you start showing it to people, and they get excited. So I feel like for me, it comes in waves throughout the process.
Ron: I will say the most frustrating part is when you sit down and go through the process map, and then you build out what was asked for, and then you show it to them, and they go, "Well, that's not how it should work." And you go, "Well, but that's how you told me it should work." And you just engage with it and move on and make it better.
Chris: No, I think you make a good point. In fact, I'll go one better. I've done that to myself. I've built the exact thing where I'm like, "This is going to be the way to do it." And then I see it moving in 3D in a real-world scenario, and it's like, this isn't the right way to do this at all.
And so I feel there's something about getting into prototyping faster. The sooner you figure out with working code that it's not going to work, the better for everybody.
Ron: And I think the AI tools have made that so much faster, because someone says, "Hey, can we do this?" And I'm like, "I don't know. Let me try." And literally, I spin something up, and within a couple of days, you have something working, and you're like, "Yeah, that'll work," or, "No, that's going to be too tough."
Chris: Yeah. I know. I'm going full circle with you, starting in architecture. I've always thought that there are so many parallels between technology and architecture, especially between designing and building software and designing and building buildings. The one thing I always think is better about building software is that if you're wrong, you just patch it with a bug fix, or you just do another version, and it's a little harder to do that with a building.
Ron: The liability is a little bit less.
Chris: Oh, right. All of the stakes around health and safety are different.
Well, thank you for making time today and sharing your thoughts and your process. This is super interesting.
Ron: Yes. And thank you for having me. I've enjoyed it.
Chris: My pleasure.