Confluence S1E7 - Overhauling Knowledge Architecture’s Synthesis v6

Welcome to the Confluence Podcast. I'm Evan Troxell and you are?

Randall Stevens.

Randall Stephens is here. And Randall and I had the opportunity to speak with Chris Parsons of Knowledge Architecture recently. And Randall, do you want to talk a little bit about our conversation with Chris?

Yeah, it was a great conversation. For those of you that don't know Chris or are not familiar with Knowledge Architecture, they've had product in the market, basically the intranet, the way I would describe it, Internet software platform, and are known in the industry of being the primary provider of those kind of capabilities inside of a lot of. A lot of architecture firms and practices. And the discussion with Chris was around. They had a major overhaul. They used to. The platform was originally built to sit on top of and leverage SharePoint and customize SharePoint setup. And they made a huge investment and kind of divorced themselves from the SharePoint platform and now have their own standalone platform. A lot more control, a lot more capabilities. But we got to spend time with Chris to talk about just why, what that's all about and what that transition kind of investment in this look like for them.

Yeah, I think one of the big topics that I wanted to hear from Chris was because I think probably there are quite a few people who listen to this show who are relying on other companies, technology, and they're building on top of it or piping into it using APIs, whatever. And we've seen issues even within the last few months with Reddit, where they started charging for API access. And all of a sudden people who have built their livelihood on top of that have to respond. I think that one of the big drivers. I don't want to give away the content here too soon, but.

Punchline.

Yeah. I mean, it's like, how much of your own destiny do you want to be in control?

Sure.

Right. So I think that's something that people would find interesting in this conversation. The other thing is just how did Chris get to where he is? Chris is, you know, he came, he didn't study architecture, and I'll read his bio in a second, but he ended up working in architecture in it, and then, okay, well, how did Knowledge Architecture even come into being? So it was a fun story to hear.

Yeah. Usually it's people in those positions that see the problem and say, hey, there's got to be a better way or a way, an opportunity to go fix this, or we did this ourself. I wonder if other people have the same problem. And that's where I think business opportunities and product development. But you're right. About this whole build versus buy. Do you build on top of somebody else's platform? How vulnerable? You know, those are all things that, you know, a lot of us are doing development on top of, you know, Autodesk Stack and applications and Amazon's, you know, Stack. And those all become considerations when you are developing technology of how much, how much usually makes it easier for you to do things more quickly when you're doing that, but it also then makes you vulnerable to, hey, I don't have full control over this, so what am I, you know, what position I'm in. So I think, I think we agreed with Chris that there's probably going to be a follow up to the interview, this first interview, so we might dig in a little deeper in further interviews about how some of the product was developed and take a little bit deeper dive on that front. But this was a great kickoff conversation.

And just to kind of frame that a little bit even further is this is Chris has thought so deeply about the problem of knowledge capture, knowledge dissemination in a firm. Right. And that's really like you said earlier, he identified this opportunity because he saw it firsthand and there are a lot of firms using their platform to do just that. And so he, in this one gives kind of a high level overview of the fundamentals and even how to start approaching this as a firm if you're not, or maybe even how to do it better if you are. So like Randall said, if, if we, we're going to hope to have him back and do a deeper dive. But let me tell you a little bit about Chris. As founder and CEO of Knowledge Architecture, Christopher is responsible for product development, marketing and organizational health. He's been a technology leader in the AEC industry since 2002, including serving as the Chief Information Officer for Steinberg Architects and the Information Technology Director for smwm, which is now Perkins and Will. Christopher has a degree in history from Wake Forest University. He's an avid reader, trail runner, birdwatcher and cook. So interesting background to end up where he has for sure. And it was a great conversation with him. I hope that you enjoy it. Welcome back to the Confluence Podcast. I'm Evan Troxell and today we've got Randall Stephens of Avail, of course, and Chris Parsons of Knowledge Architecture. And I think we all know each other one way or another. But maybe Chris, you can provide a bit more context for our conversation today. Coming from architecture, starting your own company, Knowledge Architecture, whole idea behind knowledge Capture and why you've chosen to go down the path you have. I don't before we do that. Randall, you want to jump in and you have anything before we kick into it here?

No, I'll just say that Chris and I have known each other not extremely well, but known of each other and have had conversations over the last probably five, six years. So a lot of things that my company does and that Chris's company does are kind of related in that we're. We're both in the. Trying to help people get to information. So it's always a great conversation. And I haven't been able to. I don't know, Chris, maybe you'll talk about the conference that you host, but we've had. I haven't been myself, but some other people from my company have been out for that. So just looking forward to digging into this.

Awesome. Well, Chris, take it away. Tell us a little bit of your story.

Yeah. So I was a CIO and an IT director in two different architecture firms, firms from kind of 2002 to 2009. And you know, I came out of. I was a history major and graduated in 1999 and assumed I was going to law school because with a history degree in 1999, that seemed like the obvious path. But what was going on is obviously the technology boom and the Internet and all that kind of stuff. And so I ended up getting recruited out of Wake Forest into technology consulting. And in 1999, if you had a heartbeat and you could turn on a computer, you had a job in technology. So, I mean, it was really. I had done a little bit more than that. Like, I worked and done some technology stuff, but I wasn't an engineer by any stretch. So worked in that company for about two and a half years. And we were at the very, very beginning of really kind of like it in the way that we were going into. We were the technology consulting practice of a large accounting and tax firm. And so they wanted to roll out ERP or kind of finance systems for the first time. And we had to put in the technology infrastructure, like literally networks and servers, in order for them to lay in that ERP software. And so we did that for. I worked in that group for about a year, got into the software development group because I figured out that's where I really wanted to be, is building software. Did that for about a year, learned SQL. I got in, started getting some basic skills going. And then the dot com crash hit and 911 hit and I was in San Francisco, which was a ghost town in terms of trying to find a job as a person with two years of experience so the way I got into architecture is my girlfriend at the time, who's now my wife, I'm like, we moved to San Francisco so that I could walk to work and you could walk to work. We wanted to be walkable. I want to work in the city, live and work in the city. And when I drew that parameter in 2002, that left like law firms and architecture firms, like the only people that were hiring. And I had never heard of architecture. Like, I mean, I knew what architecture was in buildings, but I didn't understand, you know, that there were like 80 or 200 person firms that like designed these buildings. And like, I had no idea what the industry was like. And so got into this architecture firm to ride out the recession and go back into, you know, tech being here in the Bay Area. And I fell in love with the firm and stayed for five years and loved that kind of like the intersection of art and law and science and politics. And it was just so interesting. And the role of technology kind of in that 2002-2006 period at that firm, like BIM was coming out for the first time, like there was just a lot of like disruption. I built the first intranet that firm had ever had. We did the first digital asset management system that firm ever had. We rolled out CRM for the first time. So it was just like all this cool stuff to work on. And I love the business. And then I went to a larger firm, was the CIO there for three years. And what I had kind of figured out running it in architecture was there were kind of like three main things I needed to do. It was kind of core infrastructure, so like servers, email, networks. There was design technology, which I know that both of you are deeply familiar familiar with. And then it was knowledge management, right? All that information system stuff. And after doing it twice at two different firms, I figured out that knowledge management stuff is what I wanted to do full time. That was the part. Not that I didn't like the other two things, but that was the part that really got my blood going and looked at. So in 2009, I'm like, I looked out the landscape and I'm like, I can go to one of the big firms and you know, we all probably know who I'm talking about and be the chief knowledge officer or the director of knowledge management or something like that, or I can start a business and work with kind of more mid size and smaller firms that I kind of was more familiar with and help them and how I would help them. I didn't know, but like I had this hunch that that seemed like a thing I could do. And so then in 2009, the. Another recession. So there's. It's a story of two recessions in some ways. Then the housing crisis hit.

Aren't they all.

Hey, there are opportunities, you know, sometimes.

That'S called back against the wall. You make those kind of tough voices. Yeah.

And so in that second firm, I was kind of like we were all having to do layoffs. Right. And so I got it. I made a deal with my team that I would go down to three days a week and we'd be able to save one of my more junior people's jobs. And in that extra time that I carved out for myself, plus nights and weekends, is how I built ka. I created the window of opportunity and just went after it with everything I had. I'll stop. I can go into more detail if you want, but like that's, that's kind of the origin story. It's like how we got. How I got into it. It.

