Leveraging Tech to Solve Challenges in AEC

A This episode of practice disrupted is supported by monograph, the cloud based practice operations solution built for architects by architects. SectionCut, the interactive virtual conference from our friends at monograph. Learn more at sectioncut.com.

B And Twinmotion, the simple real time rendering solution to create high quality imagery, client presentations, and interactive experiences that help communicate your design ideas fast. I'm Evelyn Lee. And I'm Janine Chastain. We're collaborating on curated conversations to explore how the industry is changing.

A Together, we'll find ways to create new solutions to current challenges while elevating the value of architects.

B Welcome to Practice Disrupted.

A Hi, listeners. Hi Janine.

B Hey disruptors. Hey Evelyn.

A Today we are revisiting our friends over at Outer Labs. If you are a frequent listener to practice disrupted, you may recall that we brought on Ignessa during season 2 to talk about her role as the director of customer success and how there are other opportunities for architects in tech outside of UX design. For our conversation coming up, we're going to flip the script a bit and talk to Jen Carlisle, who is one of the cofounders and CTO of Outer Labs and does not actually have an architecture background.

B So to remind everyone, Outer Labs is a dynamic company that's passionate about developing technology related to the built environment. Their work is a mixture of custom software development for forward thinking technology, and they're interested in radically changing the process of how buildings are created through the lens of software development.

A One of the reasons why I wanted to bring Jen on is really to explore the interest that tech has taken in the AEC space. Why engineers have a shared interest in literature like Christopher Alexander's Pattern Language and what we as a profession can actually learn from their operations and policies.

B Chief technology officer Jen Carlisle has been working at Outer Labs since 2018. Prior to founding Outer Labs, Jen worked at Flex for 5 years as the VP of engineering and a cofounder. Before Flex, she worked at Google X as a software engineer. She began her career as an audio and acoustics engineer.

A Let's cut to the conversation. Thank you for joining us. Would you mind telling us a little bit about yourself and Outer Labs and what Outer Labs does?

C Sure. I'd love to. Outer Labs is a pretty young company. We started just over 3 years ago. My role there is as the chief technical officer and I'm also one of the cofounders. And we are kind of a mixture of computer scientists, architects, engineers, folks from, construction management who all came together and decided that we wanted to work on interesting problems in the AEC space. And so, yeah, my role there, like I mentioned before, I'm the CTO, so I lead everything related to engineering and technology. And, yeah, that role has kind of changed a lot over the time that I've been there.

C You know, when we got started, we were just 4 people, so I was doing everything from, like, you know, figuring out what our what our first project was that we'd land and, you know, writing the code for that. And now I oversee, you know, the engineering team, and I help with things like, finding new projects, figuring out what direction we wanna take the company, if there are any interesting trends in the space, and really just what we should be working on. And just a little bit about my background, I come from a more traditional software engineering background, in school. I studied computer science and also media arts and, spent the first probably 10 years of my career in doing, individual contributor software engineering work. I eventually made my way to Google where I joined Google X, which was a research lab that was just getting off the ground then this was back in 2010 or so and was about just a few dozen people, now it's over 2 or 3,000 and that's how I got into the AEC space. The project that I worked on was was, yeah, focused in how can we reimagine housing delivery at at a large scale.

A That comment comes at an interesting time with everything that is going on with Catara. So

C Yeah. For sure. Yeah. I remember when I was working on my lost company, Flux, when, I first heard about Qatarra and we got connected with them. And, you know, I really thought that they had a, like, a really interesting model and a big audacious vision. I was pretty sad to see it all kind of shutting down. It seems like there was a lot of potential there.

A You know, one of the reasons why we were really wanted to have you on the podcast was because we talk so much about architects who have gone into the technology space. Mhmm. This is we have never had a technologist, essentially, that has come into the AEC space. So I think your role at Google X may have introduced you to the AEC industry. But what has kind of piqued your interest and held you like, why why stay in it?

C Yeah. Well, actually, my exposure to AEC goes much farther back. Actually, my my dad was a, project manager for a home building company. So when I was, like, 6, 7, 8 years old, I was, like, running around these, you know, single family neighborhoods where they were building the where they were building the houses. So it wasn't, like, totally unfamiliar to me. You know, I'd walk around while he was doing punch lists and things like that. So it was a little bit in my my blood, I guess. But when I joined Google, that was when I really got into it professionally.

C And, yeah, I mean, there are a lot of really interesting things that I think kind of piqued my interest and keep me, keep me wanting to to stay in this space. I think the first one is just all of the, like, very passionate people that I meet who are involved in AEC. Everything from, you know, people who are looking at a very large scale, like city planners, down to, you know, people focus at the building scale, down to people focused on, like, a very small individual space. Like, people seem to be very enthusiastic and passionate about the work they do, so it's really fun for me to, like, make tools for people who are so passionate. I think that it's also there there's just a lot of opportunity here too. Like, there are obviously the big players who have been around forever, you know, Autodesk, of course. But I think there's a lot of opportunity for start ups and small companies to kind of find real pain points that people have and then and then tackle them. The other thing that I think is really appealing about this space is the tangibility of it.

