138: ‘The Opposite of Garbage-In, Garbage-Out’, with Marty Rozmanith

A conversation with Marty Rozmanith.

138: ‘The Opposite of Garbage-In, Garbage-Out’, with Marty Rozmanith

About this Episode:

Marty Rozmanith of Skema joins the podcast to talk about his journey through the world of AEC tech. From self-taught programming skills to pioneering the use of 3d in AutoCAD in the early days, to Revit, then post-Autodesk with Dassault Systèmes and beyond, Marty shares unexpected twists and turns that shaped his career with the common thread of always trying to better connect design to construction. Join us as we explore the fascinating path that led Marty to where he is today and what challenges he’s got his sights set on solving for our industry with his latest venture, Skema.

Connect with Evan:

Watch this episode on YouTube:

Episode Transcript:

138: ‘The Opposite of Garbage-In, Garbage-Out’, with Marty Rozmanith138: ‘The Opposite of Garbage-In, Garbage-Out’, with Marty Rozmanith

Evan Troxel: [00:00:00] Welcome to the podcast. I'm Evan Troxel. I have a bit of housekeeping before I introduce today's episode. The TRXL podcast me. Well, I'm now collecting feedback, whether you have general feedback or episode specific feedback. You can click the link in the show notes, or you can head over to TRXL.co/feedback. It's my goal to continually progress what I'm doing, and I fully recognize that I'm not the only one with good ideas around here. So if you have something constructive that you think will help, please do so at TRXL.co/feedback. And again, that link is in the episodes show notes as well.

On another note. It was absolutely amazing to see so many great people from the AEC tech universe and beyond at this year's Autodesk university. Look for a blog post with selfies with previous guests of the show, including the guest in today's episode. So in this episode, I welcome Marty [00:01:00] Rozmanith, the co-founder and chief technology officer at Skema. Marty is an entrepreneur and building design and construction professional with a 30 plus year career in transforming the building industry. As co-founder and chief technology officer at Skema, Marty leads the team developing the Skema software suite, the world's first BIM knowledge reuse engine. Marty's career is a solid mix of technology startups, and global software behemoths that give him a unique perspective on the AEC industry. He spent five years in professional practice before specializing in AEC software, and he was recruited out of Autodesk to join the startup company called Charles River Software, which became ultimately Revit Technology Corporation. Marty is best known for his role leading the requirements team for the Revit product.

When Autodesk acquired Revit in 2002, Marty spent several more years at Autodesk before going out on his own. Once again, to create companies that address modular and sustainable buildings. [00:02:00] And before joining Skema, he spent 10 years at Dassault Systèmes as global sales director and strategy director for AEC. His work, applying modular approaches and digital twins in AEC has been published in the Wall Street Journal, Forbes magazine, and other professional journals.

Marty not only holds a Bachelor of Architectural Engineering from Penn State, he also has an MBA from Boston University.

In this episode, Marty takes us on his incredible journey through the world of AEC tech from self-taught programming skills to pioneering the use of 3d in AutoCAD in the early days, to Revit, then post-Autodesk at Dassault Systèmes and beyond, Marty shares unexpected twists and turns that shaped his career with the common thread of always trying to better connect design to construction.

Listen in, as we explore the fascinating path that led Marty to where he is today and what challenges he's got his sights set on solving for our industry [00:03:00] with his latest venture Skema.

So without further ado, I bring you Marty Rozmanith.​

Marty, welcome to the podcast. Great to have you.

Marty Rozmanith: Thanks. Great to be here.

Evan Troxel: I'm really interested in your backstory. You, you've, you've been through so much in AEC tech, and I, I want you to tell that story of kind of where you've been, to, how you've gotten to where you are.

I know that there's some, there, there's some stuff in there that, that it's just you, it's unexpected. And that, to me is, is gonna be kind of an interesting jumping off point for this conversation. So take it over and, and tell us kind of the path that you've been on over the last, I don't know how many decades you tell us.

Marty Rozmanith: Yeah, about 30 years. A little more than 30 years now, actually. Um, geez, going all the way back. I mean, I started out in professional practice, like a, a lot of people that went into [00:04:00] tech eventually. Um,

Evan Troxel: Hmm.

Marty Rozmanith: I went and, uh, was doing a lot of work, uh, with computers when I was in college. Um, I ended up. taking an AutoCAD class back in the very early days in the, in the eighties. And, um, you know, it was a drafting class and I was kind of not liking the fact that it couldn't do three D so I took lisp and I wrote an entire system so that two D AutoCAD could do three D models.

Evan Troxel: Wow.

Marty Rozmanith: When, when my professors saw that, they were like, you should just teach the AutoCAD lab . So, um, so that's kind of how I got into to tech, uh, in this world. And, uh, but of course I was just, you know, a college student who didn't really know anything about professional practice. And so after I got outta school,

I, I, graduated into a recession, which is not uncommon. Uh, I know so many people who graduated into recessions and had to do creative things. So I ended [00:05:00] up moving to California where I went for, to work for a very small architecture firm, um, where I had told 'em all about, you know, my CAD proficiency, but a lot of what they did was hand drafting.

So I got to draft on Vellum and, you know, do all those things that old school guys did, uh, when you first started out in design. Uh, and then the recession caught up with the West Coast, and I got laid off like nine months after I moved all the way across the country.

So, uh, . So, so I ended up deciding, uh, that I would try to tap some contacts from Penn State where I had graduated, and a lot of them were in the Bay Area, so I just started reaching out to people and I landed a job up in San Francisco, which was, happened to be a, a happy accident since that's, you know, where the nucleus of tech was in, uh, the late eighties, early nineties.

Um, and so I started working for an architecture firm up there. And, uh, and did work on architecture practice and also instructional engineering. And it got to the point where, um, I had worked for a couple [00:06:00] firms. I'd been in professional practice about five years, uh, got to know people in the Bay Area. I ended up being one of the co-chairs of the computer forum for the A I a San Francisco chapter.

We would have a, a graphics exhibit every year. Um, so I think I'm the first person to hold a VR competition back in 1994 at the San Francisco a i a, uh, which is pretty fun because I remember SOM Wheeling in a refrigerator size, Silicon Graphics, indigo computer because they had a three D model of the Dubai airport they were designing at the time.

And you could walk around it at like one frame per second.

Evan Troxel: Yeah. Yeah.

Marty Rozmanith: So,

Evan Troxel: Wow.

Marty Rozmanith: but it was pretty interesting, you know, just to see the, you know, where things were headed. Um. I gotta the point where I had to make a decision about whether I was gonna commit to tech or con con, continue being committed to being a designer and designing buildings.

And I thought, well, if I commit to tech, I'll probably make a bigger impact than I would, [00:07:00] you know, working on designing buildings. Um, and so I did and I started my own consulting company and I actually had a lot of clients in San Francisco. You know, HOK was a client. Uh, the Federal Reserve Blank Bank was a client, like a lot of people that needed, uh, tech infrastructure for anything to do with facilities, whether it was designing facilities or operating facilities.

We ended up doing that. Um. I got to know from the AIAI got to know the Autodesk marketing people 'cause they actually sponsored the graphics exhibit. And AutoCAD was one of the prizes that, that was the grand prize for those who, who won the exhibit. Um, and through that relationship I actually got recruited into Autodesk, um, with the proviso that I would actually move across the country to New England because that's where the job was located.

'cause they had just bought a company called Soft Desks. Um, and I had just gotten done implementing soft desks at the firm I worked at, which was RMW, uh, which is still around today, kicking hard, uh, 30 something years later. And so, um, [00:08:00] Autodesk moved me to, to, to New England and I started working on the first, uh, software product I ever did, which was Architectural Desktop, uh, which was an AutoCAD based product.

And I actually got to the Revit startup because I was out there Marketing Architectural Desktop, which that was the number one product at the time. And I was at all the trade shows. So I think the, the venture capitalists that were backing Revit. Got my business card at one of the events, whether it was, I think it was AEC systems at the time, and handed it to founders.

And one day I got a call, uh, from this guy with this Russian accent who said, you should come down here and see what we're doing. Uh, so it was all very mysterious, you know, and I drove down to Boston and,

Evan Troxel: No hesitation.

Marty Rozmanith: well, no, I, I, well, yeah, it took a few phone calls for me to go, okay, lemme go and see what these guys are up


Evan Troxel: All right.

Marty Rozmanith: they were hinting at what they, what they had.

And, you know, we were trying to do some things in architectural desktop at the time. And, um, I went down and, and these [00:09:00] guys kind of took a chance. They knew I worked for Autodesk, and so revealing what they were doing was sort of a risky proposition for them. And, but they decided to show me anyway. And, and I, what I saw was, you know, the nucleus of something that was pretty amazing.

It, it was very, very, very early. Right?

Evan Troxel: Yeah. Yeah.