Can you talk about, you know, one. Just in, in that time frame, how common was it for a firm to even have an intranet or even understand what that was, you know?

Yeah, I think among the firms. Yeah, that's great. So you guys are probably familiar. There was a company called Zweig White at the time, who's now Zweig Group, and they had published. And I'm just going to make up a number, let's call it 2004, the AEC Internet Cookbook, which was awesome. It was like print, right. And I had a copy. The people I knew and the other AEC firms I was friends with had copies. So people were doing it. Some people were doing it really well. But what was the state of the art when I started KA was either one of two things. Custom built intranets. And in the time it was ColdFusion or whatever it was, or people trying to make SharePoint work. And that had been my path at the two firms I'd worked at. The second firm I worked at was taking SharePoint at the time SharePoint 2007, which was, I don't know if either of you have had familiarity or our audience has, but I'll save them. The history lesson in saying basically like, it wasn't a solution that you could just use. It was a platform, it was a kit of parts. And you had to either spend a couple years taking that kit apart and making it into something useful or hire somebody outside to do it. And people were spending 50, 80, 100 more thousand dollars to build their intranets and they were custom projects and then what do you do about maintenance and continuous improvement, etc. So the lens that we brought that was new was we believed that it should be more like prefabrication and we'll bring intranet for AEC that's already made and we'll do it on subscription and we'll continue to maintain an emergency improvement. In 2009, subscription was still somewhat new in AEC. So this idea that you could get a pre built Internet for AEC on top of SharePoint, but it already worked and get it maintained for a fraction of the cost at which you build your own thing, that was a new idea.

So you were using SharePoint inside those firms. Did you inherit that or was that something that you kind of led the choice of how you all were going to try to implement that?

Yeah, yeah, led the choice. It seemed like in the same way that if you were building a website at that time, even now, but at that time it was probably WordPress. It's like SharePoint was kind of the equivalent. It's like you start from somewhere as a content management system and then you try and tweak it and improve it. So yeah, that was the software I.

Picked and it's great.

It's a powerful, I mean no shade on Microsoft and SharePoint. Like it's gotten better over time, but it wasn't for aec. And then we were able to do integrations with like Deltec and Open Asset and New Forma that people cared about and bring that data from multiple systems into one place and start building like project profiles. And so we started to AEC ify the software as well, which was fun.

Yeah. Did you have, did you have web development experience before or during that time, that incubation period when you started to work at these firms, was that something that you were doing? Because email networks, files security, like that's it. Right. There's not usually a lot of proactive web development happening in firms because it's all folder based file systems, it's all FTP based file exchanging in and out of the company or via email at that, you know, in those earlier days. So where did that come from? Because. Or was it really more like you were using SharePoint because it was WYSIWYG at some level. It didn't take a ton of custom coding at that point, I would assume.

Yeah, I think it's a little bit of both. Where I was strong and I can kind of speak to the teams I worked with, But I think the strength that I plus a person on my team had was kind of very lightweight front end, and then I was pretty strong on the back end in terms of building database stuff. And so what a tool like SharePoint allowed us to do was kind of scaffold a product because it handled like the authentication and some of that deep content management stuff. And we could basically write HTML and have database technology like around their core that like, let us make useful things. And so, you know, we were able to make useful things without having the bench of talent that we have now at ka, you know, and prove out that, like, there was value there. And then we've just gotten. We've grown the team and we've gotten deeper and more experienced. Experienced over time. Does that answer your question?

Yeah.

Yeah. I feel like the whole idea of spooling up web pages like early websites. So even before the time period you're talking about when I was learning how to code HTML by viewing Source and using a text editor before Go Live, Cyber Studio came out, before Dreamweaver came out, and those kind of changed the game. And then you're talking about these other platforms that I was not aware of at all. When I was working in an architecture firm just out of school, they were using a Novell network. It was all running through dos. There was no concept of creating a repository for knowledge in a firm other than sticking it in a file and sticking it in a folder. And it was email. Because architecture has always been based on this idea of mentorship. And so you learned by shadowing project managers and project architects. And that's how knowledge got passed down. And I think just the elephant in the room here is that like that is happening less and less and less and less over the years and over the decades. The mentoring. Yeah, because we're working remotely or that people have gotten so specialized on projects and yet that knowledge exists. And so therefore the need exists before those people retire and walk out the door with all of that knowledge for a firm to become proactive about what is the value of keeping that knowledge accessible to way more people at scale, not just one to one in a mentorship situation. Right. In a firm. And I think it's really interesting to see how long it's taken that idea to crystallize in aec. And maybe that's just my experience, but like, I know a friend of mine, Adam Wilbrecht, was the chief Knowledge Officer at Cunningham Group. Right. And I had like, obviously that is not a well used title in aec. I'm sure. We're seeing it more and more. But, but I mean just, just kind of thinking about those ideas of like the way that we used to do it in, in architecture was very much like the mentor to mentee.

Sure.

Can you just talk about that, like the value of knowledge capture and why you saw that, what, what excited you so much about that part of your job?

Yeah, I, I think there's a lot of ways I want to. I'm not trying to pick my spot here in terms of how to approach this. I think maybe I'll start by saying, you know, knowledge management's a pretty broad space and on one hand you have the kind of the mentorship thing which I think is critically people learn through experience. I don't think that's going to change. I think it's true. And you're right. I think that the mentorship we're hearing from our clients, that mentorship is a continuous challenge, but also people are pouring energy into it. So on one hand you have that very. Like in km we talk about tacit knowledge and explicit knowledge. Right. And so that tacit knowledge is, you know, from the Latin taciturn meaning silent. So it's this knowledge that you don't even necessarily know that you have that you gain through experience where, you know, if you've ever watched a CFO look at a spreadsheet and within a quarter second they're like down to the problematic thing of why it's not all working like. Or a pilot flying a 737 like they don't necessarily even know how they do what they do. Right. It's just this like deep experience. And I was. Explicit knowledge is things that can be written down and shared. And so like on the explicit side, what I really saw a huge opportunity was. I mean this sounds really basic and simple, Evan and Randall, but this is like, this is what it was. It's like how many projects has this firm done that are higher education projects that are over 100,000 square feet in the last five years and who was a project. Project manager for it? There's a right answer to that question. But what you saw at the time, and maybe you still see this, but one of the things we want to attack is Deltec or the CRM has one answer, there's another answer in some other system, people have different answers in their heads and integrating systems so that there's one source of truth and it moves between systems and getting the connection between those two things. So if we get the right answers, like if I can get to who was the PM on this project that was like the thing I'm trying to build or the one I'm pursuing, then I can have a tacit one on one, like I have a conversation with them. And so better explicit data led to better tacit knowledge transfer. Or if I'm looking for a mentor, maybe it's not in a formal mentor, like this person meets with me once a month or once every three months. Maybe it's like I'm looking for the person who knows the most about rain screens in the company, you know, can I get to that person so that they can give me some advice? And like that's what we saw. We don't really do anything with the mentor. Like we explore the concept and we've had people talk about at our conference. But in terms of technology, like connecting people to people and people to information, like that was a huge opportunity. It still is a huge opportunity. And that's something we went after.

Yeah, I was just going to ask Chris, can you talk a little bit about, you know, what about the scale of these firms and at what scale does does the ability to transfer and share information start to break down and what have you seen over the years as far as that's concerned?