C You know, we spend so much of our time in buildings, and when you start thinking about it, there's so much to notice. And until then, you kind of you just sort of take it for granted. So when I started really thinking about the design of buildings and, you know, how can we make it better, how can we make them more sustainable, all those things. Yeah. You just start really, like, noticing the space around you and, it's yeah. It's it's it's really fun to deal with. Sometimes hear the phrase bits not atoms or or atoms not bits. Sorry about that.

C Yeah. Tonight, I think that the AEC space is like a a nice mixture of atoms and bits.

B Why don't we talk just a second about Outer Labs? Because I'd love to hear, as someone who's, like, building this company, what what is your vision? Like, as a as someone who's interested in solving problems behind the creation of a company into an industry that really needs disruption, what is your greater vision for where your company is growing?

C Yeah. That's a great question. So when we started Outer Labs, we decided to take this sort of hybrid path where we do, software consulting work for large real estate owners that want to either scale their portfolio, or they have, interesting, difficult challenges within their existing real estate portfolio, or they want to look at building design and delivery differently. So we decided to split our time between doing the software consulting for owners with really tricky, challenging problems, and developing our own product that or products that, you know, is inspired by the people that we talk to and the problems that we see, and this was also kind of a a pragmatic move too where, you know, many start ups, technology start ups, in particular, go the, you know, more traditional venture capital route, we at Outer Labs wanted to just try something different, we decided to go go bootstrap. So this allowed us to to do that, and I think there's a lot of benefits for kind of going the bootstrap route. You have to kind of really think about where every dollar goes and be conservative. You have to think about, like, how are we going to pay the bills and be very practical about, you know, how are we gonna, yeah, how are we gonna do that? I feel like it just leads to, you know, good, healthy business practices. There's certainly merits in going the venture capital route too, but, having done that in my my last company, Flux, Yeah.

C We just decided we wanted to take it a little bit of a different direction this time around.

A I wanna dig a little bit deeper on kind of the problems or the opportunities that you see in this industry, especially as your perspective as an outsider. We tend to do a lot of navel gazing, and when push comes to shove, I I feel like we take the path of least resistance. And for us, that's what we have always done and will continue to do. So, you know, when you think about, like, problem identifying or seeing greater opportunities in the industry, where is the biggest opportunities, maybe not even just for Outer Labs, to play in, but, for for other things to happen?

C Yeah. So three areas really come to mind for me, as kind of big opportunities or, you know, problem areas slash big opportunities in the AEC space. The first is fragmentation. It seems like there are just so many people and parties involved in kind of the design and construction of buildings. It's, you know, it's you see a lot of rework and, you know, miscommunication. It's really no wonder because there are just so many people involved, and there's no kind of unified ecosystem of tools in which everybody can work within. I mean, some companies are are are, you know, trying to get there, but I still feel like it's a very fragmented process. And if we're able to, you know, tackle some of that fragmentation, even if it's in bits and pieces, you know, I think that can lead to a much smoother process and better buildings in the end.

C The second area is just the speed at which buildings are designed and delivered. I think that, you know, I live in California and we've been in a housing crisis for as, you know, as long as I can remember, and I think that that is echoed in, you know, many other parts of the country, many other parts of the world, and I think a lot about, like, how can we make the process of delivering buildings, particularly housing, much faster because it's just, you know, the population's growing at record speeds and, you know, how how are we going to to keep up with that? I think we need to kind of revisit how housing is designed. I think that's why I was, you know, kind of rooting for Cattera and, you know, it seemed like they were trying to to really kinda vertically integrate the the housing delivery process. And then the 3rd area that I think there's a lot of opportunity is in kind of, the the cost of buildings, like, understanding costs, predicting costs more accurately. You know, like, at the end of the day, whether a project is successful or not. Like, one of the biggest things it's judged by is whether it's on schedule and on budget. And there and this kind of goes back to the complexity and fragmentation, like, so many things affect the overall cost of a project, and it's difficult to, you know, really track that. And, you know, when some element of a design changes or there's a change order because there's a clash in physical space, you know, that's going to have impact on costs.

C And I I just feel like there is a lot of opportunity to kind of, yeah, use data, use machine learning, and things like that to kind of better predict what cost outcomes of building projects will be.

A Yeah. I I mean, surprisingly enough, I I think a lot of architects would actually agree with you. I I just think they struggle with the how we get there.

C Mhmm.

A So we might continue to need outside help with with that.

C Yeah. No. I've talked with all sorts of people particularly about the cost aspects of of building design and, you know, you hear some industry veterans being like, you know, everybody has tried to solve this problem. They've been trying for 40 or 50 years to solve it, and nobody has solved it, so you're not gonna be able to solve it. But then the very optimistic part of me is like, well, it's a new day. Right? There's new technology. We have a lot of, you know, capabilities that we perhaps didn't have 40 or 50 years ago. Like, just because it hasn't been like, that nut hasn't been cracked yet doesn't mean we shouldn't try.