Marty Rozmanith: um. But based on that, um, I decided to join that team. Um, and there were only a couple dozen of us at the time and we were in this building in Framingham that everybody, uh, calls the Pink Palace. So if you know Framingham Mass, you know, this building, um, in incidentally for Full Circle is now where the work bar space that we actually use for Skema is.

So actually one of our employees, still goes to that building that he used to go to when he was at Charles River Software. And so, yeah, so Charles River software software was based in Framingham and we had, you know, developers, uh, with PCs connected with hard cables 'cause wifi [00:10:00] didn't exist yet. Writing this piece of software, um, in c plus plus and eventually, um.

We started going to market and uh, and part of what I did was, was sign up. The first dozen customers,

uh, you know, that I thought of as pioneers. They, they were really people that I knew from having been not only a consultant, but also, um, some of the more, um, vocal people, uh, from my Autodesk days. So, you know, I wanted to show them what we were working on and some of them really gravitated towards it.

Some of them didn't get it. Uh, but those that gravitated towards it formed a nucleus of pretty important, um, friends of the family that helps steer us so that we got the product market fit in a way that actually worked for architects as opposed to just, um. You know, trying to come up with something you can sell.

Uh, so we were trying to, you know, we were always focused on what problem is it we're trying to solve. And, uh, the problem that we chose to solve was coordinating construction drawings and using a [00:11:00] model to do that. And so I was thinking of Revit as this rubberized cardboard building that you build so that it'll do your construction drawings so you don't have to constantly deal with 300 AutoCAD files, which is what used to have to do before, before the Revit days.

Evan Troxel: Right.

Marty Rozmanith: Um, you know, there's a lot of, uh, we put a lot of things into it because it was a model-based thing, and it's driven by a database that said, from the time we wrote it, you know, that database is a big fat file that sits in a Microsoft file system. So it's not something that's served in a client server database.

And, uh, you know, it's, it's obviously an old piece of software at this point, even though it's still kicking hard, producing lots of deliverables for people that they're getting paid on projects with.

Evan Troxel: right.

Marty Rozmanith: But, um. You know, after, uh, so we, we, we had some, we had a very, uh, aggressive marketing vp, um, who was the guy who had the market Lotus notes against Microsoft.

So he

Evan Troxel: Oh yeah.

Marty Rozmanith: he knew all the gorilla tactics and he pulled 'em [00:12:00] all out of his bag all the time. Um, it was a lot of fun learning guerrilla marketing tactics from this guy. Uh, 'cause he wouldn't, he wouldn't pull any punches. Uh, and we obviously got, um, I think we were on the, the, the radar for most of the big CAG companies, especially since we would go to all the major trade shows and they would see us.

Um, we weren't shy that we, we spent VC money and got huge boosts right next to the big players. And that's how you did it back in those days. That today it's a little bit different. Although we are rebooting a few of the Revit playbook, um, steps like the, the Pioneer customers that formed the nucleus of your product feedback.

And then eventually what, what we did at Revit, which we're doing now, is that that first dozen or so pioneer. You know, users that you have those firms, they're like magnets that attract the next 10 in their region of the country. So we eventually got to the point where we had a hundred, 120 firms that were our customer advisory board.

And we [00:13:00] would go around the country meet with all those firms on a probably twice a year basis just to go through roadmap and what we were thinking of doing. And we would basically make them argue with each other over what was more important to them. And that worked actually pretty well, um, because we would hear not just what was important, but people advocating for certain things and other people bouncing ideas off.

And you know, we, we always said, if you ask 10 architects, you'll get 15 different opinions.

Uh, because, you know, designers love to consider all sides. And so we, we got to work that working for us by just having people debate. What are the most important things for Revit to be able to do for the, the, the user base out there, you know, and what is the 10% that we shouldn't put in there that's special to somebody's practice?

And they'll do that by doing something to the family editor or some script eventually that they'll write. Um, we're, we're doing some of that with Skema now. But, um, yeah, I, after Autodesk acquired the company, [00:14:00] I spent three years there. I wrote some things which I thought would be useful for Autodesk to implement.

A lot of that stuff never got implemented. Um, part partly because I was more of a product guy. I wasn't really a business and sales guy. So after I, after I left Autodesk, three years after the acquisition, I went and got an MBA. 'cause I knew at some point in the future if I ever did this again, I would've to argue with those business and sales guys about, you know,

Not just what's a good idea, but what actually makes sense for the business.

Evan Troxel: You had to speak their

language, right?

Marty Rozmanith: Yeah. So I went, uh, like immediately thereafter and got an MBA and started working on my own startup companies. The first ones being all about the building industry, but not about design intent. Uh, more about means and methods.

Um, so, um, there was one that was manufacturing, CNC steel frames off Revit models to try and accelerate the precision and delivery specifically in multifamily housing. Uh, there was another one that we did that was, uh, after Katrina hit, um. Uh, how, [00:15:00] uh, very fast assembly housing for the Gulf Coast that was made out.

It looked like a low country Mississippi cottage, but it was made out of lightweight, precast concrete, and we physically tested it to 160 mile an hour winds. Uh, so there's a prototype still sitting there somewhere, uh, in, in Pascagoula, Mississippi actually. And, uh, you know, it's, it's been hit by like 25 hurricanes and it still looks

Evan Troxel: At this point,

Marty Rozmanith: amazing. It's the actual most amazing building I've probably ever put out. But, um, not, not many people know about it. Uh, and a lot of, so a lot of startups like that. Some of them worked, some of them didn't work. Um, not all of them were in ac. I did a couple SaaS products that were just general consumer SaaS products, um, in web publishing and some other stuff where I got to learn about, you know, running a company, , making

Evan Troxel: Mm mm-Hmm.

Marty Rozmanith: um, general marketing and sales, that sort of stuff.

And then, uh, finally got to the point where I just decided I wanted to go back into ac, um, partly because. I knew that [00:16:00] Revit would need several years just to kinda get on its feet. Um, and then. I just took a look around the industry and thought, okay, what, what's, where could I make impact now that several years have passed?

And so I started looking at the various players and I thought actually DA Systems had some pretty good technology,

um, that they had developed. Uh, obviously the big product, everybody knows there is Katia and the other ones SolidWorks. So those are all modeling products, but they actually have, you know, quite a large tech stack that's used in aerospace and automotive industries.

And given the fact that I had been in some manufacturing startups, I thought, all right, well if I have to figure out, you know, how to apply some technology and some work practices from manufacturing to construction to, so systems is probably a pretty good place to do it. So I went, uh, and spent 10 years at the so systems.

Kinda advocating DFMA and productizing and industrializing construction to make it more efficient. And that whole thing about trying to connect design to construction is something [00:17:00] I've been doing ever since I was in college. I wrote a, I wrote a, my thesis paper at Penn State back in 89 on a system to connect design and construction.

It's, I, I came across it in my basement the other day,

Evan Troxel: Wow. That's

Marty Rozmanith: Um, and so, you know, there, there are some of it, my colleagues who refer to this as a disease, like, you know, we've just been at this for so many decades, we can't leave it alone now. And that's kind of how I am about it.

Evan Troxel: Wow. There, there's so much there. I I, I kind of want to go back to the beginning for a moment because you wrote your own three d modeling lisp routines for AutoCAD. Where did that come from? Like what, because they don't teach c plus plus or lisp in architecture school. Right. And so obviously you're self starting, and so I'm just wondering like, what, why did, why did you decide to do that in the very beginning and, and how did you

decide, how did you accomplish that?

Marty Rozmanith: Um, so I wasn't in an architecture program. I was in an architectural engineering program at, at Penn State. And, uh, so [00:18:00] you're pretty technical when you're in that program. Uh, the, you know, computers in that program, these are, you know, this is eighties, so I think EABs existed. So you used it for structural simulation, but there was really, other than general drafting software that people used for mechanical cad, there wasn't anything specifically dedicated to AEC at the time.

And so I. Um, I was actually trying to rationalize a project that was a, a multi-family residential project, um, that someday I knew was working on, and it, and it was, it was all to do with roof slopes and stuff. And so I just said, how can I make this do it?

Evan Troxel: Mm

Marty Rozmanith: I wrote my first computer program in middle school.

Uh, I wrote a game for the Apple two e , which was, it was a moon game. Uh, most of the game was in basic, but in order on a machine of that era to get the graphics to be fast enough, you had to write them in [00:19:00] assembler, which is basically raw machine code. So, you know. In middle school, I learned how to write assembler code.

Um, and so I wrote this game and eventually, um, in sort of computer circles, I got a, you know, you would pass things around on floppy disc and I got this floppy disc because I had this moon game on. I'm like, I wrote this game.

Evan Troxel: That's awesome.

Marty Rozmanith: So, so, you know, I, I had written programs ever since I was in middle school, and so I just, you know, it was mainly self-taught, um, just learning how to do programming, uh,


Evan Troxel: that outta books? Was that outta magazines? Because I