Well the only responsible to answer that question is it depends. So I think from like the 35 person firm to the 2,500 person firm, like there are knowledge information management challenges. I think that what you know, at different, there are like different sizes that firms go through where they as just as businesses. If you take knowledge information management out of it for a minute, like when you go from a 30 person firm who's probably what, three to four partners, you know, a couple associate principals, it's probably the founding team that's been in there. So from a knowledge perspective it's, that's a set of challenges. When you get to be, I don't know, a 60, 80 person firm now you've got some new principals who weren't there when it got started. You've started introducing directors and managers into your structure. Maybe you've added a couple locations, maybe you're in a couple of different market sectors. And so as you add complexity and layers, you see I think more and more challenges and more and more opportunity. But on the flip side you have more resource potentially to deploy. And so one of the things that I've always found to be true is that the smallest firms say, you know, we don't have the firms, we don't have the resources. The largest firms and the larger Firms say, like, well, I wish we were as nimble and able to make decisions and turn as quickly as the smaller firms. And so everybody's got their challenges, everyone's got their opportunities. But I think what we've seen is more. You mentioned the chief knowledge Officer at Cunningham, like, since we got started, like, when I first started the company, we, K Connect, which is the name of our conference. The intention of K Connect in 2010, which was the first one, was to get the 15 or 20 people in the country who were working on knowledge management and AEC together in a room and just learn from each other. It was really. That was the whole intention. And 80 people showed up instead. And so what turned out was it's not that there were 80 knowledge managers in the industry. It's like people were really interested in solving this problem. And I think. I don't even know how many there were at the time. There were maybe 20 people with knowledge in their title. In AE firms, it is every year that's gone by, it's escalated, especially over the last two to three years. Like, it's now not only people with it in their title, but like departments. And like one of our clients, Turner Fleischer. Right. 250 people. They have a knowledge management department and they've got four or five people working in there. And so that is like a really interesting change. And I think that's partly. That's partly awareness around knowledge management being a thing you can do. I think it's partly the complexity of business changing and just the velocity and the amount of information and knowledge being created. But I think what it's also been is recognizing that people were doing knowledge management all along. They just didn't call it that. So in order to evolve your business and go from 30 to 80 to 120, whatever it is, in order to last 30 years and go through ownership transition, you are. If you didn't transition knowledge, then you would have gone out of business. And so in order to. And when new technology comes along, you either learn it and teach other people how to use it, or you go out of business. And so people have learned to do this. I think it's a recognizing that you can be more intentional about it and strategic about it. And that has been a major change, I think, for folks, if that makes sense.

Yeah, I'm glad you brought up Turner Fleischer, because I had Ellen Bensky on my other podcast, who's the CEO and the cfo. We talked a lot about knowledge management. I mean, that was really the main Topic of that episode. I'll put a link to it in the show notes for this one. So if people are interested, they can hear the Turner Fleischer story there. But that intentionality that you just brought up is to me the key. And we all had data in files and there's the structure, right? There's data, then knowledge, then wisdom. And the knowledge part, the reason that word is so important is because it is taking best practices standards, things that the firm like actual IP of the firm and the knowledge encapsulated within the people of that firm and making it available to everybody. And for Turner Fleischer, and with what Ellen was talking about, really, really saying like, this is so important for the future of our firm so that there is like one place that people go and get that information. I mean, we all know what it's like to drown in the sea of Google doing a search for data and not knowing if that data is quality or not, not knowing if what ends up on the first page is what I'm really looking for or not. And it becomes like looking for a needle in a haystack. And so firms, I think to your point about intentionality, saying we already know the answers to this stuff, but people are spending hours going outside of the firm looking for this information. At that level we have the knowledge. Let's make sure that our people are armed with that proper knowledge, at least as a starting point. And then to your point earlier about connecting the right people to the right people in the firm, who are the ones who, if I have a question about range screens, I need to talk to that project architect over there, right? Like that to me is really what we're talking about here. And I think it's really interesting to create a product around that idea. And then from my, when I was running digital practice at HMC to deploying it and getting people to actually participate is a whole other challenge, right? Because again, there is a barrier for people to spend the time with that intrinsic or tacit knowledge that they have and put it into a terminal so that it can live on for other people. That is an entire other battle. And I don't know that we really want to get into that today, but I just want to bring it up because it's real, like actually adopting and getting people to contribute and participate in these systems. The same goes for any technology, right? Like there's no magic bullet. Like you can't just buy the thing, deploy it and say, everybody, it's going to be amazing. Like that's not how it Works. Right. So I thought I would just chime in with that there because if people are interested in hearing how a firm actually did it, I think you'll be interested in that episode to hear what Ellen has to say. And I'm sure you have a lot more at all different scales, right? For that kind of a. Yeah, yeah.

I think what's different, I think you're on. I mean, we realized really early that it's not just software, it's people in process as well. And that we had to invest in creating the process and telling stories of the people. Like we had to do case studies and best practices in order to make this easier for firms to adopt. Because here's what's different. Like I'll take a. I'll take open asset. Right. Who does like image management or I mean, I think, correct me if I'm wrong, Randall, if this is an unfair characterization, but you don't have to get the whole firm to change. Like synthesis, like a knowledge management system really touches everybody and it's cross discipline, cross department, and it requires you to change. If you're implementing a CRM or a digital asset management system, you have to get the marketing department to change and maybe some business development people. But to get a culture of knowledge sharing within the company, that's a firm wide effort. And so. And when firms do it really well, I think a lot of times they're already doing it well in pockets. So they have a really good learning and development program or a nascent learning and development program, and maybe somebody's got a good project database going on over here and then somebody's doing internal communications. But I think what's not all the times happened is realize that there are like 30 different efforts going on and that if we could kind of combine them and like magnify the force of our effort and tackle and harness that at key business challenges that the company's facing. You can make the sum of the parts add up to more through the intentionality and through the focus. And so I think what I was trying to say is you have to really. You had Ellen on your podcast who's a CEO, right? And I'm not saying you need a CEO to be leading those efforts. And Ellen isn't anymore. She now has a director of knowledge management who is. But there is a kind of ethos in the business that believes that like sharing and helping others grow, like not only is the right thing to do, but it's like it's a business, it's a business advantage because it is There's a lot of inertia that you have to overcome. But once you do, you start getting some momentum behind you and you get a flywheel spinning in the right direction and you get stuff happening and that's exciting to see.

Yeah, I guess one way that you can think about knowledge capture inside of an architecture firm is ultimately manifested in the, in the projects that they're working on. And you know, the, the process and the knowledge it takes to get there though. Right. I think is largely what we're talking about. Can you, can you talk, Chris, about one the different forms that capturing that knowledge takes? Right. There's obviously mentorship, one on one conversations that happen. There are, you know, somebody drawing or drafting a detail that goes into a library is a form of capturing that knowledge. Redline markups on, on that detail might be another form. Can you talk about what you've seen, different kinds of forms that that knowledge capture takes and then maybe how you've seen that change. Like is video becoming more pervasive way for people to record things or audio like this?

I think there's kind of two questions, Randall, in there. It's kind of. One is kind of the spectrum of different ways that you share, whether it's project knowledge or beyond. And then there's kind of like means and methods in terms of different technologies. So this is a graphic I developed a few years ago and can link out. I think we're going to link to it in the show notes. So it starts on the left with like information systems and this gets into like, you know, from a project lens, something like a project database. And again it's that thing of like what did we work on? What were the key features of this project? Was it a lead project? Was it a. What was the delivery method of this project? Like all the kind of things you'd want maybe into like a dam to have, you know, images about that project all the way to like we'll kind of like keep moving. Going to skip over the information management piece because it's not as important to this piece like research and development again, that's another one of these things like knowledge management, which I think were around 10, 15 years ago, but have become more and more. You see more and more firms with directors of R and D and R and D programs and really investing there. And so on a project research level that's anywhere from. For this specific project we'll conduct some research to solve this specific design problem or go after this design opportunity to here's a way we can do this Whole set of buildings better or tackle this whole set of systems better. Obviously post occupancy evaluations aren't new and client feedback, but there's a whole system there around ways to do R and D around projects. This gets into mentorship like we had talked about before. Learning and development is a huge piece of this and finding ways. So let's say for example, you do things like defined standards or kind of core systems that you're going to use. Whatever it is, whatever the knowledge you've accumulated over time, you distill that they say like this is the way or these are three or four ways to do this. And that could come from lessons learned. There's then delivering that into the practice and getting people to adopt it so that new projects can stand on the shoulders of projects that came before. So there's a whole bunch of different kind of techniques that get used to, to do that. And there's more in this diagram than go there. But I just kind of like, I wanted to hint at the kind of the breadth of the different kind of like strategies, you know, that firms use. And then in terms of technology, I think it's just been, you know, technology's always been expanding, but certainly as you see things like, well, video has gotten much. We have video heavily used within our product. We see it getting used more and more. We're moving into building an LMS and a learning management system into synthesis, right. To kind of deliberately acknowledge the fact that that's there. Obviously things like teams exploded during the pandemic. And what's been interesting is it creates. There's sharing knowledge within the project team, which is something that teams is really, really good at. And they're sharing knowledge across project teams, which is kind of more where we focus. So there's just like the hyper. There's just so many details that go on within a project team. So we've seen like teams or slack or something like that being really, really the place that's happening. And then when you pull back like, hey, we learned something on this project everyone can benefit from, or we've updated a standard or there's this new technology we're using we've seen that's kind of like how we play alongside something like a teams. Does that make sense?