B Well, I think it's a important maybe framework to think about the way that you might approach that problem as someone coming from a technology standpoint versus an architect thinking about that problem. For example, like, they may look at that and say, well, every project design is different, and there's so many variables that aren't transferable from project to project. They change, and there's different players involved, and so that makes solving that problem universally very difficult. But I'm curious maybe from your point of view, if you could talk about the way you might look at solving that problem from a systems thinking standpoint and and particularly a technology standpoint when those variables are all different?

C Yeah. That's a that's a great question. You know, when I think about this, I think about, is there, like, a a template that could get us 50% of the way there? So, like, within a certain typology of building, we can expect there will always be, you know, certain systems. They may be of different types, but there's, you know, probably more than no more than a few dozen types of, like, structural systems that are commonly used. And so we could, you know, think about, like, the structural system and then separately think of the HVAC system, and think of the facade system, and the parking, and basically develop a kind of a catalog of all of the different things that may or may not go into a building, and have kind of a baseline of what that might be. And this would be a, like, a very complex model with probably 1,000, tens of 1,000, maybe even more elements. And but it's, like, it's it's better than a, like, a napkin sketch or rough order of magnitude. And then, you know, take that kind of model of a building and start applying, you know, average costs to it.

C And, you know, maybe average is not the not the right number for it, but basically if we can have a a fairly detailed model of a building driven by the people who are actually designing it and working on it, and then marry that with cost data that, you know, is updated from many, many different sources. You know, there's obviously kind of industry standard cost databases, there are, things you can look at about, you know, futures of different materials. Every firm probably has their own set of how much things cost, but, if we can take that kind of more, you know, sophisticated model, marry it with cost data from multiple different sources, you know, that's at least a start. And then you can, you know, have that as a baseline and then say, how different is my building from this baseline building? And then, you know, maybe it doesn't have to be directly tied to every single element of the building. But if you say, here's my baseline, and I think that my building, I'm going to do these additional things to it. I'm going to strive for lead platinum. I'm going to, add a podium underneath the building, and I'm going to do, you know, x, y, and z to make it different from the baseline. You can start developing, you know, a fairly sophisticated cost model.

C And then as far as, like, how you track changes, that is a that's a tough one, and that has a very human element to it. But I feel like there has to be some way to kind of passively gather information about the changes that are happening in a design without somebody having to say, I just did this, I just did that, I just did and then have each of those, like, affect the the predicted cost of the building. Yeah. I think that might be more around, like, data mining or, you know, just something that, you know, automatically scans documents within a project folder, things like that, to kind of find changes without a a person having to go in and manually manually edit it. I don't know. It's kind of like you can imagine a lot of really, you know, sci fi things that would that could be done in this space. But

A As you were talking through this and and by the way, like, just hearing how you talk about it, you can tell that you you've definitely been playing in the space for a while. But I I feel like the architect's perspective are even our Revit models are they're very they're very stagnant as much as architects would like to believe that they are dynamic. And I feel like a lot of the first movers, you know, some of the other other people that were, like, looking to bring in, we talked to Cove tools too, that the that they're all thinking about a more dynamic modeling structure, to make, you know, using machine learning to to accommodate the many different nuances and adaptations that can can happen. And I I feel like that's a mess soul that would benefit us from flexing a little bit more. I also feel like we, you know, we hold ourselves back. Like, it's we only design prototypes because they're all one offs, you know? And I think that's like Yeah. That's the big thing that's, like, keeping us in our head from kind of moving forward.

C Yeah. No. I think that's a really interesting point too. And, you know, when I think about tools for architects and other folks in AEC, like, I wanna build things that are as seamless as possible for people to use and that, like, free them from doing the mundane things. Like, nobody really wants to go through every element in a Revit model and put a master format or a uniformat code or any other code in there. And, you know, there should be ways to kind of do that more automatically and, you know, just kind of let the architect kind of work at the speed of thought and and have it just kind of be augmenting their work as they go along rather than having this heavy handed process where you need to go in and, you know, do the work you are already doing plus 20% in order to, you know, enable a cost estimate or some other sort of, you know, that, you know, predictive algorithm related to to anything around building design.

B I think that's what's interesting about what I heard you just say is this idea of kind of the split between the the where the human is spending their energy and time working on something versus allowing technology to automate and guide processes. Yeah. You know, where is gonna be the biggest impact to take automation and that like you said, the mundane things, the mundane tasks away to maximize the work that the architect's actually trying to do. And I think that's a really good question. And I know as we've been talking to a lot of the different technology leaders that are thinking about how to create solutions to that. It's I think the underlying question there and and ideas that there there hasn't been a lot of innovation around those solutions to make that shift. And so right now, we're in this really great moment where companies are starting to recognize that investing in solving those problems really could yield amazing results and I think could be really transformative to the way that architects practice in the next decade and beyond.

C Yeah. I always think of this, this analogy of, advanced chess. So, you know, back in the sixties, seventies, eighties, like, the the whole the whole competition was like, could a computer beat a grand master at chess? And, eventually, it did happen. I wanna say it was in the early 1980s. And then kind of the next wave was, advanced chess where a human and a computer play as a team against another human and computer team. And so it is a really good partnership because the human is very good with strategy, and then the computer is very good with brute force. And so the idea is that, you know, the the the human playing chess can say, I would like to look at this strategy, this strategy, and this strategy, and then the computer will kind of crunch the, you know, 1,000,000 scenarios and possible outcomes of that. And I think that's just like a really nice analogy to what, like, computer aided design should be, where we let or we we have people, architects, engineers, like, doing what they do best, which is, like, thinking about providing space for humans and, like, what makes a good space, thinking about things like sustainability, and then letting, you know, your your software tool kind of perform all the different scenarios and then, like, find out 1 or 2 or 3 things that you might wanna push forward, you know, based on the the strategy that you've given it.

