Transcript of Episode 16

Dave: Welcome to the Design-Build Show. This is my great friend, Mr. Austin Wei here. 

Austin Wei: Hello. 

Dave: Anyway, I beat this dude’s ass all the time. As you can see, I’m much bigger than him, but he puts up a good fight. 

Austin Wei: Thank you. 

Dave: Yeah, he’s actually a good wrestler. And I feel sometimes embarrassed because he holds his own against me and he shouldn’t. 

Dave: But anyhow, Mr. Wei, you are a computer geek? 

Austin Wei: Yes. Well, I guess, more specifically I’m a web developer. Mostly code in node, which is JavaScript. Do front-end development, back-end development. Basically, help build web applications for clients and whatnot. 

Dave: Cool. 

Austin Wei: Yeah. 

Dave: You lost me at a certain point. 

Austin Wei: Okay. What do you want me to back up to? 

Dave: Man, it’s fine.

 Austin Wei: Okay.

Dave: I go into glee a lot on this subject. I think I just like calling you a computer geek. 

Austin Wei: Fair enough. 

Dave: And let me be ignorant with it. 

Austin Wei: Okay.

Dave: But I wanted to have Austin on the show because it’s comparable and relatable to Design-Build. We build buildings and Austin builds… What the hell you build? 

Austin Wei: We’ll call them web… We’ll call them applications. 

Dave: Applications on the computer.

 Austin Wei: That’s right.

Dave: Computer stuff. 

Austin Wei: Yeah. 

Dave: And there is a design component and a build component. 

Austin Wei: That’s absolutely correct. Yeah. Sure. 

Dave: Okay. And part of the Design-Build movement is educating folks on what Design-Build is and how it relates to… Compare it to other industries and professions because that gives one more reality on the current state of the industry in how it’s fucked up in terms of having this separation between the designer and the executor, the architect and the builder. 

Dave: A great analogy is a chef who never cooked. It would never make sense to have a separate person who just wrote recipes and then somebody who just cooked. And particularly, maybe that exists in terms of a recipe, a cookbook, right? But the person who wrote that cookbook has cooked a lot. Whereas in our profession, the architect is separated and disconnected from the builder, their education is in particularly. And so it’s helpful to look at other industries and relate it. So we were talking and you were saying, “I’ve heard of this term architect.” What does that term mean in the application, web world? 

Austin Wei: Well, I mean, in my mind, I guess, the architect is the guy who lays out… So usually with any application there’s some sort of problem you want to solve, right? Let’s say it’s, I don’t know, watching videos, okay? It’s entertainment, like Netflix, okay? I mean, there are a million ways to go about it. The architect, his job is essentially to, based on the existing technologies available, to solve that problem, he decides, okay, here’s how we’re going to store all our videos. Here’s how we’re going to make these videos searchable. Here’s how we’re going to present the videos once they’re requested for. Here’s how we’re going to bill people. So he’s got to know enough about his tools and the technologies and their limitations so that he can put them all together and how these different components talk to each other to provide the end product of allowing an end user to watch a video when he wants. 

Dave: Got it. And is he overseeing the whole process of the execution of that outline that he sets up?

Austin Wei: I mean, I can’t… I don’t know for all companies. It’s really tough to speak to that. But in my understanding is generally there’s… And also it depends on the size of the project. I mean, if you have somebody just building this website to showcase my art project, I mean, you’re not going to need a huge team. One person can probably figure that out by themselves. But if you have something like a huge application, like Google or Netflix or whatnot or Facebook, you probably have a guy this chief technology officer or somebody like that who’s basically responsible for putting all the pieces together, knowing what is in their system, knowing what different components are in the system, knowing what security issues are in their system. And maybe security becomes such a big issue that you put somebody in charge specifically of security. You have a chief security officer. So it really depends on the complexity and the size of the project you’re doing.

Austin Wei: But at the end of the day, ultimately I think for a product to be successful and cohesive, you would want somebody who kind of knows at least on a general basis, all the different components and technologies related to the project and how they relate to each other. 

Dave: Yeah, makes sense. Because then you can oversee it competently. 

Austin Wei: Yeah, absolutely. 

Dave: But that position isn’t always called an architect. 

Austin Wei: No. I don’t think we would necessarily call it an architect. 

Dave: Could be a called, you were saying project manager? 

Austin Wei: Project manager, chief technology officer. Yeah. It really depends on the project. 

Dave: Got it. 

Austin Wei: I mean, even within a company like Google, they’d spawn tons of other sub projects. So you have Google photos, which is under the Google umbrella. So, I mean, I have no idea how their organization works, but I’m just guessing that their main Google chief technology officer has a concept of what’s happening within Google photos. But the Google photos project has somebody who’s overseeing that project who then relays whatever information necessary to the other guy. 

Dave: Got it. But this term architect in the computer world, it’s not necessarily super well defined? It doesn’t mean somebody who just stylistically creates the look of the deal and then it’s going to-