And that's where teams and Slack really suck because that's where the information gets so granular. And to your point about like, okay, this piece is important for that applies to the practice or to this market segment or to the studio or the office or whatever. And again, the mindset shift that needs to happen in individuals in the firm to see that and pluck that piece out because it's overload. If you were going to go into a teams channel or a slack channel on a project and scroll through and try to find something useful, yes, there's a search, but are you searching? There's no keywords. Right. It's just whatever was written at the time and there's shorthand in there and there's just a flurry of responses. It's absolutely a place you go if you want to drown in information. So to have somebody, maybe it's a PM or somebody on the team who's responsible for identifying, noticing that kind of stuff, plucking it out and putting it in a place that is the single source of truth for that kind of thing, that could help other people elsewhere is a mindset shift that's incredibly difficult. And I'll say like this periodic table, if you think about it, I love that you made this map for individuals out there who are thinking about or looking for better ways to manage their knowledge in their firm. But think about it at a even bigger scale in the practice level. And it's a Tetris board. Like it's insane. All of the other pieces there are to this, there's content management, there's design technology, there's bim, there's templates, there's graphics and marketing and HR and onboarding. And I get. It gets like it's a crazy amount of just wrapping your head around what needs to happen in a modern architecture firm to kind of build this foundation for success is kind of, again, it's one of those overwhelming positions to be in that leadership does have to acknowledge and deal with over time.

It's daunting. And I think we have a research council here at KA and they were the first people to see an earlier version of this diagram. And what I expected was like standing ovation. This is amazing. And what I instead got back was folks were depressed because they looked at this and it looked like I thought I was doing great. And now this looks like Mount Everest all of a sudden. And so what I learned from that initial time I showed this was to always then step back and say, and the goal is not to fill out this board and do everything one of these at a, at a five star level, right? It's. This is a shopping list, not a to do list, you know, and you pick and choose these components you need from here, given on whatever the biggest challenges or opportunities your firm is facing. This year and you just go, make the firm better. And then you do the. You figure out your big challenge the next year and you make your firm better again. And there's a way that this can get overwhelming and lead to inaction. And so what I hope that what happens is people look at it is like, oh, so I can combine the forces. Like an example I used to use a lot and still think is powerful, especially when firms, you know, there's this. If you go, we haven't been talking about marketing at all, but if you think about it from the lens of marketing, who's trying to keep up with blog posts and tweets and video, whatever, they're kind of like content marketing or whatever their thought leadership campaign is, they're continually having to come up with interesting things to say and that, you know, you need a pipeline, an editorial kind of like pipeline. And by connecting that external messaging back to your internal knowledge management, you can really help accelerate that. So by having people share, you know, what's interesting, what they're doing, that's just marketing just can like eavesdrop and be like, totally. They love that there's a story, you know, so it's by connecting forces, you know, using something like this, you can really can become more effective.

That's leverage. That candy store is an amazing. I've seen, I've talked to those people and they want to be in every meeting because they just want to be a fly on the wall to hear that little spark of something that they can go, then ask about. Sorry, Randall, go for it.

Well, I just want to pick up on that. The way you just described that person is exactly who ends up becoming the knowledge managers, firms, the people who are in a meeting and they're looking around, they're like, is anyone writing this down? Like, totally. You know, like magic is happening here. How, like, how are the other people going to find out about this? Like, there are people in every firm that think that way. Right. And they end up working on this stuff because they get it.

Yeah, Yeah. I think the, the challenge, you know, I probably overuse this dot, you know, dots versus lines. You want more lines. You have to take these little. All these moments. Because as you were saying, Evan, it's like you end up just an overwhelming amount of information that's being produced. So if those are all the little dots, it's like futile to think that somebody's going to be able to, you know, navigate, find those, put it in context, all those types of things. So I think I'd be interested to Hear, Chris, just what, what you've experienced over the years, like how do you ultimately, you want people to distill that, which means they need to publish. They got to think about it, they got to distill that down and then ultimately they've got a, they're going to share it, they become a publisher of some type. I'm either going to give a lecture or I'm going to write a white paper on this or I'm going to, you know, put it in something that can be passed on besides a one on one conversation. So what have you seen happening on that front?

I want to, I want to tag, I want to tag onto this before Chris answers because there, there's like a, for me being a content creator and creating a lot of stuff, I'd rather have it good than perfect. And to like the mindset around putting the burden on somebody to craft something that goes on these Internets, I think is that it kills a lot of people's motivation to do anything. I just wanted to put that in there because like, there's a lot of content creators out there nowadays on YouTube, on TikTok, on Instagram, and it's just like just pumping stuff out because like that's how we get the story that, that is the thread between all these things and see who they really are. Because they're, they're being more authentic and they're just putting stuff out there and I find that to be valuable. I just wanted to throw that in before Chris ran with that.

Yeah, I feel like I'm picking a spot. I want to answer by going back a little bit to where I left off on the last piece, which is, I think it's good if you can bring ease and joy into this process. Meaning there isn't this fear that we're not capturing all the knowledge. Because the truth is, no matter what you do, you're not going to capture it all. Like, you're just not. It's not going to happen. And so you need to then decide which knowledge is more important than others. And you know, it sounds very obvious, but a lot of that connects back to, to the extent a firm has a formal business strategy or kind of what they're doing. If you've got something formal you can connect to that, that's great. If you don't. And this is what the best knowledge managers do, is they're very good at spending time with key leaders and understanding what's important to them and what keeps them up at night and then figuring out ways to move the needle on problems they care about. And sometimes that's new systems, sometimes that's a specific. Maybe it's a quality assurance manual. Maybe that's the thing. Maybe people are worried that the quality is slipping and they think the solution is a quality assurance manual. They write it, it doesn't move the needle. Then they realize they need to do training, then they realize there's a mentorship problem, but they know what the problem is, quality or whatever the kind of the thing is. And so I find that the firms that do it really well are always doing it through the lens of moving the needle for the business, not trying to solve the knowledge management problem problem. Because that's a. It's just going to keep depressing you because it's just the amount of knowledge keeps exploding. So that's kind of like a. That's one piece of it that I think is kind of like a make sure you have your strategic house in order piece. And then I think on the encouraging people to share, I think that was kind of part of this too. And to not let perfection be the enemy of the good. We have a. I want to overly simplify our product, but there's kind of two components to it. There's the kind of kind of pages side which is more usually controlled in terms of who can write that. So the person that publishes the time off policy and the standards for QA and whatever it is that is kind of more governed, essential content, like really control at firmware level. And then we have posts which are wide open at firms and so anybody can share. And so the thing that synthesis did, I think that was unique in the beginning is put those two things in the same set system. And there was a lot of trepidation in kind of the early 2000 and tens around letting anybody in the firm share both at kind of like a perfection level. But are they going to say something they shouldn't? What if they say the wrong thing, like all the control? And I feel like mostly that's gone now. Some of that's maybe just time passing. But I think what folks have realized is when people share stuff that's imperfect, maybe even incorrect, then it can be corrected. Now it's visible and we can have a conversation about why that's either not right or why there are other options beside that thing. And it can lead to discussions about this versus it just being things that are done out of sight, maybe in emails or just face to face conversations, if that makes sense. So you want to surface the perfect knowledge, but also the imperfect knowledge because that has benefit as well. Does that make sense?

Yeah. And there's documents that. So the idea of like Wikipedia and wikis is that these documents are living. And what's interesting about kind of the old school data, and I know Randall, you deal with this a lot because you're dealing with content like there's no expiration date on these things. And that is very unfortunate, I think, because that leads to a mountain of information and it's like, where. Why do we still have that thing in our system? It should be gone. And the idea of dead documents versus living documents, I think is maybe an interesting way to put this out there in context for people. Because the idea of Wikipedia is you have some editors who are constantly. They have a great idea of what's in that and what needs to change when something new happens. And that's a difficult task for people to maintain kind of a working knowledge of the most important documentation, even in their group, in their firm, because that could be a large number of documents. Right. But this idea of living documents, most current data, getting rid of the detritus, the stuff that doesn't need to be in there anymore, and, and really moving away from files to databases and updatable living documentation is a key piece of context that people really need to understand when it comes to.