A Let's take a break from this conversation to talk about our sponsor of this episode, Monograph. We're proud to partner with Monograph because they are helping to transform the practice of architecture, one design studio at a time.

B Tired of using dated and clunky software to manage your firm, or do you feel frustrated wrangling all of your spreadsheets to get a clear view of where your project stands today. Monograph is here to help.

A Designed by architects for architects, Monograph allows you to track your time, your projects, and your budgets in real time. With our awesome MoneyGantt, you can immediately understand project performance across your entire firm portfolio.

B Need to adjust your projects week to week? Their new tool, Resource, allows you to reallocate your team's time and track its impact on your remaining budget.

A Be proactive with Monograph.

B Monograph is building a community of like minded firm owners and operations leaders who are looking for solutions that align with their firm's values.

A On top of that, Monograph is building the only cloud based practice operations software built exclusively for architects by architects.

B Monograph's easy to use and beautifully designed software allows you and your team to know in near real time time whether you're on pace to deliver a project on budget. With Monograph,

A you and your team can plan project schedules, budgets, role assignments, and team members all in one place. The best part of monograph? It doesn't require a degree in finance to use. To experience the difference today, sign up for a free trial at monograph.com.

B And to underscore their commitment, on August 12th, Monograph will be hosting their 1st ever virtual conference. It's called Section Cut. This one day event brings firm owners, operations leaders, and project leaders together to learn from success stories and workshops, all with the goal of improving their business. Reserve a seat at SectionCut today by visiting sectioncut.com.

A And Twinmotion. What if you could visualize your building in a couple of clicks? Remove months from the design process or create a bridge between stakeholders to solve problems before they even come up.

B Our friends at Twinmotion offers simple, real time visualization for architects. Their technology lets you view and edit your scene on the go in the same pixel perfect quality as the final rendering. Twinmotion seamlessly integrates with other tools like SketchUp and Revit, transforming your BIM or CAD models into high quality images, panoramas, VR videos, or presentations.

A Sound complicated? Well, what if I told you that Twinmotion enables anyone to present the biggest ideas in the easiest way possible, regardless of previous CG experience. To download your exclusive free trial, head to twinmotion.linkback/disrupted. That's twinmotion.linkback/disrupted. I wanted to move this a little bit because you talked about it's it's interesting because you have talked with a lot of architects. And I think some of that is because Ader Labs actually encourages and likes to hire and bring architects over on to the technology side. And we had a wonderful conversation with Agnesa about outside of even UX design, which I feel is like where architects tend to default, where they say, I'm going to make the jump to technology, let's go into UX. So she talked to us about customer success and customer service. What have you seen or what skills is most attractive to you coming over when when you're looking to bring architects over into outer labs? And, not only that go beyond the fact that you actually are a technology company that plays in the AEC space? Like, are there other transferable skills that they can even say, you know, like, what are other technology? Like, where can I go and bring this skill into other technology?

C Well, me with my background in software engineering and leading the engineering department, I I really encourage people to move into software engineering because, well, a, I think it's a really, like, wonderful, actually very creative career, that is, you know, very can be very balanced and very, like, family friendly and things like that. In particular for us, like, I'm very happy to help people make the transition into particularly software engineering, but other other, you know, tech related fields as well when they come from an AEC background. And for me or for Outer Labs, it really does come down to, like, the ability to empathize with our end users and understand the problems that we're trying to solve. Because, you know, if you're working if you're a software engineer and you're working on, you know, a mobile application related to calendaring or to do lists or, you know, something that's really a, like, a consumer product. It's easy to put yourself in the shoes of the consumer and be like, yes, I would use this shopping list, or I would use this calendaring app, but our tools are so technical and specific to, you know, the different roles in the AEC space. Like, it's hard to have somebody come in and say, okay. You're now building a tool for an interior space planner, and if there's no background at all, it's kind of hard to develop that empathy. I mean, it can happen over time, but having folks who kind of, you know, went through the formal training and practiced in either architecture, you know, in, you know, mechanical engineering.

C We have one woman who transitioned from she was, focused in energy modeling, a highly technical field into software engineering. Like, I find that those folks are able to really kind of understand the needs of our users, read between the lines when, you know, a a requirement is stated, and really ask the right questions. I think there's also the whole notion of, you know, software projects are very they they also are complicated, kind of like a building project is complicated with many different stakeholders, and I have found that people coming from AEC are kind of used to living in these complex projects with some, you know, areas that are more gray or not figured out, and they're just, like, a little bit more okay with ambiguity than, than other folks with different backgrounds. So that's been very useful as well. Yeah. I I I actually really love bringing people, from other industries into software engineering, especially especially women. There are very few women software engineers. There's more now than there were probably, you know, 15 years ago when I got started, but it's there's still a a real dearth of it of of of folks.