Marty Rozmanith: It was at a, mostly, mostly books and trial and error. Um, I, I wrote those programs on an Apple two E. The, the school that I was at had Apple two E. Um, I eventually got like an Atari 400 that I wrote basic programs on at home. 'cause it was a little bit better than having a game console. So somehow I talked my parents into it.[00:20:00]

Evan Troxel: Nice.

Marty Rozmanith: Um, but you know, I just had a general awareness of what it takes to write something like that and the structure of it. And I realized that this lisp language was something that you could extend functionality with an AutoCAD so that I just did it. Um, I don't know you, I just didn't think too hard about it.

I just started working on it and figured out how to structure it and it worked. Um, probably nobody else would ever be able to figure out how to use it, but

you know,

Evan Troxel: Right. Well, and back in those days, AutoCAD was running on Doss. Right.

And, and just, just to kind of reiterate the things that you're saying, the the first thing that I, my first computer was also an Apple two e and I would program things in basic, and you're, you're much more of the engineer side of architecture and I'm much more of the designer side of architecture because going through that process, uh, my first personal computer was a Commodore 64 that I bought at Toys Russ of all places. Right. And I wrote, like, you a game, but I copied it out of a magazine. And that's what we had to [00:21:00] do back then. Right? We had to, I had to read the text in the magazine and then, or a book and try to write that same code and, and then go

back and find where I, where I made a mistake

to fix it. And I realized right then that I was not gonna do that anymore like that. I, I, and because even then on the Commodore, it was like, how do I, I. I can save this to a floppy, but at some point like that, that that program was just lost. Right. It was just gone. And, and to, for you to stick with it and then to take it to those other levels, I think is, it just shows how like we're, we're coming at this, this problem of architecture and, and AEC from different places.

But I, I find it so fascinating that so much of the innovation that we see today is based off somebody scratching their own itch and the intrinsic motivation of, of people to teach themselves a thing to do, to make something happen. And that just set the whole trajectory for your entire career. It's just kind of incredible to look back at it and think about it that way.

Marty Rozmanith: Yeah, it's [00:22:00] pretty cool. . It's also just being given the opportunity to do some practical applications so that you have some confidence. Like, um, my mother at the time was a dentist and she had this crazy thing where she had these file drawers full of like index cards where the, her staff had to figure out, all right, six from months from now, we have to send this person a reminder to come in and get their teeth cleaned,

right? And I'm like, that's such an easy problem to solve for a computer. You know, you don't need an army of people sorting through index cards every week trying to figure out who the hell they should mail things

Evan Troxel: mm-Hmm.

Marty Rozmanith: So I actually took the guitar 400 and I wrote her a database program that would manage the entire, like.

Process of, um, the re the re you know, essentially scheduling people six months out to, to do this and then basically printing all the labels that they could just use to stick on a postcard to send it to the person. Um, and so, you know, when you get the opportunity to do some practical application of just some strange weird skill that you have as a computer [00:23:00] nerd, um, and you actually see that, you know, all of a sudden, like these 10 people actually, it made their job easier.

Evan Troxel: Yeah.

Marty Rozmanith: Um, it's, it's very encouraging. Um, you know, that said, I didn't really know what I was gonna do when I went to college. I thought I might do con computer science. Um, and I, I really only applied to Penn State and the University of Texas at, at, at Austin,

Evan Troxel: Hmm.

Marty Rozmanith: and UT lost my application. I was like, well, they don't have a good database if.

Evan Troxel: You disqualified them.


Marty Rozmanith: they disqualify themselves and then, then they accept me. So I was like, alright, well this is an easy decision, I'll just go there. But, um, like, uh, I, I had to figure out a way to, to, to get, um, on the main campus and so I actually applied as a ceramic science and engineering major and eventually switched into architectural engineering.

Evan Troxel: Hmm.

Marty Rozmanith: but you know, sometimes things happen for a reason and you just end up where you're supposed to be and that's kind of how it worked out.

Evan Troxel: Yeah. Super interesting. I what you, you talked about that the 10 [00:24:00] people who found value and the thing that you did and,

and that still drives people today in AEC who are writing grasshopper scripts, right. For their own studio or, and it, and it's, it's dynamo and grasshopper and, you know, the visual coding, no code kind of tools that people now have access to.

Very different obviously than, than what we had growing up from a programming standpoint, but that people still enjoy doing, experiencing that exact scenario. And, and that's still what drives a lot of innovation in AEC, it's, it's actually pretty incredible that that threat is still alive very well.

Marty Rozmanith: Yeah, one of the, and so, um,

I kind of stopped directly writing code myself because I realized having done it a few times, that there were people way better than me at writing that code. And once things got complex enough to be c and c plus plus, I was like, I'm not the best guy to write that code. Uh, 'cause that's like, you have that, you have to gone to school for that and, and know [00:25:00] that sort of stuff and, and


Evan Troxel: be in it every single day. Right? Like

Marty Rozmanith: And I, I learned some pretty heavy math being a structural engineer, but you know, the,

Evan Troxel: Mm.

Marty Rozmanith: computer science guys have a whole different sort of field of math that they have to learn in order to do some of the stuff that they do. And that was not just not where I was schooled. So, um, when I got back into this, into technology as a consultant and then eventually back into software, it was more defining the product requirements.

'cause I knew how a software engineer thought, and I knew how a design professional thought. And so my real skill was being able to translate one set of vocabulary to the other set of vocabulary so that, you know, the, the software engineer would understand the problem they were trying to solve, and be able to talk to the designer and understand, you know, this is what I really needed to do as a, there are people who tell you what they want, but your job is to figure out what it is they actually need.

Evan Troxel: Mm-Hmm.

Marty Rozmanith: you know, what was it, Henry Ford said if I asked people what they wanted, they would've set a faster horse. Right? So, so the, the art of it is. Understanding how to take the input and then [00:26:00] morph it into determining what the actual underlying needs and root causes of that request are, so that you can then turn that into something

Evan Troxel: I'm, I'm, I'm interested in the Charles River early Revit days. Just from the standpoint of like, what were you inspired by? Because I know there was a few other, or maybe just a couple others BIM tools at that point, but was it really, I mean, did you have the foresight to kind of understand what the potential of what you were doing was, and, and were there other examples or were you really just solving the customer's problems, trying to pull that out of them to define what, what the things were that they actually needed to practice efficiently?

Marty Rozmanith: I thought what we did at Architectural Desktop was quite a significant development in, in software because we got away from Lions, arks, and circles, and we had objects that were actually representing real world things as far as Waldo window.

Evan Troxel: Yeah,

Marty Rozmanith: Um, the thing about that piece of software that it was pretty [00:27:00] by the infrastructure of AutoCAD that it was built on.

So, um, the, the software RD team did as great of a job as it could by building this entire infrastructure called object, ARX, uh, that would enable these things to work. But it was, um, purely speaking, kind of clunky and the workflow of AutoCAD where you had to basically do one floor at a time in files that, um, you know, there was an entire XF structure around that.

Evan Troxel: mm-Hmm?

Marty Rozmanith: Uh, meant that you had to do a lot of pre-planning before you ever did any design work. Um, and so one of the things I recognized when, when I saw Revit was that that entire, presupposition of having to do things one floor at a time and having an X-ref structure and all those things that were sort of the computer side of using an AutoCAD based solutions didn't exist in Revit because it was just a clean

[00:28:00] Clean page rewrite of a building modeler. Um, and in fact, the branding of Revit was not Bim, BIM was something Autodesk invented as a marketing concept, but the branding of Revit was the world's first parametric building modeler. And what parametric went was something up for debate. Um, uh, parametric in our view was the change engine that allowed it to coordinate construction drawings, whereas most people now think of parametric in terms of shape generation like Grasshopper or Dynamo or things like that.

But they're both valid definitions of parametric. But, um, the Revit parametric engine has more to do around coordinating sheets than it does, than it does geometry. And of course, um, you know, after I left, uh, I think the, the, the people who became product managers who were all very interested in shape generation put those sorts of things in there because, um, the market wanted it.

So now b it does both, it does shape generation and the coordination of sheets. But, um. In the early days, [00:29:00] the, the, the first part was that you could design a building and you didn't have to pre-plan how you were gonna organize the data just to make the computer serve your


Evan Troxel: mm-Hmm.

Marty Rozmanith: So that was the first thing I saw.

The second thing, which was my real big concern, 'cause I was working at that point for the number one product, being pretty well paid and having, you know, I don't know, 50,000 users was how is this small team, um. Who obviously have some bright people not just gonna get crushed by a behemoth like Autodesk.

And, and it was the CEO that they had just hired said to me, uh, big companies are just structurally incapable of doing certain things, right. We just basically we're gonna outrun them because we can just develop faster.

Evan Troxel: mm-Hmm.

Marty Rozmanith: is exactly basically what happened. Um, it was that, um, you didn't have to support the legacy infrastructure of a solution that was driving [00:30:00] whatever, a billion dollars of revenue, half a billion dollars of revenue.