With analytics that show which ones are being used and which ones are. Like, yeah, all that plus process. And so I can maybe put this in the chat or not, but one of our clients pioneered a process that we, and she then shared at K Connect. And we put across all of our clients now around content maintenance. And it's a pretty simple process. But again, a lot of the things that work are. And it's about, you know, hitting different areas of the intranet multiple times a year with the content managers and still making sure this stuff is valid. And it doesn't take very long once it's structured. And it's just like, you know, it should be the same thing on a website is like making sure that that website is still saying things that are true. And this is still our best knowledge.

I have a small website and that is hard. Like it's, it's. I can't remember what I wrote where. And there's no flag that automatically goes off when there's better current information that I need to swap out. And it's like somebody has to be responsible for that.

Yeah, I think part of, part of that challenge is that different kinds of information, you know, some, some information is eternal and other information.

Exactly.

Yeah. Some, some Very temporal in nature. So know, it's like style. You know, I can go into my closet and I've got concert t shirts from 20 years ago that are, are even better today than they were 20 years ago. And relevant. Like I don't want to wear necessarily. It's pictured.

Rush. I don't know what you guys are picturing.

It is Rush. I'm reading Geddy Lee's book right now.

I just ordered it from the library yesterday, so. Okay, good.

But, but it is an interesting, you know, on the like, technical front, things that we're working on are. You're right, Evan. People, people, you know, it's like digital wasteland. People never want to throw away anything away because you, you never know. I might need that. But you know, I think you can, you know, technology can come to play in this, in that, that things can have a, a fall off value over time and you can let that decay. And if that hasn't been touched in a long time, there's a good chance that for that project type or something that, that maybe it's not, you know, in style or in vogue anymore for whatever reason, that it's not as relevant. But other types of information, you know, is evergreen, like you said. Chris, I think it's.

Yeah, you're right. So like in our search algorithm, the way we try and split the difference there, right. Is we a factor for waiting for search is freshness, but then we counterbalance with that with usage. So it could be that something's old and used all the time because it's still accurate. And so that's a piece of a way. But yeah, it's a perpetual challenge and you know, evergreen in one person's eyes versus another person's eyes, then it can become a little subjective.

It's very contextual. Yeah.

But I think as we get into more and more AI work, I believe that's going to bring this issue even more into focus because it's things that were. Sometimes the perspective could be, hey, in the old days, right, these files were out in the network, they're out of date, but who cares? Like there's nothing. They're not going to. So don't use them. You know, as you can move more into like the Internet world and Internet plus AI world, it's like, yeah, but you're getting incorrect information because you have outdated data and oops, you know, or you've got conflicting information because your standards change, but you still have both sets available. And so I think that that's going to raise the visibility of this issue and then hopefully, I think, also provide some more inspiration to manage more tightly.

No, it becomes it. That falloff value. Right. Of, of, you know, what is the time frame that something's relevant. I had a, A friend that worked in different industry, but he was an engineer, ran engineering teams for a large company. And he was telling me about, you know, that. That at one point they had to say that people were bringing things that came up in meetings from like a year before, you know, bringing it into a meeting. But we said, or you said something, and he said they had to put in a policy that said, you know, if it's over 30 days old, it's irrelevant because things have changed. Right. You know, we have. We have more information, and what we said a year ago may or may not be relevant anymore. So you can't count on that. So there is. There's definitely a falloff value. And I think it's the trick then is classifying. Right. Structuring information in such a way that we're able to classify it and determine when should this stick around, when should it go away, and trying to ultimately automate as much of this as possible. Because I'm sure, and maybe, Chris, you can talk about this, but, you know, ultimately, it's a rare bird that wants to be the person who has to go put all that information into a system. So it's almost like you have to try to gather up as much of that as part of a byproduct of what people are naturally doing every day as part of that process, or else, you know, these systems get stale and old because somebody, you know, didn't. Didn't keep information up to date. So maybe you can talk a little bit about what you've seen and how you see that evolving over time just from a technology standpoint.

Well, actually, I can talk about it on the technology standpoint, I think from. From a mindset standpoint, because I really do feel like that's the beginning. That's the most important lever you have is mindset. Right. And to the degree to which businesses are able to create space for people to work on the business, not just in the business, is a big separator, because maybe you've got really talented project architects and project managers, and the best use of that person's time is not building these systems, but if you can dedicate some resource to making them as efficient, as effective as possible, that seems like a really good use of energy and resource. And so I think that kind of ability, what's the. It's the Eisenhower quadrant, right where you've got the things that are not urgent but important that get missed a lot. And I think KM lives in the not urgent but important quadrant. Like that's the. Because everyone will do the urgent important, you know, and a lot of people do the urgent and not important just because it's loud. But it's that other quadrant that's like that really separates the firms that are kind of. What got my attention of knowledge management was a conference that I went to in like 2004 ish that again the second reference for Zweig Group. But they had put on a conference called the Firm of the future. So 2004, 2005, something like that. And it was like MIT Media Lab was there, Gensler was there, Kieran Timberlake was there. WebCorp, who was a really progressive construction firm at the time, was there. And they were talking about these kind of innovative practices that we're doing. And I was really impressed by what I saw that kind of Firm of the Future idea look like. And what I kind of distilled was common between all of their stories was it involved using knowledge. Weapon's not the right word but like using, using knowledge as power, like really intentionally building strong knowledge, foundations and practices and then using that to do whatever, do better design, win more work, whatever the core things is attract more talent to just really use that as like being a really well run business as an advantage versus just do just doing great design because it's not, you know. And so I felt like you saw a firm like Kieran Timberlake who did great design with an amazing R and D capability attached to it and they were just a hero firm for me. I'm like that is that is it right there. So I do think there's technology pieces that go behind it and firms can do better or worse at that. But I feel like that mindset of like we can build a solid platform for all of our people to be more effective. By platform I don't just literally mean software. I mean like the business is a platform to let people come here and do their best work. And that, that is valuable. That is as valuable as the work itself because you're enabling other people to be really effective. Does that make sense? I feel like I went a couple different rows.

Yeah, yeah, totally. I'm so glad that you brought up that Eisenhower matrix because the idea of where KA lives in that is the behavioral shift that needs to happen in firms to understand why that's important because we do live in the urgent. But not important because guess what? We're busy over there, right? And because we're so busy, then we don't have time to do that. And so you talked a little bit earlier about making it easier for people is that I want to shift the conversation more towards your latest release and maybe talk about what you're doing with Ka6 or synthesis6, I should say, because the idea here, to me, I would imagine that a big part of that is making it easier for people and making it more extensive so you can go in other directions. Directions as well with your platform to offer things like you mentioned earlier, like an LMS and things like that and getting away from SharePoint. So is there. Because I know, like working with SharePoint at my old firm, it sucked. Like, nobody wanted to use it. And that was. We didn't want to build an intranet on SharePoint. And I know SharePoint has evolved a lot and so I'm not familiar with the latest version of it. But that is an option for people, right? Like, if you're in Microsoft house, that might be a valid, totally valid option for you. But at the same time, like for us back then, it was so cumbersome, it wasn't easy at all. And that is a huge barrier for the people who are busy, right? I don't have time for that. It's hard. It's actually just a mask to say, like, that's too hard. I don't want to deal with it. Right. I have other stuff that I'm busy with.

I got to do the design mantra that we wrote for Synthesis six, which was simple and more powerful. And so we believed that we could both add capability and make the product easier to use at the same time. That was really what we set out to do. And the person that we had in mind, like our hero that we were designing for, was an HR manager or an engineering project manager or someone who owned a subset of content within the company. And they needed to get their stuff out to people so that people would be good at doing their jobs. And maybe they don't touch it again for three months or six months or nine months. And when they come back in and they need to make an update or add something new or whatever it is, they should just be able to do it. They don't need training, you know, they don't. It doesn't need to be extensive. Like it really should just we should empower those kind of like we call them content editors, right? They're not the knowledge manager, you know, they're not the global administrator. They're the person who just has some stuff, and that was who we targeted with like, just ease of use of making it really easy for people to use the platform. And it was, it was, it's. It's been very validating to see that it worked and to see that what's happened as a consequence. So the HR information is always getting on the Internet. First of all, there's a department that does it, and it's critical. Like, you have to have your employee handbook and you have to have these things. What we have seen now in six that people are able to get onto the Internet is the deep kind of like practice content, so, you know, guidelines on how we work. And not just at the overall, like, BIM manual, because again, there might be an overhead person that can do that or a partially overhead person can do that. It's getting into. No, this is the hospitality practice putting in their kind of like, standards and like, here are some sample sets and here are the key people and here's key terminology. So if you onboard into doing a hospitality project and you'd been working in retail or whatever it is, you can get up to speed on, like, how we work, what matters to our clients. And so because we've been able to make the software easier, we've been getting access to that deeper knowledge that we always wanted from the beginning. And more and more firms, if that makes sense. And so because they wanted to do it, like, some extent, like, technology won't solve it all, but, man, it does have a stake in it. And if you can make it really easy for people, they want to get it out to us other folks.