C So, yeah, whatever I can do to kind of encourage people, I I try.

B I'm curious. Like, what do you find when when people do come in and make the jump into software? What are there are there things that they tell you that they notice that are different in terms of, like, how you guys either operate or the way you think? Or what stands out when you have those conversations

C and this is not every software organization, but many software organizations really strive to have, like, repeatable processes, where you do something once and then you reuse it, rather than kind of building something new every time that you are starting a new project. So there's a really strong notion and desire for reusability, which I think is pretty different than even, what, what, Evelyn, you were just saying a few minutes ago about everything being a one off, and we tried very hard not to have that. You know, where it's like, if something is going to be used more than once, you turn it into a library or a service or something that, can be built once and then used many times. So you have a lot higher leverage on the work that you've previously done. It's not just, like, you know, start at the start, march along to the finish, rinse and repeat. It's like every time you build a new project, hopefully, you can identify something in there that you can reuse on the next project. So as you, kind of, you know, grow a company or a team over time, like, you are, yeah, really just kind of adding the new things and then reusing the the the pieces that you built for a project, you know, 3 iterations ago. I think that's a pretty different mindset.

B Yeah. I would agree. That's a really big difference from, I think, the way that most architects approach problem solving. I mean, I think that there is a priority towards creating, and so and, actually, most designers find joy in that. So they're looking for those opportunities to create something new, whether it's, you know, the exterior of a facade or that they wanna come up with a new, you know, courtyard design element, and they wanna come up with, like, 5 different iterations around how to do a courtyard. You know? They're always looking for where they can create those one offs that are unique, and so I do agree that that's like a inverse almost of the mindset for for how you all are thinking about that. And I I think that that's maybe something that we should point out as something really valuable, and and we can talk about why, but, specifically, that perhaps it's not every design solution that you come across in practice. But I think where you can identify those systems and those processes and adopt them and build from them, it actually creates efficiency and, you know, reduces time, like you said, on the things that you shouldn't be spending as much time on Yeah.

B To allow you more time to spend on the things that you do wanna do the one off on. But I constantly see and, Evelyn, you can you can decide to take this out if you don't agree. But I I like like, AIA is a perfect example of where I see architects constantly doing this behavior where they're always trying to redesign something that has been designed, and and their reluctance to actually just adopt the thing that's already been designed is so inherent to who they are. That the reason everyone gets so frustrated at the AIA is it's constantly being redesigned every year. And that's just one example.

A For me, the a huge difference between the technology space and this idea of open source versus architects, I mean, I've worked at offices where we, for whatever reason, have people sign NDAs before they can even enter our space. Like, I don't I don't know what we have up on the walls that they're gonna steal. That's that, like, is different than necessarily a technology firm. But, like, there's a there's a level of secrecy that prevents us from even sharing information internally with a firm, let alone without, like, externally to another firm. So so I think, Jen, when I think about all of these great databases and and knowledge sharing that we could be doing, it just doesn't happen in the architecture industry nearly as much. And again, I think it's a symptom where we are kind of standing in our own way because that knowledge sharing would help us remove all of those mundane tasks that we are all doing, maybe just slightly differently, but, actually, it's very similar. But we're not even willing to share, like, one, we're horrible or update our own libraries in house and the firm. So let alone thinking about yeah.

A Heaven forbid, we should share our detailed libraries outside the firm, even though there's only so many ways you can draw like

C folks in the software open source community to keep libraries up to date and, you know, create new projects? And, actually, a lot of it's around reputation. And some of the sites that are common, you know, for open source sharing like GitHub and GitLab and things like that. Like, if you look at a person's profile, it has this chart that shows all of your contributions, and it's kind of like your badge of honor if it's if it shows, like, a daily contribution or a weekly contribution. And people, they they build careers as open source contributors, either, you know, working entirely independently through donations from the larger community. Many companies sponsor open source projects, so they'll hire an engineer who is, you know, a major contributor to a to a software package and then just pay them to update and maintain that library. But, yeah, there definitely is, like, a reputation component to it, which, yeah, I think is kind of an interesting thing. But, yeah, I I've spent a lot of time too thinking about, like, how would you even start something like that with the AEC community. And there are definitely people out there who are trying really hard to do so.

C Like, you know, the the folks over at Highpar have a lot of open source components. My last company, Flux, we had quite a few open source libraries and and SDKs and things like that. So I think it is happening kind of with the generational changes, folks in their, you know, twenties, thirties, forties. Like, it's maybe just a different mental model for how kind of work and sharing happens and, you know, hopefully, we can just model the behavior we want to see and it will eventually start taking hold more broadly.

B Definitely. I'm wondering, are you able to give us some examples of of problems that you've helped solve within the AEC industry that are demonstrate that process towards efficiency and getting rid of the mundane with some of your clients?