And so you could just move a lot faster 'cause you didn't have any of those considerations to deal with. And so I just learned a lot about startup companies from the original Revit founding team. It was a fantastic team, not just the RD team that wrote the code, but the client support team and the marketing team and the sales team and, and the executive leadership team.

It was just an entirely fantastic team on, on all sides. It was a great place to learn about it.

Evan Troxel: In what year was that? I mean, what? This is like pre Revit

Marty Rozmanith: Yeah, I, I joined in the summer of 1999

Evan Troxel: Okay.

Marty Rozmanith: and I was employee 26 and I think Dave Lamont was employee number 25 . Um, who was the CEO? So, um, and the, the two founders, uh, Lena and Irwin, they had started the year before, um, with a space above a pizza shop. Uh, so I wasn't in the space above the pizza shop. I didn't quite even know where that was.

But, uh, we were in the, the Pink Palace in Framingham, and then we soon moved to wall fame after that, because we started, we started [00:31:00] hiring people really fast. Um, 'cause once, once the customer started showing up, then you have to, you have to respond,

Evan Troxel: you gotta deliver it. It, just to put this in context from my, from my point of view, I graduated college in 97

and so I had used AutoCAD at least 12 or 14 maybe, and three D face commands to learn three D modeling. And I had, we actually had a Form Z lab, so that was where I

was, I wasn't in the building information modeling database world at all.


was still very much file-based. And this whole x-ref thing that you're talking about, like the whole point of that is so that multiple people can work on a project at the same time.

Right? 'cause of course you could CAD the whole thing in one file if you wanted to lose it all at once, I guess. But, uh, the whole point of that was so that you could Have the elevations over here and the plans over here, and the sections over here, and people in the office could be working on those. And, and I guess assembling the sheets

Marty Rozmanith: Yeah.

Evan Troxel: happened via, you know, this really cool dynamic [00:32:00] system of X-refs. Uh, and, and so there was like that AutoCAD world and then to me it was very separate working in



Marty Rozmanith: were very separate. You had designers who worked in three D modeling ish stuff like Form Z, and then you had production people who, who made the drawings that they got paid for and that, and that took a lot of pre-planning. Planning. You had a CAD manager, right, who figured out how the whole thing had to hang together

and, and every job had a job captain who just figured out what is the sheet set and what do we have to do from a file standpoint to make that sheet set plot at the end of the day on a, on a plotter, right?

Evan Troxel: Which, and and this is still happening in Revit, like there's still

this huge discussion at the beginning of every project of how are we going to

Assemble this, is it gonna be every building's in a separate file? Are we gonna have, you know, like what, there's, there's still a lot of time spent trying

to figure that out, and I know this is something that, that you guys are, are going to be solving as well.

Because this this has, the thinking has shifted and that, [00:33:00] like, this isn't the kind of thing we should be spending a ton of time on every single project still

hours and hours, and then switching it, sometimes midstream because something changes on the project and it, it is still quite a, a bear to deal with, I think.

Marty Rozmanith: Yeah. You know, one of the things that I did, um, early in my career in San Francisco was we, uh, the architecture firm I was working for had, um, United Airlines as a client. And when the international terminal at SFO kicked off United called us and said, we know we have a lot of space at San Francisco Airport, we have no idea how much it is or where it is.

So I got this field survey, , I got the field survey, San Francisco Airport, and, um. , you know, that takes a long time. Um, and put it all into AutoCAD, uh, just to be able to show them where all the space they had was, um, which was, [00:34:00] you know, it was, you know, in the days before they were highly security conscious.

I still had the palm scanner in order to be able to walk out on the tarmac and, you know, measure the outside of the, of the airport. But I eventually put together a set of AutoCAD files that showed that they had 2 million square feet,

Evan Troxel: Wow.

Marty Rozmanith: And, um, so then there was this plan of, with the international terminal coming online, how they were going to take all of those people and move a bunch of them over there.

And then what space they were gonna keep, what space they were gonna get rid of. It was massive, like move, add changes problem. And there was nobody who had the appetite for trying to figure out how to do this with hand drawings. They were like, how are you gonna do this using AutoCAD? And so what I ended up doing was I ended up taking a, an access database and.

Kind of a rough facility management system, connecting it to AutoCAD. And I would literally print a color book like that thick every week with just everything they had [00:35:00] decided to do with the space. And so it was like an, it was a, it was a massive publishing job every week just to put out 2 million square feet of SFO space for United Airlines.

And so that really got me to the understanding of what it's like for a database to drive a drawing production system.

Evan Troxel: Mm.

Marty Rozmanith: And the reason that I wanted to go work for Autodesk when they made me the job offer was that I, you know, up until that point, production of drawings and design were very separate things.

And I saw Architectural Desktop as really the first place where you might be able to do design and production in the same system. And then I ran into a lot of that, you know, the, the presuppositions of AutoCAD, which designers didn't wanna have to deal with. Um, so then when I saw Revit, I said, oh, well this is even more in the direction of someplace where we might be able to do design and production in one system.

And I think it's just been constantly trying to get to that point where, 'cause what I would like to be able to do is design production and then construction. All in one system, , that, that's where I, [00:36:00] you know, the thesis I wrote back in 89 was around connecting design to construction so that all of that data can inform the means and methods.

Not knowing anything about the fact that an architect is a special kinda lawyer and that you don't have insurance that covers anything after the deliverables and you can't inform means of methods, otherwise you're open to get lawsuits. And so there's been very interesting business, uh, you know, having the part of, part of the, the good of having the MBA is now, I understand all of the things that prevented this from happening weren't actually technical things at all.

They were all legal things,

Evan Troxel: Yeah.


Marty Rozmanith: legal and insurance constraints that, that caused that from happening. And spending 10 years at DESO systems looking at how OEMs do cars or airplanes or elevators or industrial equipment like Caterpillar, um, you see that it's just a totally different organization because manufacturing's only about a, you know, a hundred years old.

The law predates manufacturing, well, like construction's like thousands of years old. It predates the law. And so the law in some ways was developed [00:37:00] based on construction practices. And what you find is actually that construction practices are the same wherever you have English common law countries.

And then in other places like France or other places where they have different laws, you actually have different construction practices because the two are sort of inextricable from one another.

And so we actually have interesting things that go on in countries that are not based on English common law because now technology is not the constraint. And if law and insurances in those places, they're different law and insurance. And so you can actually learn from those places. So it's been a fascinating one.

One of the things the So Systems did for me was it gave me a platform to see these differences worldwide that you wouldn't really be able to easily see if you were working for a smaller company.

Evan Troxel: Yeah.

Marty Rozmanith: That, that, that's been, uh, great for informing what's going on now with, with what we're doing with Skema.

Evan Troxel: Uh, a friend of mine, friend of the show, Clifton Harness from Test

Fit, he, he said, if you want to be [00:38:00] innovative in, in architecture or in technology, he said, you start with the OAC C contract. Right? Start with the owner architect agreement, because, so, so much of what we do is based on that, and there's

only so much we can do because of that.

Right? Uh, I, I think that what you're saying is, is right in line with that and, and it's incredible. Insurance law contracts, like all of these things, permitting agencies, uh, it's still based on printing. It's still based on that


Marty Rozmanith: It's based on the artifact.

Evan Troxel: yep.

Marty Rozmanith: And this is one of the things I learned from having tried these manufacturing companies and seeing how the OEMs do it from my time at the, so is that ? In every other industry other than construction, there are process engineers who have process diagrams of the way things happen at an automotive manufacturer or at an aircraft manufacturer.

And in fact, those process engineers have conventions just like other professionals, and they compare their process [00:39:00] diagrams to other people, process diagrams. And eventually, after 20 years, the industry comes up with a best practices process diagram for standard operating procedure for an automotive plant or a aircraft plant or whatever.

So you can literally go to a consultant and say, what is the best practice process for an aircraft? And they can tell you,

Evan Troxel: Yeah.

Marty Rozmanith: and nobody in AAC can,

Evan Troxel: Nope.

Marty Rozmanith: uh, I'm probably one of the only people who's ever tried to diagram using BPMN five, design and construction process. And it's an impossible problem because what happens

Evan Troxel: Every project's different.

Marty Rozmanith: Depending if you're doing a hospital, you've got medical gas consultants and you've got a whole bunch of piping that doesn't exist in any other building. And so the scope is totally different. If I'm doing an airport, I've got a baggage handling consultant who knows all about conveying systems, and those are all completely different.

And so the scope, the contract, and the team changes depending on the type of project and the process changes with the team. And so it's very, very difficult to use any process-based system like PLM in manufacturing to

[00:40:00] try

Evan Troxel: Mm.

Marty Rozmanith: the construction process because that's just not how it's organized.