Austin Wei: No. In my mind I would think the term architect, if I saw it in a technology related context, I would think relates more to the what goes into your product, how is it put together, how do things talk to each other. So it’s not so much necessarily the physical layout of the application, how the user interfaces with it. I mean, you could have somebody named a UI architect. A user interface architect could be in charge of that and that would make more sense. But if you’re just going to throw the term architect out there, generally speaking, I would think mainly somebody who deals with the actual design of the component. And when I say design, I’m not saying visual design. 

Dave: The workability of it. 

Austin Wei: Exactly.

Dave: It’s really the whole, the full picture. 

Austin Wei: Exactly right. 

Dave: Which makes sense because that is needed to start off with to create up a project up for success, right? 

Austin Wei: Sure. Yeah. Absolutely. 

Dave: And that is in an ideal world what the architect in my industry does as well. The issue is that architects today don’t build and as a result of that don’t know what costs are, don’t know what schedules are, don’t have all the resources in terms of the specialists that would execute the work and can’t always think with that. So there’s an inability to set that outline with all the proper components. They might be able to just focus on specifically design, but just as in a computer project, if that’s all you’re focusing on, the thing may never ever actually work.

Austin Wei: That’s true. 

Dave: And so not a real product. 

Austin Wei: That’s true. Yeah. 

Dave: And you were mentioning a thing you’ve seen occur is the salesperson, who’s actually getting earlier… is the earliest person on this… start of this project. Talk about that. 

Austin Wei: Sure. So, I mean, I’ve been uncertain projects where there is a product, let’s say it’s a service to handle customer emails or something. So one of our clients who wants to use our software, they basically buy our software to send out email campaigns to their clients, right? Just whatever. Some random idea. Anyways, what happens is the sales team will talk to that person and start promising things like, “Yes. You can customize the look and feel of your email. And you can filter your email list by where they live or their age group,” or something like that. And those requests or those features aren’t actually necessarily built in the software. So what ends up happening is you have a guy who has no concept of what it takes to actually implement those requests making the decision and design decision about how the software should behave. So it sounds like a similar case where there’s a disjoin in communication between the guy responsible for design and the guy actually responsible for building. 

Dave: Yeah. And so what happened? What ends up happening there? 

Austin Wei: Well, obviously either: A, you can’t deliver; B, you have to develop like crazy. Spend a lot of resource and time and energy on actually trying to meet the requirements. Or, B, you can’t deliver the product and you lose a client.

Dave: Yeah. Amen. For me, that was very real because I do the sales for my company. And initially what I’m doing is in a very short amount of time, go to a home and think with all the components, think what the problem the client’s trying to solve, just same thing. There’s a problem we’re trying to solve. What’s the best way to do that? And I’m not going to nail it on that meeting that’s why there is a design process. But I do want to set expectations broadly at a high level of like, “Hey, here’s what we can do. Here’s what costs look like for that versus this.” If you’re not able to do that, I could create the… I could dream with this client the most fascinating, amazing design but if that is disconnected and that conversation never brings in let’s say cost, it could be a complete… It’s just not going to happen. So, yeah, that’s very analogous. That’s pretty cool. 

Dave: And we’re both sports fans. You like the Eagles? 

Austin Wei: No, I just like football in general. 

Dave: Okay. All right. And I think it’s relatable to sports too. Let’s take a coach. I was thinking about this. So Brad Stevens… We’re in Boston. That dude was not in the NBA, right? He’s the head coach of the Boston Celtics. I don’t know if he played in college basketball. 

Austin Wei: I don’t know. 

Dave: But I guarantee you he played basketball. I guarantee you he played basketball and he might not have been the best basketball player, but he made… He can think with it all, right? He can understand it all. He can’t go on the court and compete and never could with the level of that. And we were talking about, especially as technology develops, it’s going to be impossible to do every single facet. But there does need to be somebody in charge who can actually control what play is going to be run and what have you. What do you think about?

Austin Wei: Well, I agree. I mean, I think that in order to successfully design something, and design it in a way that’s realistic enough for it to actually become a product, you have to have some practical experience with the underlying components. I mean, you can’t just start whipping stuff up and then you have no way to implement it. 

Dave: Yeah. Yeah. And as a project gets bigger, I think this is another comparable, as a project gets bigger and as technology develops there’s more specialties, right? 

Austin Wei: Sure. Absolutely. 

Dave: There’s more intricacies and so… But it makes it all the more important to have this controlling, accountable entity, otherwise it’s where’s it going? 

Austin Wei: Exactly. Yeah. I mean, and I think you do see that in certain projects when… I mean, being on certain teams you feel the turmoil. There’s different departments. Somebody in charge of quality control. Somebody is in charge of development. Somebody is in charge of actually managing the project. And if there’s not somebody at the top who knows all of those different aspects, and what goes into those different aspects, there can be a lot of infighting within the team.

Dave: Yeah. Is it in your industry there’s always somebody in charge? Is that always a… It’s just known in your industry? There does need to be somebody like that wearing that hat? 