C Yeah. So one tool that we have is very focused on space planning of really it will we We have space planning tools both for existing buildings and for buildings that are about to go through, like, an adaptive reuse or tenant improvement project. And what our tools allow people to do is basically specify their intent and say, I'd like to have, you know, this much of this type of program, this much of that type of program, this type or this much of, you know, this type of program. And then using things like constraint solver technology, we can generate many, many different options that all satisfy that target or those constraints. And so instead of having to, you know, manually lay out everything in a building's program, a person can just say, okay, this all seems pretty good, but I wanna focus in on this area and then go in and manually override that particular region of a building. So we, in that tool in particular, we just give people, you know, a much better starting point where the space is, you know, 80 to 90% correct and meets their their targets, and then they can go in and apply, like, the human touch or take it, you know, take it the last mile. And, you know, instead of having a, you know, a layout of a a building take, you know, 10 hours or 20 hours or 30 hours, it's more like 30 minutes to an hour. So it's like a, you know, an order of magnitude reduction in time that we can we can help with.

C And as far as, like, some other examples where, you know, this is more kinda going on the the open source trajectory. Like, there are certain things, like, one thing that Outer Labs has open source is we have, like, a a wrapper around the forge viewer that makes it very easy to use in a React application, which is for those not familiar with React. It's probably the most popular front end JavaScript framework. And so we needed to build this for an application that we were building. We're like, there's really nothing proprietary about this. It's just making a viewport easier to use for other people. So, you know, we worked with our our client and got the okay to to open source that, and now it's, you know, used by by, you know, many folks. And, yeah, I think that, yeah, that just saved all those people a bunch of time.

C It was it's also, you you know, we're able to reuse it within our applications. And, yeah, I I really do wanna encourage that mindset within EEC firms, but, yeah, I think it's gonna definitely be a a collaborative effort.

A I'm going to touch a bit of a 3rd rail, but a lot of software companies use the term architect, even when they're talking about their engineering. Folks, I was hoping that you could kind of draw some more parallels between the complexities of an architecture building and the similar complexities of kind of developing the software tools you are in a way that helps people understand, like, why that term is being applied to certain individuals in this technology field.

C Yeah. No. There are so many overlaps in language between the architecture field and the software engineering field. And, you know, I think that kind of comes from the idea that a piece of software is very complex with many moving pieces, and you you really do wanna think about most pieces of software in, like, a systems way, where you have the whole is the sum of its parts. But, like, the way that I like to think about software architecture is that you have, like, small discrete components that each are responsible for, like, one job. Kind of like in a building, how you have the structural system, and its job is to hold up the building. And the, you know, the the seismic system is to, you know, keep a building standing in an earthquake or a seismic event. The HVAC system is to circulate air within a building.

C Within a software application, you may also want to have, like, you know, dedicated services like this. You may want to have a service that's all around authentication and authorization. So a person who shouldn't be accessing a piece of software or an asset that it holds shouldn't be able to get it. You may want to have a component that is responsible for communicating with the database of an application. You may want to have a service that is responsible for, you know, like, parsing user input that comes into a system. So you can think of them both as like systems based and, you know, each system having a discrete role. And so I think that the kind of the architect term and that that crossover, that overlap in languages that you need to have people who understand how all of the parts work together and be able to like debug when things go wrong and I think that in a building design project that role is the architect, they are kind of responsible for the big vision of the project, but also kind of managing how all of the different parts will eventually come together into that greater whole. So, yeah, I think there there is a lot of a lot of parallels between it.

C But, you know, also just like, you know, a modern large commercial building and a modern large piece of software. It's really kind of impossible for one person to hold everything in their head. So you have kind of people who specialize in different different parts of it. Still, you know, software architects or architects, but focused on, you know, this area or that area versus the the the whole thing. I think maybe you're maybe if you're building a, you know, a smaller application, it's possible for one person to hold everything in her head. But, yeah, if you're building anything that has any sort of scale, that just eventually becomes a tough thing to to to to to hold. There's another area that software has taken a lot of, inspiration from architecture too, which is the idea of pattern languages. And, actually, when I was first getting into kind of the AEC technology space, I read, Christopher Alexander, a pattern language book, and it's like, oh, yeah, this is this is, you know, very applicable to software design, and then there's a a group of 4 researchers, I'm gonna say it was back in the eighties or nineties, and, you know, they had that same idea.

C They had all read the Pattern Language book, and they developed a very now famous book by the Gang of 4 about, like, software engineering patterns. And, like, many of those patterns are still in, you know, use today. So it's not just the titles that software engineering has borrowed. It's actually kind of some of the algorithmic thinking and naming something that is occurring regularly. I think that with with Christopher Alexander, you're saying, you know or one of the one of the things that he's that really comes out in the pattern language is, like, we have these things that we repeat over and over again. If we just give them a name and kind of codify what that thing is, then we have a chance to, like, make it better every time, and the software engineering community really latched on to that. And it's a really common I don't know if it's really, like, taught in school, but it's definitely something that, you know, a budding software engineer would learn as they are trying to kind of hone their craft.

B Yeah. Actually, I've heard that come up a few times in our interviews and also over on Architeckeys. People seem to be really drawn to that research and that way of thinking.