And um, you know, part of what I learned from comparing the two is that really what. A's organized around is artifacts. You know, architects will make an artifact and then they'll go back and say, what worked, what didn't work? Okay, on the next one, let's not do this. Let's do this instead. And then they learn.

They learn from artifact to artifact, which is we literally directly implementing that into Skema where you take this old Revit stuff that you've been sitting there doing nothing. And we learn from that and put it into the new project. So it's just a lot easier to use. And, know, anybody who comes from manufacturing will always think of, okay, how do I, they they always start with process first and try and impose process and realize after a while that's not how it works here.

Evan Troxel: I,

I've had that exact

same experience.

Marty Rozmanith: It's, it's, it's just fundamentally different.

Evan Troxel: Yeah. A, a guy that I worked with on a project out of San Francisco at Project Frog, we were doing some prefabricated school stuff, and this guy, Ash, [00:41:00] he had come from automotive and he, it was like three years into Project Frog, and he was still like, I cannot believe how hard this is.

I, it, he thought, he thought it would just directly apply. He thought

they were gonna, they were just gonna figure it out. and and to your point, it was just like impossible to figure out because every project is a different set of rules, constraints, uh, team members, inputs, outputs, all, it's all different all the time.

Marty Rozmanith: And so there, there is a way to learn from manufacturing, but it is not by the, by replicating the process they use to make things. It's rather, um, you can productize pieces of construction and then use that to make overall construction more efficient. Like a great example is an elevator, right? An elevator is a manufactured product, yet it's different for every building.

'cause every building has a different number of floors, a different floor to floor height, a different structural system. And yet somehow they manage to manufacture an elevator on schedule and install it [00:42:00] and maintain it.

Evan Troxel: Right.

Marty Rozmanith: Um, and


Evan Troxel: they are, but they are always broken. Marty. Well, I'll just

say that.

Marty Rozmanith: it's, yeah, yeah. There are certain companies trying to apply that, you know, specified and delivered by owner principle

Evan Troxel: Mm-Hmm.

Marty Rozmanith: certain very time sensitive, um, buildings, like data centers, like just don't, don't bother the contractor with assembling the guts of a data center will do ourselves

Evan Troxel: Mm-Hmm. .Mm-Hmm.

Marty Rozmanith: Um, but you know, McKinsey and so all the, especially the so systems, they took notice of this, McKinsey wrote a report on construction heading towards modular, and they said 25% of the value chain of construction is gonna move towards modular, which is in many hundreds of billions of dollars of work in place.

And I think, you know, um, finance people saw that and said, oh, construction's turning modular. There's a huge disruptive opportunity. Let's get in the game. And that's when you saw all of these like. AI driven configurators doing massing based on developer proforma pop up, right? And all of a sudden they were just gonna come up with a feasibility study and we [00:43:00] apply some modules and boom, we have a end-to-end solution.

And I see that, and I say to myself, McKinsey might be right, but that doesn't mean construction projects are gonna be a hundred percent modular anytime soon. Like you can look at a hotel, like what Marriott's doing with bathroom pods, right? And the, the hotel is still engineered order, but now all the bathroom pods are modulars that they're shipping as units, right?

Or, or unitized facade or, or even kitchen pods or things like that. I see that as modular penetrates. The construction value chain projects are gonna go from 0% modular to 20% modular to 30% modular to maybe 40% modular. But you know, the most advanced work I've seen in modular and construction, other than very simple buildings is like 70% modular.

Uh, because every time you gotta interface with the ground, it's not gonna be modular anyway, so, so I see this, and, and part of the reason that I decided to make Skema in the fir, you know, leave my fairly [00:44:00] comfortable job at DESO Systems and go ride the wild bucking bronco of a startup again,

Evan Troxel: Uhhuh,

Marty Rozmanith: was the fact that I didn't wanna see a world where the engineer to order stuff was, was done in Revit.

And then there was this other system that dealt with the 30% modular stuff. I was like, designers will lose their minds if they have to design half the building here and then half the building here, and then try and figure out, out all fits together somehow. Um, and so that's part of the, that's part of the, the, the motivation for taking this on at this point, which is I see what's coming from a execution standpoint and designers can't directly get ahead of means and methods, but the systems can evolve so that they don't have to.

Evan Troxel: Hmm. The perfect segue. It is time to stop bearing the lead and talk about Skema here. So I. By the time this episode comes out, it will have been November 1st. It'll be

past your, your release date. So give us an idea of what Skema is. So [00:45:00] like, just let, let's start on the outside and work our way in.

Marty Rozmanith: Yep.

Evan Troxel: Tell us what Skema is.

You, you mentioned that, that you, you've moved from de so into Skema and you didn't think that you would get back on the wild bucking Bronco. So tell us kind of what, what was the spark there and, and what is so exciting about the work that you're doing now? What's, what's the potential here?

Marty Rozmanith: Yeah, so I guess I'll tell you. How I became aware of the technology team. So these, these guys in Eastern European, Eastern Europe had written this really bunch of prototype code libraries for doing modular residential production.

Evan Troxel: Hmm.

Marty Rozmanith: Um, and so they had written configurators, uh, different types of configurators.

They had written some for apartment buildings, some of them for, um, uh, mass timber office buildings, uh, some of them for parking garages. They had their, their, their, just had this competency in writing configurators [00:46:00] that dealt with manufactured systems. And so they were trying to figure out a way to bring some of this technology to market, but they didn't, you know, they had good technology.

And, and the, the, the most amazing thing about this technical team was that they. Didn't write this on somebody else's tech stack, like Forge or, or something else. They wrote all of their own math, just like the original Revit team did. The, the original Revit team had to write its own three D engine, its own constraints, solvers, its own, all of this stuff, right?

So the entire tech stack was written by that original Revit team, um, which is why in some cases Revit was so weird about what kind of surfaces it could do because they wrote their own surfacing engine. Um, and so this team wrote all of its own tech stack and they, they decided that the ultimate manifestation of the tech stack was these configurators.

Well, one of the things I decided to do, um, leaving deso systems was [00:47:00] that I was gonna see if I could pioneer a way of. Showing this change in construction that was coming towards modular and ended up going in with, with a friend of mine who was also a licensed architect and had done some commercial property development on a, uh, multi-family commercial apartment project in Massachusetts.

And we had talked about, you know, doing things that most owners wouldn't be willing to do and doing this in a, for, uh, affordable housing, not by making them cheap, but by using modular delivery to drive down the delivery cost of the facility so that we could, um, produce housing. Housing. It wasn't affordable housing, it was just housing that was affordable, which in Massachusetts is almost impossible.

Evan Troxel: Okay.

Marty Rozmanith: right, because our rent structure is the same as. San Francisco or all the other big tech places. And so we said, alright, we'll do this as a project because we understand design and construction, and this is just a good thing to do to show this as a, as a, [00:48:00] as a project. But we also wanna use it as a test beds for software.

And so after I left, you know, the, these various configurators that came out, all the ones that were done by private equities since about 2017, uh, the Archie Stars of the world, the delves, the, um, you know, Spacemaker, which was bought by Autodesk. All, all these configurators that come up with a, a project feasibility analysis.

I wanted to say, you know, as someone who's designing a project on a real world site that has slope differences and has, you know, a podium that has mixed uses like parking and commercial, and then residents above, could I actually use one of these things to do a real project? And I, we applied a bunch of them and none of them worked.

And so we actually had, uh, we hired an architect out of Boston. And after we went through these experiments, um, he ended up doing it in Rhino . So we reached out to some of these tech companies and we were like, look, we tried to use our system on this actual project and here's why it didn't work. But we, you know, basically [00:49:00] recorded the charette we did in Zoom and we'll send you a copy of it so you can see how we actually did it, you know, and, uh, these guys, um, that had developed what is now SSkemagot back to me and, and said, uh.

Okay, uh, let us work on it. And so, you know, I don't know, several weeks later they were like, Hey, can we have a Zoom meeting? So I, I had a Zoom meeting and they're like, we, we, we did it. We wrote what you wanted. I'm like, what are talking about? So they showed me this thing, which, which was called Skema, uh, which was basically, uh, some implementation of, of the ideas of, you know, solving this multi-family project in, um, in Massachusetts using their residential configurator.

But now with this, easier to use front end on the front of it, but all the backend hard math was all the stuff that they had written in the past. And I had, I actually put this, uh, company on the desso, uh, mergers and acquisitions team roadmap, but a couple years passed and decided, decided not to do anything.

And so I thought to myself, well, if these guys actually have a way of solving this problem that might make [00:50:00] a good piece of software,

and so. Probably half a year after I left a set of systems, I started talking to these guys about doing a, doing a deal where I set up a company to acquire the technology.

'cause we know we, we have an idea of how to take this to market and uh, let's do that. And so that's what we did. And we signed an agreement with them at the end of last year and started working on adjusting the roadmap in the spring. Uh, and essentially launched it at the a i A show in June where people got to get their hands on it.