Okay, congrats on that. We, we talk a lot here about the challenge with intermittent use. Right. Which is what you're talking about. It's like, that's really hard from a design standpoint. So as much as you've been able to crack that, I think it's one of the huge wins in developing a good piece of software. And it sounds like we probably share that. I always think it's a win when things got. I know they got better, but they got simpler. That's when I always look at what we're doing and be like, wow, we actually simplified, took things away, which is hard. And that gets back to that usability, that intermittent use. If you haven't touched it in three months and come back, it's like, do I know where to start? And it's not that complicated. So congrats on that.

Most powerful tools in the AEC toolbox only get more complicated over Time. And if you. Randall, we've talked about this and we actually it recently came up on my other podcast with Nicholas Catelier who runs Revit Pure. And this is a consulting practice. He does courses and training, but he publishes these PDFs and he put one on LinkedIn. Just showing the Revit Stair tool as an example of what. And it's this crazy diagram of like all the different pieces and parts of what goes into the Revit Stair tool. It is seriously an application unto itself and it is one tool inside a 20 plus year old code base. Right. And it is more and more and more complicated as the years have gone on. And like nothing has ever been taken away. There's been no expiration date because old projects rely on it. People's muscle memory relies on it. There's so many reasons, right, to do that. Do you have examples of how you made synthesis six easier? We don't need to get into the whole screen share and how you move this button from here to there, but I mean, what are the kinds of things that you're talking about when it came to how did you actually make it easier for people to input their knowledge into the system and share it with their teams?

Yeah, I'll give you kind of a philosophical answer and then maybe I can try a screen share and short of that we can hand wave it a little. There's a mindset. I mean one of the huge influences on us as a company was 37 signals and they're writing the guys from Basecamp and they're writing about business and software. They were really starting to get well known right when we started. And so there was a book called Getting Real. There's another one called Rework. They have multiple really good books. And one of the kind of concepts from them is to let your customers outgrow you. And what they talk about is exactly what you described. There's this kind of bloat that happens in any piece of software, no matter how clean and simple it is when it gets started, then you start listening to your customers and then you start adding just this thing for this one and then this one for the other one. And, and especially if you're an enterprise software. So you want to close this big deal with XYZ Large Firm, or you've got XYZ Large Firm and they really are unhappy unless you do this one thing. And then so you do the thing and then the next thing and then the next thing, and before you know it, you've made the thing really, really big. And so what we've tried to do from a mindset perspective is to not let any. Not let. We have large firms that we work with, and we love that, but not let that drive our product roadmap and not let any one firm drive our product roadmap. We have to stand back and kind of understand. We see that our subscription revenue as like an innovation fund, right. That we're supposed to manage on behalf of all of our clients in a way. Like, we want to be like effective capital allocators to really important things. So we want to invest in the things that make the most impact for the most number of clients. And so. And not make the product too hard to use. If we make the product too hard to use for that HR manager or that engineering person I talked about before, we've lost. And so we. The thing that we doing can't come at the cost of making it harder for other people to use. So I feel like that's like a. That's just. The mindset is like, if anything, we want to try and continue to make it simpler if possible and be willing to lose a client or 2 or 10, if that's. Or not win a deal if that cost were to come at simplicity.

I 100% agree. And it's a challenge. You know, I've, you know, once a quarter, we'll review all the, you know, I've still worked with the product team here at Mellon. We'll. We'll review all of the requests that come in from customers. You know, it numbers in the hundreds, right? So the process that we go through is to try to, you know, we read it all. And what we try to do, though, is understanding, you know, a lot of, you know, different. Different kinds of customers. Some. Some will tell you what they want specifically. Like, give me a butt. That does this. Here's what we try to do is to back that into what problem are they trying to solve. And then as we go through all of those, we try to see if we can. If. If there's a theme that becomes evident, right, that what people are looking for, then that becomes the target. And then we, you know, our job is to go figure out what's the best way to solve that in the most elegant, you know, design way instead. You know, I think, Evan, what you're alluding to is, you know, if you just take a feature request and you get an engineer to say, can you do this? They'll say, yes. And there's a new button over here that does that, and you end up with a frankenstein And I think the real challenge is to, you know, I think about some of the sports, you know, stellar athletes, you know, they will perfect their craft and then they've got to be willing to, like, break it in order to get to the next level. So it's like, it's really hard to start to take stuff away. And, man, people kick and scream and, you know, as you said, Chris, you know, sometimes you're going to lose customers over it. But, you know, that's leadership. Sometimes you have to be willing to say, we're going to lose a customer because we're not going to. The customer is not always right. Customer's always got an opinion and the customer's got a problem that they're trying to solve. But if you let them design and develop your software and platform, it's a recipe for Frankenstein.

And we see they might be right in their context. Right? Yeah, but we have to look across, you know, or, you know, here's what happened. Like, we had a list of, like, we cut a decent amount of. When we're built on SharePoint, we inherited a lot of complexity because SharePoint. SharePoint. Right. And so there were just things we just absolutely did not bring across because we thought that they were marginal. We had the data to show that they were marginally used and that they were confusing. It's been really interesting to see that that didn't really cost us any. Like, it didn't really have the impact in an adverse. Like, people appreciated the simplicity. And so it didn't. Like, there was a list I have on Trello of the dogs that didn't bark in synthesis. 6. Like, we thought this is going to be a problem. We're going to have to build this. After we get version 6.0 out, we're going to be coming back to this. And it's amazing how many of those things aren't a thing and the things we're actually going to be working on. And I feel like this is the best decision we made was we didn't commit to any roadmap. So that that re platforming of the product took about five years from start to finish, from research to, like, getting it into general availability. We didn't commit to any features after we shipped that because we knew that we needed to get it out into people's hands and talk to folks and understand, like, what's next, you know, that we should build. And so after, you know, March, when we went into GA, I did 40 interviews with clients personally. Right. Not just about synthesis and where we should go. But just like industry, like, what kind of challenges they're facing. And what I. What came away from that, to me was we should do something on learning and development, and we should do something with AI and search. Like, those became the two obvious opportunities. And to your point, Randall, they weren't all literally asked for that way. Like, it wasn't. I need an LMS that does this, this, and that. It's like, here's where I'm struggling, and this is what we're trying to move the needle on. People were using the word onboarding a lot as being their challenge. To me, onboarding is a form of a learning thing. It's just at the very beginning of your learning journey with the company, for example. And so I think that kind of. What I would say is the things that we thought might be problems, those aren't what came up when I did those interviews. That wasn't the thing. And so being willing to be able to shed that stuff and go back to it if we needed to, okay, fine, we would do it. But, like, it really generally didn't materialize.

Yeah, you're probably like, me and that. You know, I'll think something's hot. And I just have to give it time to say, let's, let's. Let's revisit this in 30 days and still see if I still think that that's, like, the hot thing. Right. Because, you know, you're always a victim of the last person you talk to and.

Yeah, right.

You know, so you have to. You have to put a little space in between those conversations and sit back and distill those into, you know, ultimately back to the dots versus lines. You don't want to be making those decisions on the one little conversation you had. And you got to give those things some time. When it comes down to developing, you know, part of. Part of this podcast is to talk to people who are developing these kinds of applications and share with people what the methodology and. And how we think about doing these kinds of things. And I think it's. I think, for companies like yours, you know, that are doing it well, this is important for those others that are out there listening that are also developing applications for this industry is, you know, to. To really think those kinds of things through if you want to. If you want to have a lasting, impactful product that you're developing.