C But it makes a lot of sense in the software context, and they even transcend software languages. Like, there are patterns that, you know, whether you're writing a c plus plus, you know, back end server or, you know, a JavaScript front end web application, like, you can follow these same patterns, because they're just ways of, you know, dealing with data exchanging information. And it really doesn't have anything to do with, you know, the language it's written in, what the context is in. I think that's kind of a very similar concept to, you know, what is kind of advocated for in that in the pattern language book. So they're kind of universal concepts.

A I wanna take this conversation about parallel ways of thinking and transition that back to advice you would give to architects. So, you know, if you are interested in getting more architects in this space, especially introducing more female architects to this space, how would you suggest that they begin that journey?

C Yeah. No. That's a great question, and this is going to be kind of geared more at people moving into software engineering. I think there's maybe a slightly different path if you're moving into UX research or UX design or product management, but just given my background, this is the one I've thought about the most. One of the best things to start with is learning to kind of program in your own domain first, so I'm a really big fan of tools like Grasshopper and Dynamo and other graphical programming languages where you may not be, you know, sitting at a terminal or a text editor and writing textual code, but you are starting to think about things more algorithmically and also just getting exposed to the types of operations that are common in programming. So I think that, like, learning, yeah, graphical programming is a really great place to start just to get a sense if you even enjoy that type of work. And then I am personally a big fan of boot camps because I feel like they're very practical. They're usually, you know, on the order of 3 to 6 months.

C There's a defined start date and end date. You have a lot of accountability during that time to the instructors or whoever is arranged the program, there's a set curriculum, it's well curated, and you come out with enough knowledge to really start as a junior developer somewhere. You may not have all of the background in data structures and algorithms and things like that, but that can kind of be backfilled. I really think that when a person is just starting out as a software engineer, the type of work you're you end up doing is very practical. You're, like, probably working on a web application or you're working on, like, a boot camp really does, like, you know, just prepare you well for, and then you can kind of backfill any kind of theoretical knowledge that, you know, a boot camp didn't offer. And I I prefer a path like this rather than, like, trying to, you know, follow the curriculum of a computer science program at a university on your own because I feel like if you can have a if you can kind of have a project that you're working on or something practical where you can take these, like, theoretical ideas and then start applying them in, a real world context. It just makes the the concepts, like, stick that much more. So, yeah, I've been a big fan about about of, like, boot camps and things like that.

C And then I think another important thing to do, and this doesn't apply just to, like, people trying to make a career transition from architecture into software engineering, but just like any career transition, is just like tell people what you're trying to do and, like, people generally wanna help you out. You know? I think people are generally good and, you know, wanna be helpful. And, you know, people are like, oh, you gotta use your network, and that's kind of a, you know, kind of a scary term and, like, oh, I don't know how to network. But network is really just like it's just talking to people. Just like talk to anybody and just be open about what you're trying to do, what sort of change you're trying to make, and, you know, I feel like so many things happen when a person is like, oh, my cousin's sis or my cousin's girlfriend is, you know, they're looking to hire a junior developer here and, like, it's a it's a foot in the door that you wouldn't have had if you were, you know, just trying to, you know, apply through, you know, online job portals. I feel like it's very it can be very difficult to land a an entry level or junior level developer position just by applying through, you know, job websites. I feel like nearly everybody who I've spoken to who's made this sort of transition, they've done so by just talking to people and kind of sharing with them what they're trying to do and then kind of having that serendipitous connection.

A I think that's all super helpful. The one last thing that I think would be helpful for you to touch on is so much of our work is encapsulated in a portfolio.

C Mhmm.

A Can you help architects understand why they might not want to bring their portfolio to a conversation about a software development? I only say that because I think that's the hardest thing for architects to set aside when they make the transition.

C It is a pretty, you know, different career path to go down, particularly, you know, moving from architecture to software engineering. You know, I think it can be good to show that you have what your past work is, but if you dwell on it too much and you're not talking about what you're trying to do now and do moving forward, you can come off as being kind of either uncommitted to the change that you've just made, stuck in the past, not as excited about software engineering as you are about architecture. I think it's important to once you've made the decision to transition into a different career, like, really commit to it and be very excited about it and share with the people who are interviewing you why you're excited about it. I think if you were to come to a software engineering interview and they're asking you to do a whiteboarding question or talk about the boot camp that you just finished and you say, well, could I also show you my portfolio? They say, well, aren't you that's just not really relevant to this to this to these questions that I'm asking you. So I think it could come off as, yeah, either being unfocused or or not committed to the change that you've made.

B So we wanted to tee up before we dive into our closing conversation that at the time of this interview, the news about Katerra had just come out about a week prior to us talking with Jen, so you hear it mentioned in the conversation. You know, I'm really curious what stood out to you in this conversation and what what did you walk away with?

A My usual perspective on the profession has been a pessimistic one. I don't know if it's because I'm inherently that's my view on things, but also because I've been involved in the AIA long enough to see the wheel come around and to see us repeat things. So it was nice to have a conversation with Jen, who has somewhat of an outside perspective and yet still brings a very hopeful perspective to the profession and where we can move things forward and where the opportunities are. And I hope that our listeners heard about the opportunities she believes that we have to reclaim some of that creative thinking space and get rid of the things that, frankly, I think we're all sick of doing. So what was great for me was how thoughtful Jen's response was about the profession, the view that she was able to give based on her knowledge, having had an adjacent role this entire time and saying, you know, there's still a lot of opportunity for everyone to play in this space. But that goes back to kind of the title of the conversation. Right. And why there is such a big interest from the tech companies in the AUC industry.