Uh, but at that time it was still very modular, so it was very much a modular configurator for apartment buildings and that's what it could do. 'cause that's basically what the original prototype code they had written was. Um, what we're coming out with by the time this airs is all the work that we've done with architects over the last six months to take that idea of a modular configurator that can make apartment buildings and turn it into something that is far more general that can apply to all [00:51:00] buildings.

And so, in short, what Skema is, is a conceptual design system that can learn from your previous Revit projects using the layouts for things like, let's say you're doing a healthcare facility and you have exam suites and labs and surgery suites in previous Revit projects. It can farm those things out of the rabbit projects.

And put them into a concept catalog. So then when you're trying to resolve the part T of that healthcare facility, um, you can much more easily at a sort of jello cube moving things around level, um, solve the, the Part T. And then because we know what Revit data it came from, we can generate the Revit model out of it without you having to take the two intervening months to manually model Waldo window to represent what those gel cubes are in Revit.

Um, and so the idea there is that from a, from a metaphor standpoint, you're bumping up one level from wall's. Door was windows [00:52:00] to working with whole chunks of buildings as the way an architect would think about the program. Um, so I almost call it meta bim, um, in that I'm not doing BIM at the object level.

I'm not doing it at the whole chunks of building level, but the chunks are things that you've done. Previously, uh, that we're reusing in a systematic way. And so what's interesting about this is that we give you a conceptual design environment where you create a mass and then you start applying these catalogs to do the block and stack.

But even if we had an architect that started out on the same site with the same mass, their catalogs look totally different because the data in the Revit projects is different. So once they generate the Revit models, you know, architect one is gonna have their wall styles and their doors and their windows and their furniture fixtures, equipment lighting, all of that stuff that comes from their catalog of work is what appears in their Revit model for that project versus the architect two, their catalog of stuff is completely different.

So what's interesting about this process and this um, systemization of the [00:53:00] design process is that you don't lose the individuality of the architects, the buildings that result look like what that architect.

Because it came from their ingredients. And now that, um, some of the architects that we've been doing charettes with and have been putting this on project realize, you know, they can basically resolve a whole bunch of the building and then they can start having design exercises separately on facade and how they want the building to look and, you know, so they can resolve form and they can resolve function and then they can get into variations of that, uh, to serve.

Um. How they want the building to feel from the outside and the inside experientially. And part of what we're trying to do is our goal is never to make a hundred percent complete building our, we, we describe our ourselves as a fast forward button, uh, with the, with the idea that we're the fastest way to get to 60% complete.

So that would take you two months. We can do it in two minutes. Um, and then you just take the result of that and do what you normally would as an architect In Revit, it's just, we take a lot of the boring stuff that you have to manually [00:54:00] do out of it so that if you have all of the things that are experiential about the building, the entry, um, in some cases in a healthcare facility, the signature waiting area that's multi height and you know, got all sorts of interesting things going on.

That's where you spend your time as an architect, not on laying out patient rooms and labs.

Evan Troxel: Starting over every, yeah. So I'm gonna, my marketing brain is going in and so Mark, what is your zero to 60 time?

Marty Rozmanith: Zero to 60.

Evan Troxel: Zero to 60%. Like you, that's your

goal, right? The fast forward button. So what you, what is your zero to 60 time? What? What does that actually look like for somebody who's using a tool like Skema or using

Marty Rozmanith: Yeah, so we typically, I mean the, the the, we have a very risky marketing and sales approach in that. Um, I've worked for many, many large, large software companies that will do death by PowerPoint. Uh, we typically will do one of those just to get people to understand what we're talking about on Zoom. But, uh, our typical approach is we sign an NDA because we're gonna have the architect send us [00:55:00] their Revit models for anything that we're gonna use in a charette with them.

They have to send us two or three Revit models of that project type. So it's not like we're getting a big data lake with thousands of Revit models and training it on something. We, we need two or three rev models. And then, um, from that we will go into their office. They will invite people who've never seen Skema,

will make the accounts the first half hour of the meeting after we, they introduce themselves.

We'll teach 'em how to use it in an hour. Um, two hours later they will have a building in Revit, uh, which they didn't think was

possible before they walked in the room that day. And so that's generally, I mean, that's our biggest hurdle is, is convincing people that what we're talking about is not magic science fiction in the future.

That it's actually here and that, that you can actually use it right now if you want to. Um, so our zero to 60 time is about three hours.

Evan Troxel: Wow. It, it's gotta be really satisfying to you to watch those [00:56:00] people's aha. Moment. Right. And, and what, what is that like as a, you know, this goes back to your early days when you wrote

the the thing for your mom, right? And it was like that when you saw 10 people using this tool that you had made. And in this case, again, like achieving the, what seems to be impossible for most

people to comprehend.

Like, what is that, what's that like for you?

Marty Rozmanith: Uh, it is interesting and there's a lot of different flavors of those aha moments. Uh,

Evan Troxel: Storming out of the room? People just pissed


Marty Rozmanith: I mean, some, some people are like, holy crap, AI's coming, uh, but other, other people, you know, and, and what we, when we hold one of these charettes, we like to mix senior people and junior people.

We've had people who are senior because, you know, a lot of the people, we have a conceptual environment, design environment that does options, right? So it is made to do presentations, to win work.

Um, and a lot of the, your senior people are the ones going after those projects and they're losing two out of three projects because that's the win ratio, right?

And so [00:57:00] they're spending a lot of their time at risk. Um, so we've had senior people like that come in. They don't, they don't, certainly don't use Revit. Um, but some of them don't even use SketchUp. And they've used this thing and they . And two, two hours later they got a building. Um, that, that quickness of wind gives them confidence that this is not for other people.

This I can actually do it. Um, so that aha moment is, is different 'cause that can sometimes be a little scary for them. 'cause they've never, you know, they've always done everything on trace, right? So that's, that's, that's one level of aha moment. The other one is, uh, the junior people in the room, right? So senior and junior people in, in this type of charette.

Uh, when we first came out with Revit, it was interesting that, uh, a lot of people, like we, at the beginning of this call we talked about, you know, the people doing production with x-refs and AutoCAD. And at that time, you know, in the 99 2000, when you show somebody Revit, they're pigeonholed doing production on AutoCAD 10 hours a day [00:58:00] and they see this Revit thing and go.

This is my way outta being pigeonholed in AutoCAD. And what's interesting about the aha moment for these junior staff, uh, in these firms is they see this and they go, wait, this can do my Revit production work. This is a way for me to get out of being pigeonholed in Revit doing production work, and now I can do more interesting things.

So it's just the parallelism between those two, uh, was, that's one of the biggest surprises actually. I had not, uh, anticipated that, uh, that that's just come out of seeing the reactions of people and using it on projects.

Evan Troxel: let's talk about what it's like to actually work in Skema. What you showed me was, I, I loved it because I, we've built scripts that have done this,

and it was arduous process. Uh, so what you're doing makes, everything that I've done in the past seem completely obsolete. But the idea of just drawing a, a line of circulation and you pick a site, it's got a slope to it.

It's got, uh, contextual buildings. So you've got kind of an environmental aspect to this thing. Obviously, sites aren't, a building site is [00:59:00] not in a vacuum.

You, you need context, but you, you start off with this very simple concept of circulation and the kind of the double loaded corridor condition,

and then Uh, based on the architect's kind of library catalog of spaces that you mentioned earlier, you then kind of built the blocking and stacking based on a very simple version of those, and it automatically kind of populates and then you start to move things around. I, this was a very dumb version of what you explained.

I'm sure you can explain it much better. So talk about what it's actually like to use the tool.

Marty Rozmanith: Yeah, it's, it's interesting because I've, you know, architectural Desktop had a massing tool and a, and a spaces tool, and Revit has a massing tool. Um, so this is, you know, and, and I that we had one called building space Planning at the systems. So this is like my fourth time around on massing and space layout tools.

Um. The thing about [01:00:00] Skema is that it's extremely fast and flexible, kind of like SketchUp, but it's not just about making faces and shapes. So the idea is you start with a site context, right? With the surrounding buildings and all of the things that you have to consider and at, and you, you basically start out by blocking mass and you don't know whether the mass you have is big enough or not.

You've just got some rules of thumb based on whatever brief you have, uh, about where the building should be on the site based on, you know, sight lines, sun views, noise, whatever your criterion is. But once you get to, you know, you might do three or four different massing options just to try different things.

Um, within each of those massing object o uh, options, you're gonna assign space usage so that you can, from an analytics standpoint, see how much of each use do I have, do I have enough of each use based on the brief that I got? Um, how can I solve the


Evan Troxel: Mm-Hmm.

Marty Rozmanith: creatively on this site? Several


Evan Troxel: Mm-Hmm.