Austin Wei: I guess, it really depends again on the size of the project and the company, number of personnel. I mean, ideally, yeah, somebody knows everything that’s going into it. They might know… Not know how to actually do it, but they know enough about the technology, about what it does and its impacts so that they know how it’ll affect and play with the other aspects of it. 

Dave: Got it. Can you ever think of a scenario where a client would say, “Hey, I’m going to hire this company to a design my stuff and then I’m going to hire this company to build it.” Could that be a thing that… Does that ever happen? 

Austin Wei: I mean, there are certain aspects when that happens. I mean, I could see a case where the client says, “Okay. Here is the user interface design. This is how we want it to look. These are the colors we want to use. Here’s an example of how I want it to appear when somebody visits my website,” and then some other guy comes in and actually does the development. But in that particular case, I think what happens is that is that the coder, the guy who’s doing the development, knows enough about his tools to be able to take that vision and translate it onto a webpage.

Austin Wei: But there are definitely certain instances when, this is actually a problem that you run it to a decent amount, when the designer doesn’t understand the technology behind it and makes some requests or some visual features that are either very difficult to implement or would require considerable amount of code to do. And somebody who does have both the artistic ability and the coding ability would be able to steer around some of those fantasy or less easy to implement features so that definitely does occur actually. 

Dave: Yeah. Cool. And I’d imagine it would be possible if that person is kind of like that architect. Those could be separate entities in terms of if that person who created the outline of the program or app or whatever could think with the whole execution while it was setting up that outline and then that entity that took it, who’s going to develop it also could think with the full components. That could work, but it’s not necessarily set up… There’s more opportunity for some shit being problems. Austin Wei: Yeah, sure. I mean, you would get more back and forth like, “Hey, there’s no way we could actually implement this special menu that you’ve designed. How about we do this?” Or they’ll say, “We can’t do this because ABC.” And there’s going to be dialog back and forth in that. That’s obviously time lost or whatnot. 

Austin Wei: But the problem is not everybody has their feet in both the aesthetic and the actual implementation, the technological aspects, so you end up with situations where you do have a lot of back and forth communication.

Dave: Yeah. Yeah. I think in that scenario too, the person who’s going to develop it and execute it would need to take ownership, full ownership, for what came before, right? 

Austin Wei: Yeah. Sure.

Dave: I have a comparable is there’s this company, and it’s a common thing you see in my industry, where it’s not one entity, but firms are pairing up early in the design process, an architect and a builder. But they’re collaborating and there is an understanding of, “Hey, I’m going to handle this aspect of it, the design. You’re going to make sure it’s buildable. We’re going to work together,” and they’re collaborating. But the only way I see that really being effective… And there’s this company called Bensonwood in New Hampshire, they do amazing work. They often have clients who work with a separate architect, but they are always the engineer of record. Meaning they will take those and make them their own, so they’re then taking ownership for it. And that gives the client… That’s a huge deal because the clients never then going to have this back and forth. You know what I mean? 

Austin Wei: Right, right, right. Yeah. Makes sense. 

Dave: You know what I think? I think our industries are going to parlay at some point.

Austin Wei: Yeah. I can see that. 

Dave: Just become one. How can you see it? I’m serious because like 3D printers. 

Austin Wei: Yeah, I mean, sure. 

Dave: That’s all technology. I don’t know. It’s that’s more technology than building. But you can Google it and see a building being built with a 3D printer now. 

Austin Wei: Sure. I mean-

Dave: And it’s not going to change. I’m going to go off on it a little bit. I got some more ideas.

Austin Wei: Go ahead. 

Dave: And then you have a BIM, right? Building Information Modeling. This is the new… Instead of AutoCAD where you’re drawing every line you have components. So you basically can build the building with all its components and see through it ahead of time. At some point with 3D printing you’re going to be able to do that and then press print and it going to do it. It’s just going to build itself. 

Austin Wei: Yeah, I could see that. 

Dave: So it’s good we get on board with each other now because we are going to parlay, so let’s just… You guys should just adopt Design-Builder because I feel like you don’t have a name for the dude in charge. You got project manager, architect, computer geek, informational security, whatever the hell you’re talking about. So what do you think about that?

Austin Wei: Well, we’ll put it out there. 

Dave: Yeah. 

Austin Wei: Okay. [crosstalk 00:20:49]- 

Dave: Yeah. Because Design-Build is just the mindset. It’s really just a mindset of accountability and ownership for projects. That’s really what it comes down to. And that’s why I love interviewing guys like Austin because it is relatable. 

Austin Wei: Yeah. Yeah. I mean, it’s definitely a very interesting concept and to see how the architectural field, construction, how it got separated out is very interesting. 

Dave: Yeah. Yeah. It was never meant to be and it doesn’t really make sense and we bringing it back.

Dave: And thank you very much. 

Austin Wei: You’re welcome. 

Dave: I appreciate it. Austin’s going to beat me up after this. And any parting words?

Austin Wei: No. 

Dave: All right. 

Austin Wei: See you. 

Dave: Peace out.