B It was really noticeable to me how many parallels there are between the way that I think a technologist thinks about designing what they're doing and the way that architects think about what they design. I guess we separate these things, but it was interesting considering that Jen's able to come in with her expertise and then offer additional value to what we're doing to elevate the work that architects are trying to do by designing software that supports the work in more to your point, in more efficient ways. That's kinda exciting, and I think that that that will continue to grow in the next decade. I think that the more that we allow people into this space that have complementary skill sets and strengths that can create a more efficient, more forward looking profession, I think that's gonna amplify the work that's trying to be completed.

A Yeah. What was unique about that conversation is I think you and I, Janine, have had so many, not confrontational kind of conversations, but every time we mentioned that we should be doing something differently or that we should be approaching things, a lot of our conversations leads to spending, you know, what we would call non billable hours or overhead time. And a technology is like, a product engineer's immediate response to that is let's create a library. Let's create a template. Let's never have to do that again. So it was just a different reframe on a conversation that you and I have had so many so many times in the past and have kind of hit a wall against versus how a different profession approaches it and and maybe even a reason as to why why they progress so much more quickly than we do, because of that reframe.

B I also wanna come back to this conversation around the pattern language because I know this was something that's come up in architecty. And then also you told me you reread this book recently. So maybe tell our listeners for those who don't know what Pattern Language is. Like, what's the premise? Why is it important? Why has it been influential?

A So I'm in the process of rereading it. I haven't gotten through it all. But the pattern language is essentially if you see things that are reoccurring and if you give it a name, then you have the ability to to talk about those reoccurrences in a way that other people can understand. It's like creating an alphabet for various different architectural vignettes or patterns and and at a variety of different scales. So similar to I have a 4e except after c, there's rules that come along with the patterns that are like the most accepted ways of implementing them. There's always the exception. But by creating this language, then you all have a common vocabulary to move and develop ideas very, very quickly and iterations. You understand what works and what doesn't work and and why things may or may not work as well much more quickly than if you just did not have the ability to frame it around that similar vocabulary.

B So Outer Labs is one example of a company that has tapped into trying to solve challenges that are coming up in the AEC industry with technology. I'm curious, Evelyn, you know, we've talked to several companies that are also in that space, but what is your hope as this work continues? Where do you wanna see these two worlds come together?

A It's not different than the hope that Jen has placed on the future of the profession. And it's not different than any of the conversations that we really had about how do we raise the value of architecture. Right? So so much of our fees we've talked about is is done on an hourly basis. So right now, we essentially have no incentive to increase the efficiency of how we deliver construction documents because that means we deliver them quicker in a smaller amount of time. And because we are billing hourly, that actually means the overall fee on our project is smaller even though since sequentially you would hope that you could do more projects more quickly. I I think that would, you know, people could lead could argue that that leads to quick burnout. Right? If we wanna be paid and valued for how we think about space, and the relationship of individuals and community to space at whatever scale we're operating at, be it a single family home or, you know, a university or more even even at a more urban scale, then we really need to automate everything else around us and really look at how can we drive more value towards that strategic thinking that is really independent. I don't care if you're a designer or a technologist.

A That's, like, really where we all kind of love to spend a lot of our time. And maybe I'm speaking out of turn for the entire profession, but that's where I love to spend most of my time in the strategy world.

B Yeah. I mean, I can just think about so many times when I was working on drawings where we were doing these tasks that were just endless and mundane and pretty painful, and I just couldn't believe that we were spending time on these things. Like, it's just the more automation, especially, like, with modeling, I think anything that we can do to create efficiencies and get rid of manual hours put towards things that shouldn't be done by humans is the direction that we should be going and then allowing more designers to kinda focus on the things that are more engaging and more Thank you for

A listening, and tune in next week. Thank you for listening, and tune in next week. Thank you again to our podcast partner, Monograph. Learn how Monograph can help you take control of your firm's financial health. Follow the link in our show notes or visit practice of architecture.com backslash monograph so that Monograph knows that you heard about them from us. To reserve a seat at their first ever interactive virtual conference, visit sectioncut.com today. Thank you to Twinmotion for

B their support of this podcast episode. Visit twinmotion.link /disrupted and try Twinmotion for free.

A Thanks for joining us on Practice Disrupted, a podcast by Practice of Architecture. You can find all of our past episodes by visiting practice of architecture.com backslash podcast.

B You can also get involved with our growing community. Find us on social media at practice of a r c h.

A And you can join us in the POA lab. You can apply to be a part of the practice of architecture lab by visiting practice of architecture backslash lab, where you will have more opportunities to interact with us and all of our podcast guests.

B This show is part of Gable Media. You can learn more about all of the podcast and video content connected to this community by visiting gablmedia.com.

A Don't forget to share with your friends and feel free to let us know what other topics or speakers you are interested in hearing about.