Marty Rozmanith: Um, [01:01:00] and once you get to that point where you have things roughly sized, both from a mass and space use standpoint, you can get into simulation. So you can look at sun, you can look at daylight, you can look at those factors to say, oh, this mass doesn't work 'cause I'm, I'm blocking all of the sun access to this adjacent property, um, day lighting's bad in this condition because of whatever other feature I have in my context.

So you can make, you can rule out some of your massing options. Uh, based on just some simulation. And we expect that to just get more robust as time goes on, because simulation's just one of these things in conceptual design being plugged in. I mean, if you look at form, form has a dozen different simulation engines for everything from wind to noise to whatever you want.

Um, and then once you, you know, once you get down to a couple different options, that's when you've gotta see if it's feasible. And that's when you really try and fit the proforma in. By doing the blocking, stacking and figuring out the Part T for the building, [01:02:00] that's where we really shine because that's when we can actually help just starting with circulation and exiting, then fitting in the parts of the program that you need to fit into that mass.

And you don't have to do it in that order. You can, you can go to the block and stack and realize, oh, I actually need to change the mass and then just . , turn that off, change the mass around, and then reapply, block and stack. So it's iterative


Evan Troxel: Mm mm-Hmm.

Marty Rozmanith: not sequential. It you can go in whatever order is, is useful to you.

Uh, but eventually what you end up with is a site context that has some mass that you've worked out because you've simulated it and you, and, and it's working from all of those simulations. And you've resolved the brief as far as the Part T and the block stack in that mass. And then once you're at that condition, that's when you can just instantly go to high LOD Revit data because everything that you've got there represents a placeholder for chunks of buildings that we have in that catalog library that can then reconstitute the building from that higher level, [01:03:00] uh, met BIM type of arrangement that you've developed.

So you don't have to think about the bim, you just, it ends up being a byproduct. Of that conceptual design process that you've done in Skema. And in fact for us, the two things are different systems. Skema AI is the conceptual piece that you actually do all the conceptual work in. And then once you have that resolved block and stack, that's what we use in a backend system called Skema bim that actually generates the BIM data.

And what we do is we take that and preview it in Skema so you can see what it looks like. So you could say, oh, that's not what I was expecting. And then you can turn that off, change the block and stack, or get rid of the block and stack change the Mac reblock it. So again, like the whole point of generating the BIM is so you have a touch point of did this work the way I was expecting or did some weird thing happened when I actually turned it back into a building?

But what's nice about that is in the current process, you would only find that out after a couple months of painstaking work. Like you would, you would get to the point and you'd be like, oh, I didn't like, that's not what we should have done here. You just get that answer [01:04:00] in like a minute, minute and a half.

And then if you don't like it, you just go back and try something else.

Evan Troxel: Yeah, I was gonna bring that up because the, the, how much time do we waste as a industry in that feedback loop right there.


Because it does take time to figure all of that out, to only find out that, oh, that didn't actually work. And so then you either have to decide to spend the time and do it again, or you have to just say, uh, we're gonna try to figure that out later.

Right. Or

as we go. right. and and that's bo both of those are, are painful decisions to make, to have, to make if you didn't do it right the first time.

Marty Rozmanith: Yeah. And I mean, design is an iterative process, so you're gonna go through that. It's just, um, what is the easiest way to get to the best answer,

you know? So that's what we're, that's what we're trying to deliver in, in this. Um, and I, I, I honestly believe in two things with software and that this is always applied for any software I've ever done.

Uh, the first is you have to meet the mirror mortals test. So there's software that works, but normal humans can't use it. And, and this is part of the problem with [01:05:00] some of these things, like Grasshopper is like that principle that doesn't use SketchUp. She's not using Dynamo, right? Um, so part of this is the mirror mortals test.

So a lot of what we do, we prototype in things like Grasshopper, but eventually we want to take the 80 to 90% that really shouldn't, is the, is the common thing that everybody needs to use. Across the board. And that goes into Skema, which is a web app where you don't have to install anything and you can just use it straight outta the box.

And that's the mere mortals implementation as opposed to, say, a grasshopper script that does the equivalent thing. But it has a very fragile instantiation environment where you need the certain plugins and all sorts of stuff to be in exactly the right place for it to work. Um, we wanna be a web app where you don't have to think about any of that.

So that's the mere mortals test. And then the other is the easy to use test. If it's easier, people will use it, and that's it. .

If it's easier for 'em, they'll use it. And if it's not, they won't. And, uh, so mere mortals and easy, easy ease of use test, uh, that usually leads you to the right answers from the standpoint of a software product.

Evan Troxel: [01:06:00] It, it is pretty incredible that SketchUp got that so Right.

So long ago, right? Because it, it, how many, how many ICON's in the UI are driving SketchUp that most people use on a day-to-Day basis. It's like five tools. And those are the ones that are, are right there

and easy to use. And is, of course, this is why it won so big in the industry.

So it's, it's kind of refreshing to hear that because yeah, software is powerful, but if most people can't use it, then it's not gonna get adopted. And I think that's, this is the hurdle that we have to overcome as an industry, which is the, the ever increasing gap from innovation between innovation and adoption.

Right? Adoption is so difficult. I've Led digital practice at a, at a large firm. And adoption is so hard because the deadline of the current project is the only thing that matters to most people. And so when do I have time to learn? When do I have time to try a new tool that maybe, or maybe isn't gonna work? Uh, [01:07:00] so it's, it's again, refreshing to hear this. And I, I wanna reiterate what you just said about it being a web app. Can you just kind of go around that, explain why you decided to release Skema as a web app versus a on, you know, a workstation based app or a, an installation based app, because I don't want it to. Go unnoticed. Uh, the, the major pros, obviously there are some cons, you have to be connected,

et cetera, so maybe you can talk through some of those. But the whole idea of what you said about Grasshopper and making sure the scripts are all installed on everybody's machine so that they can run the tools that they need to do the feasibility study.

And like that, that's a

nightmare for a lot of CAD and BIM and it people to have to manage. And if they don't have to manage that stuff with a piece of software as powerful as this, I mean, that is another reason to take a serious look at it.

Marty Rozmanith: Yeah. And, and we're not, um, we're not saying that people shouldn't do that because they get a lot of value from making something that 10 people [01:08:00] find useful. So, you know, for us Skema, we haven't implemented it yet, but it's gonna be a Grasshopper host so that you can take your facade script and actually generate it in Skema, just like you would in Grasshopper.

Um, but for the 80% of the stuff that everybody needs to be able to use out of the box, um, that'll be, that'll just be native in Skema so that people don't have to understand how to instantiate it or what they need to do to get it to start. so I, I'm not sure if that answered your


Evan Troxel: Well, well just the, the cloud-based aspect of

Marty Rozmanith: Yeah.

Evan Troxel: why did you decide to go down that road?

Marty Rozmanith: Well, I think just because everything's headed there, um, by doing this as a web app, we is, if my goal is to connect design to construction, it's very difficult to do that in desktop based software, right? Because, I see, uh, uh, a future where we have an ecosystem of connected web apps that use web services to talk to each other.

We've done a few of those things just in Skema [01:09:00] already, just to show this way, as opposed to, and I'm not against platforms. desa is a very powerful platform. Auto's a very powerful platform. Uh, but the idea of a platform as the guardian of your data is one approach to. Putting things on the web. The other is that you've got a series of apps, kinda like a peer-to-peer where they can talk to each other.

And that's basically what we're doing. So we've, for instance, on some of the simulation, we've done an integration with Cove tool because people are used to some of the Cove tool. Daylighting UIs and some of the other things that Cove tool does. So we just did a direct scheme at a Cove tool integration.

We're doing, we're generating architectural BIM data, but when you move from say, fully modular solutions, like what we had done previously to things that combine engineer to order normal construction with modular pieces, you need primary frame again, right? To hold things up. So. Uh, we've done some work with Thornton Tomasetti to take the block and stack cubes that generate the architectural [01:10:00] scope in Revit to their Asterisk, um, product that generates the structural scope, uh, BIM model at high LOD so that we can generate both and that they actually come out pre-coordinated.

And then from those two models we can generate using other AI vendors, MEP systems that are also pre-coordinated with the architecture and structure. So I see that the, the ecosystem of connected web apps is going to be able to solve things that have not been solvable in the desktop environment

Evan Troxel: Mm-Hmm.

Marty Rozmanith: and that, um, there's gonna be so much value unlocked from that, that it'll be a massive structural advantage for those that are, that are participating in that way.

And eventually, yet you, uh, if you really wanna impact construction, you gotta, uh, you have to impact the actual construction delivery process. So. Starting from procurement all the way to how things get sourced and made and delivered and installed on site. So, um, [01:11:00] to some extent, we'll we will systemize the front end of that so that people can take advantage of that and systematize the backend.

We might also end up systematizing some of the backend things like procurement and possibly even doing revenue share with designers so that they get some of the benefits of having done the modeling work without having to take on the liability of the means and method risks that they can't do because of insurance.