So, yeah, yeah, I want to go back to your stair tool, Evan. Oh, sorry, go ahead.

Yeah, no, go ahead. Jump with it.

Well, I'm thinking about your stair tool, and I kind of Answered it kind of at a high level, I think on a detailed level, you know, a lot. My wife is my design partner and we spend a lot of time looking at design precedents that are in the consumer space and that are outside of what we do. At the same time, there are things that we want to do that oftentimes there hasn't been. There's not a good precedent for. And so, but there's kind of like a, you kind of develop a design sense where you kind of squeeze win at something and if it's like, if it's got too many buttons or too many options, you're kind of like decision or choice anxiety starts ramping and you can start feeling yourself like that's too much work to even like, I don't know, I don't want to bother, you know. And some of it's just like intuitive. It's like if you make it to the point, then like people are going to have to spend time figuring out, decoding your interface to figure out what it does and how to start using it. Like, I don't know, it's a. But it's an ethos that it's better to err on the side of. Like make it simple. I don't know, I don't know if I'm saying something original there, but it's like sticking with it is the hard part.

Well, I'll just throw in before you say that, Evan, one of the things that we try to do as we've developed a veil platform we've always taken, we split the world up into the people that are publishing and putting information into the system, those that are consuming. And ultimately it's a 99 to 1 or you some, some huge outsized percentage of people that are on the consumption side. So we've always had a strategy that says ultimately the product is about consumption.

Right.

The necessary evil is the putting. But that should not get in the way of. And everybody, even the people that are publishing are also ultimately consumers or we want them to be consumers. So everything should be designed simplistically from that standpoint. What does it mean to consume from this platform? And then I don't want to say it's an afterthought, but you know, the, for one thing, if you're not a publisher, you don't see all of the buttons and you know, we strip all that stuff.

Absolutely. For sure.

So, so there's, you know, there's strategies, you know, when it comes to how to develop and keep things simple. But I don't I don't know if you have any thoughts, but that's the way.

No, I mean. So yeah, you. Thank you for putting it that way. Because I realized maybe our, our delivery is a little different. We have a middle tier in between the two ends that you called out. We have a global administrators and end users and then we've got those content editors I talked about before or those intermittent people. And that's why we realized like a lot of soft. I hate to quote Steve Jobs, but I'm going to do it. But he had a very famous quote. They had an ad campaign running. I think it was like the G3 or something like that, that where it's like the back of ours looks better than the front of theirs. And his point was like, When we went to build my wife's website, we used Squarespace because I wanted her to be able to. And she wanted to be able to maintain her own content and not come to me to write HTML and to do some of the JavaScript stuff or whatever. Watching that. We then put the Knowledge Architecture website on Squarespace because I'm like, wow, that's powerful what you can do. I hadn't conceived a Squarespace being something a company of our size could use, but it turns out you can, and it's great. We did that the year before we started design on synthesis 6. What that made me realize is we can make the admin features or the editing features as simple and as easy to use as the end user features. And we have to. And if we do that, then we're going to get more and more of those people adding content because what had happened before is we had not designed for that community. And so those people that wanted to get content either had to go to somebody more advanced to add it for them or they just never did anything and they just abandoned the project. And like, you know, I don't want to do it. And so that really forced us to raise the bar on the design because we wanted to go after that intermittent.

Audience and simplify it.

And simplify it. Yeah.

I just wanted to talk about this switch from a platform that you kind of, that you were building on top of to being in control of your own kingdom. Because there's probably a lot of people in our audience and I'm trying to put myself in their shoes, even though I don't make software. Randall, you do. You can speak to this. This idea of being dependent on another platform. Maybe they've got too many things, maybe they don't have enough. They're not moving at the same pace as you. They have different motiv, customers are different. They're building something for everybody, not just you. And then you ultimately taking the reins with this switch to version six, right, and saying, no, we're doing it all because we want to be in control of all of it. Can you just talk about that? Because I know there's a lot of people building on top of other platforms out there, or maybe they're using APIs. Like we all saw what happened with Reddit over this year, where all of a sudden they flipped a switch and said, you're going to pay for all these API calls. And people had built their entire living on maybe an app that was a new, better UI for Reddit than even Reddit had. And so all of a sudden they got squeezed out because they couldn't afford to do that. So that's one possible outcome. Also, maybe just talk about taking control of that and why you decided to go down this path. And just maybe what are the lessons in there for people who are dependent on other platforms to deliver their whatever they're doing?

It was a big decision. And I can talk about why we made it, and then I can kind of get into the implication, like, kind of the how and the implications. We. So we had a fork in the road where SharePoint, you know, they had announced SharePoint 2016, but it was very clear that the future of SharePoint was in the cloud and SharePoint Online was going to be the thing. And so we either had to go the route we ended up going, or we had to port the product to SharePoint Online. So a rewrite was coming one way or the other. And I mean, there's some technical reasons, like the SharePoint, like, we weren't quite sure we were going to be able to build the product that we had built on their cloud product. But it was almost more important that we weren't sure that we weren't sure if that makes sense. We just had no sense of. And even if we figure it out today, that doesn't mean that it's going to be possible six months from now or 12 months about like you're building a house on sand versus building it on rock. And we just didn't trust that it would be okay. And so really it came down to this conversation we had, which is like, I don't want to be in. If door A is building on SharePoint online and door B is building our own thing, I don't want to work in company A. And I don't think the engineers do And I don't think our team does. Not only is it the uncertainty of building, but then if people don't like the way a certain feature works, like, for example, wikis and SharePoint, we had all these feature requests and approving. It's like, that's not our code. It was so frustrating to tell clients we'd love to fix that, but we can't because it's somebody else's stuff, like, brutal.

So, yeah, it's almost.

Yeah, go ahead.

Well, I was just going to say it sounds like, you know, in the early stages you get to take advantage. Your product gets more advanced quicker because you're building on a set of tools, core foundational tools that are there. You get to extend that quickly. But over time, as you matured and understood exactly what you needed or wanted, then all of a sudden the tips to be like, now there's baggage that comes with building on that versus kind of having our own control.

Yeah, 100%, you know, so much so that I think, you know, there's a lot of lessons learned when you do a project that big. Like, one of them is that we had underestimated how much we were getting from SharePoint. I think, I don't think. I know it seemed like it was going to be simpler than it was, but just even getting into things like authentication and giving permissions and different levels and who can do this on this design community versus the marketing community. Like, there's just a lot that goes into building a content management system and a lot of it is invisible below the waterline, like version history and what happens with deleted items and does the things expire? I mean, they're just like thousands and thousands and thousands of decisions you have to make. And I'm glad we got to make them our way. We know why we made them, we know how they're made. We take full responsibility for them. But I think it did accelerate our. Like, we kind of made a deal with the devil. And I'm not calling SharePoint the devil, I should say that a different way, but it let us go faster. But eventually the bill came due that we had to, for the long term health of the company, switch over. But it let us feel like the product was written by a single author, which I thought was really important for end users, because again, that middle tier of folks that we're talking about, the intermittent users, if it's a tool that we wrote, they kind of learn these design patterns. But if it's something coming from Microsoft, they had to learn these design patterns, patterns and so that kind of like whipsawing between two different design languages. And I guess we could have made it simple. In retrospect, we could have made it simpler by following Microsoft's. But like the whole point was to make it simpler. That was the divergence in opinion. So at the end of the day, you got to feel like this is a tool written for AEC firms with a single author. That's simple and powerful and it's made for me. And by the way, if you want to fix, if we, if we want to improve something, like, we can improve the entire product. We don't. We are not limited to the percentage of the product we can improve. That's different though, I think, because what you said, Evan, in your question is people that are building stuff using APIs, we have more integrations now than we did pre synthesis 6. And that is very much on our trajectory to have even more than that. So I think it's more a matter like. And a lot of them were with Microsoft. Right. So our authentication is Azure Active Directory. We've got a light integration with teams now we're looking to do more. We've got some other Microsoft pieces we're plugging into. And so Microsoft's a really important player in this ecosystem. We will continue to develop integrations with them. But I think doing that as an autonomous entity versus being built on top of their tech is the big switch. And I don't think I would have done it differently, honestly, looking back, we didn't raise money, whether venture or private equity or whatever it is. Like we have been bootstrapped since the beginning. And to get to where we wanted to get in 2009, 2010, 2011, in that environment where SharePoint was as important as it was to a lot of firms, I think we chose correctly. We just, like I said, the bill came due and we had to make the move.