So there's, by doing this on the web, you open up a number of interesting business opportunities and models that just are not feasible with desktop software.

Evan Troxel: and just thinking about it from a development standpoint and releasing tools and bug fixes and updates, and how great is it when

it's so transparent that I don't even have to think about, uh, clicking a button that might nuke my project? I mean, it, it, I, I mean, you,

you take on that liability as the company, I guess,

but, but just that the new tools, it's always running on the most current version.

This is also another nightmare for BIM managers

around the world, right? Uh, which

is, how long do we keep it [01:12:00] in that version is everybody on that version. And just the amount of communication that has to happen around those kind of decisions is incredible and and complete waste when you look

at it from the big picture.

Marty Rozmanith: What's in, and the other thing about this is, it's interesting that this learns from your previous Revit projects, but once you have it in is Skema catalog, you don't have to think about Revit versions anymore.

Evan Troxel: Interesting.

Marty Rozmanith: that that might make life a little easier.

Evan Troxel: One, one of the things that you showed was the, and you, you talked about it here, is this idea of these catalog items getting plugged into the Skema model.

How, how squishy are they? Uh, because one of the questions I'm sure people have floating around in their mind is, you know, different depth to width ratios and, and if the Skema model is one thing, but my catalog item is another, you know, how, how does it

adjust for that?

Marty Rozmanith: So when we talk about the catalog, we're talking about, um, knowledge encapsulated in a Revit artifact from a [01:13:00] previous project. So, you know, if I think about cad, like AutoCAD, that's data lines, arcs and circles, and, and it goes data, information, knowledge, wisdom. So data is lines, arcs, and circles. Um, information is objects, walls, doors, windows.

That's why it's building information modeling. And we're bumping it up to. Knowledge. So the knowledge is encapsulated with how that surgery suite was laid out or how that exam suite is laid out. Um, and we're pulling that into a concept catalog in Skema. And then the main part of what is so big about the release that we're putting out in November is that, um, you know, you lay out the circulation and the exiting and then you can lay out things that are regular size based on what you previously did.

But you will have leftover spaces that aren't the same size and shape. And what Skema understands how to do is take the logic of the layout that it has in the catalog and morph it into the target size and shape, respecting [01:14:00] minimum maximum distances in target areas. To give you a workable layout. Now you can come back and edit it all on Revit after the fact because it's all native Revit stuff that you can edit.

But the whole point about taking data, which represents knowledge over decades and reusing it in a systematic fashion so that it's much faster to, to, to get to resolve design is the main thing about the catalog. And, and so, you know, people might ask who are, you know, Revit users? Is there a family editor for the catalog?

Yeah, it's called Revit. Whatever you put in Revit you can put into the catalog. It's just a matter of that's the way it works. So, you know, people that have been using this on projects at some of our early firms, they realize, oh, well if I want actually standards of quality in my architecture practice around sustainable materials in the projects, I can just do that by loading them into the catalogs that people use.

And then by default it'll be the easiest thing for them to do is just use that. And it's the opposite of the garbage and garbage out. If I want great stuff coming out the back, I put great stuff [01:15:00] into the catalog and then great stuff comes out the back on all the projects. So, um, firm principles that our technology leaders are thinking about it that way is that they have the opportunity to enforce quality and sustainability through this catalog mechanism, which is a lever that they haven't had in the past.

Not only that, it's a lot of, you know, a lot of some of these artifacts were done by senior designers who aren't at the firm anymore. So

you can't go ask them how to lay out that surgery suite. But here you have 10 of 'em that have been sitting on a file server somewhere for 10 years, and now you get to leverage it and, and look at it in a new context of design for a new facility and then sit down with our architect and say, is this a good layout?

Is this a bad layout? How, how would we do this differently? And then you can go back and update it in, in the catalog and then use it on. It's a way of systematically improving your future projects by harvesting what you have on current and previous projects.

Evan Troxel: So is that what people shift to? There's, there's people who are, like you said, gonna be disrupted in their normal two hour or [01:16:00] two month long, uh, CD drawing phase or, or, you

know, end of dd, beginning of cd. So if, if that's gone, that that amount of time is gone and the people aren't needed to do that because the tool's doing it for you, what are people shifting to? Do you, what do you think about that?

Marty Rozmanith: So most of that acceleration happens in the DD process. And in fact, this was recognized by some of the principles that we showed this to, um, in, in these charettes where they said, you know, we've done this in the past where we've done a block and stack and grasshopper, and then we have guys go spend a couple months to model this in Revit.

What we find out is that . When we get to the end of the two months in Revit, what we have in Revit doesn't match what we had in Grasshopper because we, we take those, those blocks and we start off with cubes in Revit and we start blocking things in. But Revit's, parametric, you know, somebody makes a decision to move a wall over and then that propagates and something else moves over.

And that's just the way Revit is, right? It propagates changes to [01:17:00] keep things consistent. So the construction drawings stay coordinated, but what it does is over two months, you have the net effect of all of those changes, which in this format represents variance. You have what you started off with in concept design, and now you ended up with something else in production because.

Those people working for two months introduced a bunch of variants because they have an accumulated set of decisions. One of the things about Skema is that it avoids all that because it starts with these block and stack and immediately generates the same Revit data out of that. They absolutely match all the exiting all of the, you know, sizes of things are the same in both the, the cubes in the block and stack rep are the same as where the walls are in the Revit model that comes out of it.

And I should say, by the way, that. I'm saying Revit a lot, and we use Revit in a lot of the examples because Revit has so much market share, but for us, we're kind of BIM agnostic. Um, input to the catalog can come from any BIM system. You know, it could come from anything done by [01:18:00] Graphisoft or Nemetchek or dis even Dassault Sytèmes.

And on the output side it can go to any BIM system too. So while we're saying very Revit specific, and that's where our hearts are, obviously having built it and knowing we, we, we have a lot of tribal knowledge about Revit, which is why when we do one of these things and we do a presentation, uh, after one of these charettes in the office with people, we get just as many questions about how the Revit data is structured as how Skema works, right?

People, people really are, uh, they have, uh, strong convictions about the way they should structure Revit data. And so usually we have all the right answers to those questions. So

Evan Troxel: Yeah. Who better to ask? Yeah,

Marty Rozmanith: Um, but that's not to say that you can't use it with some other BIM system. I mean, it's absolutely, there's nothing prohibiting anybody from applying it with different inputs and outputs, uh, than, than Revit inputs or Revit outputs.

Evan Troxel: It is gotta make it a great presentation and communication tool then, right? Because if, if you can kind of dial it back to the blocking and stacking [01:19:00] Skema, totally assured that it's gonna match up with what Revit is gonna show then. Because a lot of clients don't speak Revit, they don't speak plans, they don't speak those kinds of things.

And if you can simplify that and show them in a, in a graphical, experiential way, the kinds of things that you're trying to communicate with them. But, but again, be assured that it's going to work with what you've gotten

Revit. That's, that's, this is a, a big deal.

Marty Rozmanith: Yeah, and I, uh, up on our blog. The, uh, I have a, a video I did of just taking block and stack output from Skema into Veris and Revit and just doing AI generated imagery very early on the project just to show a client does this feel right? Um, but having the geometry be correct about the way that, you know, where the buildings will actually be and how big they'll actually be, and that sort of stuff to guide Veris into producing the right [01:20:00] size of image.

Um, and it's still very early days on all that AI image generation stuff. I mean, you get into, sometimes you still get into weird scale problems that, uh, you know,

people in, people in AEC tech circles will talk about. Um, but I'm sure those things will get solved. But yeah, the, the, from the standpoint of just taking the, the conceptual data and using that to.

On its own merits. It's absolutely valid.

Evan Troxel: Yeah. Awesome. Well, what, what have we missed in this conversation that you wanna make sure that the audience hears about? Uh, you, you've got a new website, domain name launching. You've got, uh,

Marty Rozmanith: Yeah, it's live as of today. Skema.Ai.

Evan Troxel: Okay. And that's Skema.ai.

Marty Rozmanith: ai. Yep.

Evan Troxel: All right. And so people can find out more information there. Uh, where else should they be watching for all things Skema as we move forward?

Marty Rozmanith: I would say mainly, mainly the website. I will be, um, speaking next week. Well, this will air after that. [01:21:00] Uh, I'll be speaking at AC Tech in New York. Um, and then you can come see us if you're gonna be at Autodesk University. We're not exhibiting, but we will be at the show. And, um,

Evan Troxel: Gorilla, gorilla


Marty Rozmanith: guerrilla marketing.

Evan Troxel: Back back to the early Revit days. Alright, awesome. Well, Marty, thanks so much. This has been a, a really fun conversation. I love the history part of it and I love where it's going. So, uh, looking forward to future updates and I'm sure we'll have to have you back to do some catch up once, uh, once we kind of, once you get through this launch and, and see where things are going.

Marty Rozmanith: Thanks so much. It was a lot of fun.