And that was a significant investment. I could only imagine, to take that responsibility but ultimately deliver on that kind of not knowing how long that would take. I'm sure you had targets, but did it take twice as long as you thought it would, or how did that play out when you decided to make that switch?

Yeah, I think there were two things that are like, I had a lot of anxiety around the way clients were going to react to the choice that we made. I thought I, you know, I had, I did a lot of like scenario modeling of what it would do to revenue if this, you know, if 20% or 30% or 40% of our clients said, I'll pass you know, and so what I did was a listening tour. Like, so in the first year of design, I talked to every single client for an hour about, here's what. Here's where we're taking the company. Here's why, here's our vision for what it could look like. What are your questions? For example, if you've got these custom things built in, if you've got this, let's just talk through all of your questions and concerns. And then by the end of that, I went into one of the clients that I thought was going to be the most upset about this direction. That was the first one I did, and they loved the direction. Within 10 or 15 of those conversations, I realized it's like, not only are people not mad, they're very excited about the way that we're going. And that put a lot of energy behind our team, and I'm really glad that I was able to do that. And so in terms of projecting how long it would take, we didn't know. And what we told for the first couple years, when people asked when it was coming out, we'd say, we don't know. It's too early to tell. I used this. I had an image that I took going over the Golden Gate Bridge, which is, you probably both know, can get insanely foggy at times. And so I had had this experience of coming home from vacation over the bridge. It was a video, not an image, actually, of it being super foggy on the north side of the bridge. And by the time we got to the south side of the bridge, the sun, the fog had cleared, and you could see where you were going. And I'm like, we are here on the bridge, right? We are 40% over the bridge. We're still shrouded in fog. We know we're on a bridge. We know where we're going on the other side of it. We just can't tell how much bridge is left.

Yeah, we don't know how long the bridge is.

Yeah, we don't know how long the bridge is. And so halfway through, we had a really good idea of how long the bridge is. And we said, it'll be in 20, you know, 2022. And ended up being. When we went into public beta, and that was a little further out than I think. And the kind of. So people had connected. So if you don't tell people what the data is, they make up their own version of what the data is in their head. And so I think a lot of people had assumed it was coming sooner than it was. But again, we were very transparent and honest about saying, like, here's the roadmap. Here are the things still to be built. This is what we're going to end up with at the end. And we were blessed to have a community that was patient and stayed with it and believed in what we were doing. And the retention has been great. And the uptake. We're already, you know, we went into GA in March of this year and we're. I think we're 90% of our clients are in the platform and like 40% are live or something as of within less than a year. And so we're super excited about that transition. So we're going to wrap it at the end of next year. We have a two year kind of migration window.

It's a catch 22 when you get them excited and then their next question is, when can I have it? And then you have to say, I don't know, which is awesome.

Yeah. No, no, yeah. One of our favorite clients that's been with us for a long, long time, they're all our favorite clients, but one of them, his name is Jim. And he said, you know, because I had been doing these every six months, kind of weird demo days of kind of showing progress so that people could see what we were building and get excited and understand it's real. And he's like, I don't think I want to go to these anymore. And I'm like, why not? And he's like, because I'm getting carrot fatigue. I'm like, what's carrot fatigue? He's like, you just keep stringing these carrots out in front of me and I can't keep chasing them. He's like, just tell me when it's done and then we'll implement it. So that was kind of fun.

I think I know who that is.

Along those lines from my developing the product. Chris, did you. You know, it's often overused, but the mvp, minimum viable product. Did you all end up taking and reducing the feature set and getting back to a smaller set of core features to then begin to build back on? How did you all think about that and you know. Or did you feel like I had to get back to feature for feature kind of replication before this was going to be ready for people to begin to use?

I think it was a third option, which was. So the mvp. Yeah. I've got two answers, actually. The first one. So that's what we ended up with. And then how we took it through beta, because those are two different things. We Had a pretty mature product. It was 10 years old at that time. We had a lot of adoption. It's an intranet. So there was a certain. A pretty high level of feature parity that we needed. Or if not feature parity, like we need to take care of this kind of content. It may not be done in the exact same way, but like we are stewards for this content. We need to find a way that you take care of it. But we did cut some features that weren't that heavily used. Like Microsoft SharePoint has calendars. We just didn't know that they actually that important synthesis and turns out they really weren't. We added some things that weren't in five. So it's a little bit of like we took some things away, but we added some new things. But what was really interesting, and this came from Susan Strom, who's our chief client officer, like right before we're getting ready to kind of start doing a beta or getting kind of near the beta process, she's like, I don't think we need to be done in order to get into beta. I think we can bring people into beta tackling some of the core content editing tools and maybe like email notifications and analytics and maybe even search can come later. Like, let's just get people into like making the content. Because again, I've said multiple times, targeting those intermittent users and making content creation easy. Let's validate that and make sure that people can create content really easy. We're not going to be able to be in general availability without search or email notifications or whatever. But let's see how far we can go. And we got a lot of clients in the beta creating content. As we were still releasing features, even what we called general availability, there were a couple things that clients told us. We're ready to go live. Yeah, you don't have 1, 2 and 3, but we're creating enough value. Let's go. And when that thing comes, cool. We just released responsive, I don't know, in October. And it's like, cool. We'll love it when you release it, but don't hold up the Internet for that. And so that was in the beginning of the project. We didn't see that we would be able to do this kind of phased beta and then even kind of release things afterwards. So reducing the time to value is maybe how I'd kind of summarize that.

Sure. Yeah, that's a good way to think of it. Yeah. As soon as something has value, why shouldn't you get it in the customer's hands. Let them decide. They'll decide. Ready for prime time or not. Cool.

Well, this has been a fantastic conversation, and I can't wait to have you back on to talk more specifically about the director's commentary track for synthesis 6. I think it would be fun to dive into one of your design challenges that you worked your way through with your team and ultimately delivered. It sounds like you're in a really cool place with user adoption. I mean, that's something that we see time and time again, is. Adoption's hard. I just want to point out how impressed I am that you actually did deliver a tool that is more powerful and easier to use. I think that is not normal in this landscape of. But at the same time, we see new tools coming out all the time that are an absolute joy to use, and that's why people flock to them, and that's why they're. That's what generates excitement. Right. And I think it's because that's in reaction to the landscape that we've all lived through over the last 20 years of software getting incredibly complex and difficult. Right. So kudos to your team for delivering something that is. That is more powerful and easier to use. And that is, I think, something that everybody should be striving for because we're all feeling the fatigue of our. Of our tools at some level or another. So thanks for taking the time to hang out with us today. And we'll put links to Knowledge Architecture, Synthesis, the periodic table that you shared, Kaconnect, and we'll put a link to you on LinkedIn and everywhere that people can follow you. And so is there anything else that we missed that you want to let the audience know about here at the end?

Yeah, there's one thing I'd like to share because, I mean, I think there's about taking on a big project like that. I'd said before I was a history major, and so I have read a lot of history of technology, and one of the things you hear about these projects is they oftentimes turn into death marches and you end up with people getting divorced. You end up with people their health getting compromised. You end up with people quitting because everyone's at each other's necks. And the.

Sounds like an architectural project. Chris, this just sounds.

Yeah, right. Maybe too much. Too close to home.

Too close to home.

And the thing I said from the very, very beginning is like, we're going to do this with ease and joy, and we're going to find a way. We're going to stay together as a team. We're going to grow. We're going to have to learn things that we don't know how to do. Now you. But nobody should get divorced over this project. I don't want to impact people's health. People should still take vacations. We need to continue to have an emphasize quality of life while doing something hard. And so I think if I could summarize what I've learned at knowledge architecture over 15 years in the spring is we can do hard things with ease and joy. And both of those things are true. And one of our core values is we work on the hardest thing, no matter how important it I mean, the most important thing, no matter how hard it is. And the coda that I've now added afterwards is with ease and joy because I think that that's really, really important. So, yeah, that would be my kind of my kind of ending thought.

Nice. I appreciate that. Anything from you, Randall, to close this one out.

I'm just going to say great catching up and look forward to having more conversations more often.

Sounds good. Appreciate it.

Thanks, Chris.

Thanks, Chris.