Intro: This is the Pro Perspective from Houzz Pro, where homebuilders, designers, and industry experts share their views on running a modern firm.

Liza Hausman: Do you ever think about hitting the reset button for your business? You know things aren't working the way they should. It's just hard to stop the train. Paul DesRoches and Dave Greksouk of MOSS Building and Design did just that. Together, we dive into the how and why, plus the results that made it worth the effort. Hi, everybody, and welcome to today's podcast. I'm Liza Hausman, vice president of industry marketing with Houzz.

I'm so excited to welcome today, Paul DesRoches and Dave Greksouk, the CEO and the principal and the VP of MOSS Building and Design. Paul and Dave have developed a unique team-based model at MOSS that has helped deliver a consistent premium experience to their clients. Today, we're going to talk about the importance of being able to hit the reset button on how your business works, and why taking a step back to evaluate how things are working can really make a difference. Welcome, Paul and Dave.

Dave Greksouk: Thank you.

Paul DesRoches: Thank you.

Liza: I'd love to start and just give folks a little bit of background on the two of you and the company.

Paul: Sure. I actually started in construction when I was eight years old. I went to work for my dad in the summers. He's a carpenter. When I went to college, after I graduated from college, I went on a different path. Met the founder of this business. When I moved into his neighborhood in 2008, was getting my MBA at the time and wanted to do something different. I joined MOSS in 2012 as the chief operating officer. In 2020, moved into the CEO role when the founders decided they wanted to move on and retire.

MOSS has been around since 2001. The original founding idea was that-- the company was named after one of the founders, Pete, and Jason, who are father and son, Pete's father, his name was Paul, and his nickname was MOSS. They named the company after Paul, when the reason being is that, he espoused all of the values that they wanted the company to be run on.

He worked for the phone company for 40 years and then when he retired, he was the handyman around the neighborhood, just taking care of all the, all the people. MOSS was really founded on the idea that we would really take good care of our employees and take care of our people, and then therefore they would then take care of the customer. That's the basis of it. We're a DC Metro firm. We're headquartered in Northern Virginia. We serve DC, Maryland, and Virginia, with the bulk of our business being in Virginia.

Liza: I love the community aspect of that story, by the way. I think it really is such a nice example of that philosophy of taking care of the people that are around you, and helping them. A nice founding story. Dave, I guess, how did the two of you meet, or how did you end up working together in this business?

Dave: Sure. I started in the remodeling construction business in 2001 with a regional Mid-Atlantic kitchen and bath company that my dad was CFO and partner of. I was coming from a tech-wide area network back in the day, long-distance telecom industry. I started with them in their dealer network and eventually worked my way out to the retail branches and supported a variety of different teams and functions there. I was there for quite a bit of time, almost 10 years.

From there I went to a national window manufacturer, supplier. Then it was there where I met Jason, Pete, and Paul. Through just conversations, we turned out to be a good fit. I came on board almost 11 years now as the vice president of sales, trying to do some specific things in that world. Then as Paul mentioned in 2020, had bought the business out and moved into more of a general role here at MOSS.

Liza: Nice. Can you tell us just a little bit about the types of clients and projects that the company does?

Paul: 75% of our revenue comes from additions. That's our bread and butter, usually additions with master suite and kitchen addition. We do a lot of interior models, do a lot of just kitchens and some bathrooms, and some basements. As you can see, we have a beautiful basement behind us. That was one of our projects that we've done. The types of customers that MOSS serves, we're in the DC metro area. I've heard this said to me, and I don't know if it's true, so don't fact-check me on this one, but that is the highest percentage of type A personalities in any metro area ever.

Maybe the metro area says that, but in the DC market, for sure, that's the case. I think this is a fact. 60% of the people that live in Northern Virginia being Fairfax and Loudoun have master's degrees, which is a very high percentage, obviously. Our customers are people that run big government contracting firms, attorneys, all in all, the rest. We're typically looking at people that have a pretty high income. They have a lot of equity in their house. I think the average home sale in Fairfax County and Arlington County is probably close to $1 million, average single family home value.

We're looking at customers that are pretty very sophisticated, very sophisticated buyers, very sophisticated people. They're looking for a sophisticated turnkey experience. That's really what we're trying to provide for them. We're a full-service design build firm. We have project designers, project architects, project developers, and project managers all on staff, as well as project craftsmen that work in the field. We're not working for the Bill Gates of the world, but we're also working for a very sophisticated customer.

Liza: Makes sense. I spent a summer in DC, I remember it, the pretty intense town. Makes sense that that's the clientele. It's interesting because you talk about who's on the team. For folks serving customers like that, there's probably consistency, firm to firm about the types of roles that they have on the team. What's unique that you guys have done is really thought about serving the customer, not just from a process or some of the obvious touchpoints, but really all the way down to how you've organized your people and teams, and processes. Maybe share a little bit about how the company is currently organized, and then we can get into how you got there and why.

Paul: Sure. Like you said, the typical organizational structure, which would be called functional, is where you have salespeople, which we call project developers, you have architects and designers, and you have project managers, and the baton gets passed between the different departments. With a real focus on execution and optimization within those departments. What we've done is we've flipped it on its side and said that what we're most interested in is not necessarily functional optimization. We are most interested in project optimization and the customer experience.

We're organized by a project team. Each team is like a little remodeling business where there's a project developer, traditionally called a salesperson, an architect, a project designer, and a senior project manager with other project managers reporting to that person. Each team is responsible for a geographic area within our market, and they operate somewhat as autonomous business units within the company. They do operate with a consistent process across the organization.

Liza: How does it work differently than a functional model? Maybe just compare and contrast a little bit to how things work in a functional model versus this project-based team.

Paul: At its most basic level, it's probably easy for everybody to understand that the sales organization is its own function. Within a sales organization, traditionally, you have a pretty big disparity amongst performance within that organization. You'll have your top guns, your high performers, and you'll have your people that are new or at the lower end of performance. What will end up happening is your top gun salespeople end up selling the majority of your projects, and then that project would be then passed to the architect and design field.

Depending upon their backlog and their existing workload or maybe who might be good at doing that sort of a project, then that person, that architect and that designer might be tasked with that project. Then the same thing along with the project management role. What that creates is it obviously creates high performance within certain functions, but it creates a little bit of a disconnect. I think people tend to overlook what's called transaction costs, which is the cost of transferring the information and the project between the functions.

If you got a salesperson that has sold a ton of projects, and they've got a ton of projects that are being flowed through the system, they are focusing on selling new projects, they may not be as available to help the architect or designer, or the project team down downstream. What a team organization does, this is a little bit different, is each salesperson/project developer is accountable for a certain amount of sales that flow through that organization, and it's much more balanced in terms of what they sell and how much they sell. The reason we're able to achieve that is through the fact that the team is working in unison to help that project developer sell that project.

That flows down through the entire organization. A good example of that is you have a project that, say, a new salesperson comes into your organization and they have a project that is maybe a little bit more challenging of a project for them to sell, say it's like a large edition with an interior model, very complex to try to figure out what the right project is for the customer. Our team will get involved in that sale and they'll get involved in helping that project developer, that salesperson create and identify what is the right, most value-added project for the customer.

That allows new, less experienced salespeople to come in and start selling larger projects. It also prevents errors from happening. If you have a newer salesperson that may not be as comfortable with providing, being able to estimate, or be able to write the contract, they can make mistakes, or in that early phase even if they are able to sell it, and those mistakes will then be transferred downstream.

That's a simple example at the start of the project, but it extends back into the architecture and design where the project manager and the salesperson are getting involved, and ensuring that that project vision, the vision that the customer had for the project is being designed and architected, and that we're staying on budget or we're expanding the budget per the customer's request. The same thing happens downstream. You're really talking about a highly collaborative environment where they're all focused on executing on the customer vision.

Dave: Then the team-based approach, the project developer, sales, pre-sale is very interested in setting the project up for success. We can talk about what that means in the team environment, because they're seeing the project through design and even into parts of construction. If there's a mistake made in setting the project up for success in the contract, they are involved with interacting with the customer and helping to resolve the issue.

Whereas in a functional environment, there's more of a premium put on making the sale and passing it off and letting the other functions clean up the mess, if you will. It's not always like that, but it does happen. You can see why somebody would be more interested in setting the project up for success in a team-based environment than in a functional-- That happens regularly throughout the project, even into construction sometimes.

Liza: I'm sure these are things that our listeners run into. I've had countless conversations where it's that hand-off. Somebody's handing off an enormous amount of information to the team that's handling the next phase, and that's always a stressful process because it's a place where things can go wrong, data's lost, et cetera. Because you were organized functionally previously, what wasn't working that caused you to rethink things? Was it a really obvious trigger or did it build up over time? Did you take a step back and have a conversation about it? How did this come about?

Paul: It's a couple of things that led us to think about this. First, when I first came into the organization, when Dave first came into the organization, the bulk of the sales were being done by the founders and the company was organized functionally. We saw some of the challenges that were associated with that model. Obviously the things that you're talking about as well. We saw that there was an inconsistent customer experience across the organization. The ownership was tasked with selling different types of projects. You had some owners that were purely selling additions, you had an owner that was purely selling kitchens and baths.

One of the things that the vision for the company that Jason and Pete had when I was brought on board is they really wanted to scale and grow the company. One of the things that we had to be able to do was we had to be able to get people on board that could sell projects. We also knew that there was a disconnected customer experience just through observation when I first got on board as to the model. This is one of the first things that I did at the company level was to reorganize us into this team model. Initially we reorganized into a team model that was aligned with the existing structure.

We had a team model that was an “addition” team. We had a team model that was a kitchen, bath, and basement team. Then we had a home services team. That helped with the ability to transfer the information and have the team act more cohesively, but we still had a disconnected customer experience, and the geography that we're working in is pretty large, so we would have salespeople, project managers, designers, sometimes driving an hour between meetings, trying to cover the territory that they were going on. We would also have a customer that would buy an addition from us, and then a couple years later they would buy a basement from us, and then a couple years later they would do a home services project.

Each one of those experiences was a little different. The customers we knew from talking to them, they got attached to the team that they were working with. They really wanted to continue to work with that team. Probably many of the people that are going to be listening to this identify with this, the people that are in their home, they become very close to, they see them every single day. Those people are taking care of their pets. They're taking care of their kids. They're taking the trash out when required. They're bringing the mail in. They become part of the family.

When that person goes away, I know we've had customers tell us many times that they're going to miss this person. Then they do the next project, they were hoping that person's coming back. Obviously that person's not coming back. We reorganized really around the subsequent-- the second reorganization was around the customer. We could have picked a customer whose last name starts with the letter A through the letter G is this team and go on and break it up like that.

We decided to do it geographically because that would optimize our workflow as well so that when people are out there visiting customers, visiting homes, going between job sites, when we're active construction, people aren't driving an hour between jobs now. That was the progression of the organization. We've subsequently, since then, have tweaked that model. I'll let Dave chime in on a couple other things there. I know he wanted to say something earlier.

Dave: The cultural element comes to mind as well. I think that for Paul and I, that was definitely an inflection point way back, when you have ownership selling 80%-plus of the business and the organization set up around supporting them, it doesn't create much opportunity for the rest of the folks. The team-based model helps to draw away from that. Whether it's ownership or whether it's a top performer who's selling a vast majority of the business, they can have a cultural impact in ways that maybe are not seen to the naked eye because you want to create opportunity for folks, you want to have steps and advancement for folks.

In the team-based approach, you also want to shift so that it is a team of peers, and within the functions on the team, there's not somebody who is necessarily leading that team per se, it's more of like the general management or the management above that. The cultural element originally is what strikes me as a big gain. Then also trying to shift so that the performance within these teams are consistent. I can't remember if Paul mentioned this or not, but we have four teams that are around a $5 million remodeling business. Each team is performing to about $4 million in revenue and $5 million in sales, and they're tasked with working with their team for those production points.

We're managing behind the scenes, the lead generation, the volume, how to tweak it to make sure that it's as consistent as possible. That creates a lot of cohesiveness amongst the team and it reduces the disparity of having that 80/20 rule where in a functional environment, you have five salespeople and one of them's doing more than half of the business and you keep churning over, and it's hard for those newer salespeople or even project managers or designers to get established.

In this case, it's already pre-fabricated, if you will. Somebody is joining a team where they're responsible for the business within that geography. That's around that $4 million in revenue and $5 million in revenue. It's a better feel amongst the team members, everything out in the open. What we do to nurture and recruit that is another element as well, and it's taken a long time to get there, but circling back to just the cultural advantage and the elements and the ability to be able to promote and move people throughout the organization is a huge benefit for sure.

Liza: Interesting. Maybe we can drill a little bit more into the biggest benefits you've seen of shifting to this model. It sounds like the consistency of team performance is one of them, where you don't have one couple out performers and then a bunch of laggards, because there's a smaller number, I guess, of each role on each team. They're responsible and have to be supported. Maybe tell me a little bit more about what you've seen in different parts of the organization or on the customers as the biggest benefits we've seen from this change.

Paul: From the customer standpoint, you have consistency in the execution of the work. One of the things that pet peeves me as a customer, and I'm sure it does other people as well, is having to basically relay the same information over and over and over again to other people. It's like, I've already told you this, why do I need to tell you this again? Now I'm telling you this for the third or fourth time. Obviously that doesn't happen here 100% of the time. We don't perfectly execute and transfer information. The fact that the team is working collaboratively throughout the process, the customer's vision is always at the forefront of what they're working through.

That consistency and information transfer, the consistency and what the customer is trying to do, because everybody has a little bit of a different perspective that they can put on it, including the people that are executing the work in the field. If they really understand the customer's vision, we give them some autonomy to discuss certain things within the project that will ultimately try to implement their vision. Because as we know in remodeling now, once the project's happening, not everything is going to be laid out perfectly from the design phase.

There's going to be some nuances and certain tie-ins and certain other elements in the house, and you have to be able to navigate around those. I think that's one of the biggest benefits from the customer experience standpoint. Dave talked a lot about that cultural standpoint, which I think you can't really underestimate. If you're in an organization where there's a series of top performers and there's a series of low performers, you're going to create a little bit of a cultural divide within the organization. That's going to extend, and you're going to have issues with that downstream.

We've talked to other design build firms around the country that have this issue and they're trying to figure out how to resolve that. I think our model, I wouldn't call it plug and play, it's not quite that clean, but the ability for us to take people, new salespeople, new project managers, plug them into the system, new architects, plug them into the system and bring them up to speed fast allows us to scale and grow the org, and allows for the team, as Dave said, to be all on board with what's happening.

There's no secret behind what's happening inside of the sales team or what's happening inside of the architect team. That creates a lot of transparency and in terms of what the employees perceive to be happening in the organization, which I know is an issue that everybody suffers with. Especially around compensation and special treatment of people and those sorts of things.

Liza: It's super interesting. Oh, sorry. Go ahead.

Dave: Go ahead. You can ask for follow-up.

Liza: No, I was just going to-- a little bit of a follow-up, but it's more of a comment that it's interesting that you've created a culture where everyone can succeed. It isn't that competitive situation where someone has to outperform somebody else. The way that you've organized it, you set everybody up, I guess, in some ways for more opportunity. Everyone's got that equal opportunity to succeed. I'm interested in knowing, do folks feel-- you mentioned the autonomy to make changes happen. Do you see greater job satisfaction with that autonomy?

Dave: I was going to mention that before. The competition is created amongst the teams and amongst the company at large, but you're right, within that unit, they're relying and trusting on each other. I was going to say that the team members seem to love it. They want to pass the project off to people that they're comfortable working with and that they trust. We spent a lot of time developing the teams and their relationship with one another. You get a higher level of ownership amongst that team, just on the success of the project and the customer experience at large. That's a big advantage for sure.

I don't want to say against other firms, but we get them involved in some consequential decision-making things from a company perspective. In the recruiting process, if we're hiring a new member for a team, one of the steps in the recruiting process is for them to have a social hour with the team to meet. The person we're interviewing and recruiting can actually meet the team that they're going to be on, and vice versa. We've taken their suggestions on a number of occasions on moving forward or not moving forward with somebody based on the fit of the person in the team. That's a good feeling. If you're a teammate and you have some say over who's joining my team, that can be powerful.

Liza: It feels like it's, in some ways, a healthier competition because you feel like team competition. Competition between teams. You've got your crew with you. That's a different feeling than I'm an individual competing against these other individuals. You still have that support and feel like you've got a support network to succeed in that team competition.

Paul: Definitely.

Liza: Any other big benefits? I think one of the things you mentioned to me before was reducing some of the risk at the project level. 

Paul: Oh yes. For sure. I think I had mentioned this earlier, you might have an inexperienced salesperson who comes across a very large project that has some complexity to it, and the risk there is multi-fold. Obviously you might not win the project. You might win the project and it might be the wrong project for the customer. You might win the project for the right project for the customer, and you might have made some mistakes along the way, either in the contract or in the estimate. Those things, that was another thing that we saw. I'm glad you mentioned that because that was another thing that we saw in the functional side of things.

Dave and I got clued into this. I guess this was pretty early on, but maybe a couple years into our tenure. We had a couple of customers where it looked on the surface like the execution was perfect. Everything happened and went, but the customer was not happy. It was a shock that they weren't happy. Dave and I conducted a little customer experience project where we would go out and personally talk to these customers. We started to find a thread where the execution was perfect, but we missed the customer's vision for the project. Even nuanced little details.

If you're putting in a basement, as an example, and your plan is to play pool in the basement, you don't want to post supporting a beam in your basement where you're not going to be able to get your pool cue back. It's going to interfere with your pool cue. It's things like that that crept into us. It's like, how are we missing the vision? How is this happening? We feel like we're getting it, but it doesn't make a lot of sense.

What we were finding was that once we had locked in in the early phases of the contract through the sales process, that we really didn't have an establishment. Our processes and our structure didn't allow us to craft and create and move beyond, or dial in to what we think the customer's vision was. It's very easy to do. It's actually very easy to miss it. It's a lot easier than I think people think. A variety of things came out of that.

We introduced actually a process, changed the organization slightly at the time, and changed some of our sales processes, changed how we engage the rest of the team to reduce the risk of both missing the customer vision and the estimating correctly and getting the contract right, but also introduced some new things, some new technology into our design process, some virtual reality technology that allowed the customer to actually walk through the space and visualize the space in real time. I know we're not here to talk about that piece of technology, but that was another big part of it. That's a big risk--

Dave: You're probably going here, but the reduction in fallout is a direct--

Paul: Correct.

Dave: That's where you were going with it, is the direct reflection on the team's satisfaction and the customer's satisfaction.

Paul: Correct. Exactly.

Liza: It makes sense, adding the visualization tools as part of that process, that makes sense holistically. It's been part of the changing of the structure and processes are the things that allow you to make sure that that vision doesn't fall through the crack.

Dave: Maybe one more thing back on the team that just came to mind is you have leadership opportunities within the team, even though there isn't a team leader per se, but everybody has the opportunity to step up and to influence the success of the team. We've seen that and we've promoted from folks who have demonstrated that leadership amongst the team and has given us and the organization confidence in promoting somebody and giving that opportunity, which is--

Paul: That's actually a-- Go ahead, Dave.

Dave: I was going to say typically you're hiring managers or promoting them into something that maybe they've never done before, especially in this industry. You get a chance to see them operate within the team, lead the team in certain areas, work with the team before you do that. I think it's a benefit for both the person being promoted and the organization.

Paul: Absolutely. That's a good thing to build on because I think if people are hearing this, they might think to themselves that we don't have any high performers and we don't have any low performers. That's not true. We do have high performers, but how does the high performance manifest itself? It doesn't manifest itself into a salesperson that sells $10 million and the next best salesperson selling $1 million and manifests itself. As a salesperson, you might be excelling, or what we call project development, might be excelling in sales, maybe selling more than the average salesperson, but also providing significant leadership at the team level.

Ensuring the project, as we know, like we've talked about, how we're organized and why. That team is always thinking about that. If you're thinking about what a high performer looks like? It can come from all different areas, either project management, architecture design. We have people that are demonstrating that, if they excel at ensuring the project is optimized throughout the entire project. They excel at helping lead the team through that optimization. You get just a different level, a different type of a high performer, I guess you could say, in terms of what they're doing.

Liza: Interesting. I love this in the sense of, because we talked a little bit before about it just seems like there are greater opportunities for more people on the team. Would you say that this structure also gives you a better line of sight or visibility into people's performance and being able to identify those individuals and recognize individuals who are doing well?

Paul: Definitely. The team, they're relying on each other. Their success is very intimately connected with their teammates so that they're very vocal about challenges that are being on their team, and they're very vocal about the successes of their team. Recently, I remember just having a conversation with one of our project developers who just was raving about the project architect on his team and just saying she's amazing. She just does so much. She crushes it.

We have these challenging projects with all these special permit situations that require more paperwork and more details, and all these things. When those people are excelling, and frankly, when they're non-performing, it definitely impacts them and it's very easy for them to identify and they know that that team success is either being driven or being inhibited by that team member. Yes, I think that the line of sight into performance comes directly from the teammates themselves.

Dave: I think Paul mentioned this, but the performance also as it relates to just how the people are doing in general. We definitely feel like we hear about that sooner and can do something and can step in and help if there's stress in one particular area, but as it relates to really the well-being of the person. A lot of times you don't have insight into that in a functional environment or strictly based on performance and numbers where we spend a lot of time engaging the teams about the health and well-being of the individuals.

That comes out because the teams are naturally protective of their own. Just reiterating what Paul mentioned, we'll hear about that, which is part of the performance. Somebody who's voice isn't being heard or we're not trying to remove obstacles, or obstacles to help them get their job done are going to be less likely to enjoy what they're doing.

Liza: That team structure is basically a built-in support network for them as well.

Dave: I think so.

Liza: Interesting. Really powerful. We've probably got folks listening, thinking, this is interesting. Maybe this is a structure that's going to help me grow or scale. I'm sure there were some challenges implementing this along the way. What were some of the difficulties that you had making this transition, and what should people know?

Paul: One of the challenges with this is obviously, as people are thinking, is how do you equalize opportunities across the geographic areas, and how are you making sure that when you have either turnover or growth, how are you managing that? That's definitely a challenge. There's no doubt. There's no silver bullet here. If somebody leaves the team or we need to add a new team, or we need to rejigger the geographies because we're adding a new team, all that comes into play. There's territories and people want to make sure that they have a good territory, that they have good opportunities to excel.

All of those things have come into play over the years. There is really no silver bullet to that. One of the things that we've done right now, which we're at the scale that we're able to do, is we've got this concept of partner teams. The partner teams are able to, both when people take time off or if there's turnover within that team, provide coverage for those positions. It's not the perfect example, but it does allow for the business continuity to exist amongst those teams. The territory idea is something that I think probably exists everywhere, just probably in a different manner.

Am I getting the right opportunities? Why do all the best leads go to so-and-so? You just need to be cognizant of that and you need to have very good, what I would say, information systems that allow you to understand the opportunities inside the geographic areas and be able to manipulate those and adjust as required. Of course when you're doing that, you are obviously changing some of the things, some of the benefits that I talked about earlier with the customer consistently having that same team over and over again. Again, it's not a perfect world and you try to mitigate that as much as possible.

Try to keep the accounts that are there. Sometimes people will really fight for an account that's outside of their territory because it's a customer that they've done a lot of business with over the years, they want to maintain that. We've allowed that to happen in a couple different instances. I think you just have to take each one of those requests and process them and figure out, is this the right thing to do? Is this not the right thing to do based upon a variety of circumstances?

It does muddle the purity of the water. As I said earlier, we have this geographic area and we're trying to optimize it for production activities and sales activities, and design activities. The reality is there's projects that get sold and the person leaves, and then this person takes it. It's never pure. You have to keep that in mind. There are some instances where those things happen and there are going to be some outliers that exist in your model. You really just need to be able to account for them.

Dave: A couple things I would add are you definitely have to shift your recruiting process and focus on candidates who can appreciate and want to operate and know what it means to operate in this type of environment. As Paul mentioned before, there's a combination of things that make somebody a high performer or successful, not just the raw performance within their function. We have spent a lot of time shifting our recruiting strategy process from a variety of different things in order to vet that out. That's moving a bigger boat in the ocean around.

It takes a while to do. You also have to be comfortable with the numbers. The teams are based off of us proving out the numbers and performance over a period of time. We feel comfortable with the size and makeup of the team. I wouldn't do it the opposite way, which is to put the team together, not having the performance proved out. We spent some time proving out the performance and we've set the team goals based off of something we're very comfortable with. Those two things, I would definitely keep in mind if you were interested in exploring or testing the model out.

Liza: An interesting comment about recruiting differently or looking for someone that appreciates that environment. Are there any things that stand out in particular that you look for that are indicative of that?

Dave: First is it opens it up widely because the number of top performers in the design build world are few and far between. A lot of them have been with their firms for a long time and are 80%. They're part of the 20% who produce most of the revenue. The chances of them leaving that organization are-- there's not a great chance of it. Now you're opening up to what we feel is somebody who can reasonably perform within our process and our structure at any function.

That probably has a tendency towards team environment, some leadership capability. That opens up, that casts a wider net than just somebody being able to perform their function. A candidate that somebody else may look at strictly for performance or past results, we're opening it up and looking more broadly at their experience and what they could contribute to the organization within the team environment.

Liza: Recruiting is tough for this industry. Anything that can allow you to go broader makes a lot of sense. It's interesting, I would say one of the threads that I've heard from both of you throughout this conversation is while there was this leadership change trigger where you guys came in and had the opportunity to rethink the model, you've really been iterating, I think, since that point.

I'd love to hear just a little bit about what your approach is there. Do you make time to step back? It can sound like, again, these customer stories, or you tried the different types of project model to organize after moving and before getting to the team model. I guess, how do you start thinking about it, even these small changes with organizing territories, et cetera? How do you keep the mindset of iterating and not leaving it at a static place?

Paul: That's a great question. Primarily, it's a main topic of conversation at leadership discussions every week. That's the number one thing that we're looking at and talking through is the team, the team performance, the customer stories, the customer experience. We're very, very dialed in on what the customers are experiencing? What are they saying? What are the reviews saying? What is the performance like on the team? Do we need to adjust? Do we need to tweak? How consistently have we been able to produce the same level of results with new hires?

Dave said that before, I think the easiest one to wrap your head around is on the sales and the project development side of things. It's hard to say, oh, I'm going to give a team to-- you're going to have one salesperson on a team and that salesperson is going to ensure that that team sells $5 million. Not a lot of companies would be willing to take that risk. How we've got there is through iterations on the team model. It's very hard to do that model right out of the gate because you don't have the team model that's proven to create that ability to sell consistently at that number, regardless of where you've come from.

It is an evolution that you almost have to take. If you're looking to transform into this model, doing what we did right out of the gate probably would not have worked. If we just said we want to do what we're doing right now and we're going to implement that 10 years ago, it wouldn't have worked. It would have failed. You've got to really just keep, as a leadership team, really keep a focus and an eye on how you ensure the project efficiency? What does the customer experience look like? What are the opportunities that are being created inside of your team?

If you're looking at what we talked about, tweaking the geographies and making sure that people have opportunities, you have to do that regularly. You need to have information systems that are telling you that. It shouldn't be, I have to spend a month trying to pull this data together. This is something that we look at every single week. We have a system that tells us this is what's happening across these different teams. This is how many discovery calls this team took this week. This is how many discovery teams that last team took. This is what the company took.

This is the distribution. Here's the value of these. It's not a management by disconnect. It's not like we're just going to let these remodeling teams run their thing and do their thing and look at the end gain. We're always looking at the leading indicators. Is this successful the way we thought it was going to be successful? Are these opportunities being distributed? Are the teams performing in a way that we think they're going to perform? Do we need to make a tweak? Do we need to tweak this? Do we need to add something here? Are people at overcapacity?

That's another issue that we didn't talk about. The other issue that we'll reiterate is you have an individual project developer, sales consultant, and they'll sell a bunch of projects all at once. This team will have a heavy backlog when this team has a lighter backlog. The tendency will be like, let's redistribute that backlog so that we make sure the customer experience is high. Sometimes we've done that. I won't say that we haven't done that, but it's got to be very carefully thought through, how you're doing that.

That sort of stuff does lead to us tweaking the model. Why did this happen in this individual case? What's going on here that led this team to be in an unbalanced situation with the other team? Organizationally, the leadership is highly focused on project success. When we're seeing deviations from that project success, and we're seeing, across the organization, when we're looking at what's happening, that's when we jump in and say, is this a model thing? Is this an organizational thing? Is this a process thing? Is this a personal thing? 

Liza: It sounds like it never stops. You're just constantly looking at the numbers and the performance, and the feedback, and there's not a time to rest. Dave, any additional perspectives to add to that?

Dave: The last thing I would say that just comes to mind, high level is it's just more enjoyable to operate for us as owners. It makes us feel good that we can pass some of the ownership to the teams, creating more opportunity. Smooth out, if you will, the performance and the results. You're dealing with other issues, but you're not dealing with some of the issues you get in a functional organization, which are--

I've been there, and Paul has too, where it's just you have some days you're like, again? It's a lot about, what do you want to do, and what do you want to wake up doing every day? I think we feel not only good about this, but it's enjoyable to work in. It's not without its challenges, but it's enjoyable to work. If you feel good about coming and nurturing this model, I don't think that can be overlooked.

Liza: Nothing's perfect, but it sounds like you guys get enough positive feedback from your people, from your customers, that you're getting signals that this is a model that's working and making folks happy and fulfilled, which is great to hear.

Paul: Just the review that came in yesterday that illustrates the power of the team. There's more to it, but I'll just read the back half. It says, "Right from the start, the whole process was super informative. Everything went as planned. They went above and beyond. Finishing the project in record time. We're absolutely thrilled with the results. We can't wait to celebrate Thanksgiving and the holidays with our family and friends, and our beautiful new kitchen."

This is a kitchen addition project. They named each and every individual person on the team. "It was a pleasure working with such a professional and talented team." When the customer recognizes that it's a team and they call out every single individual person on the team from project developer, project manager, to the senior project manager, to architect, designer, design assistant, everybody on the team, you know you've made a significant impact from that standpoint They see it as a--

Liza: It's a great impression. A terrific conversation. You guys have been fantastic. I think this is really going to get people thinking about, again, I said at the beginning, hitting the reset button, maybe it's not always a complete reset. We talked about it's a bit more of a constant iteration, but being open to making change, being open to recognizing when things are working and that your initial solution may not be the one that you land on, but that you've got to keep moving and got to keep changing, is super important. Thank you so much for sharing your experience and your insights.

Dave: Thank you!

Paul: Happy too!

This series is brought to you by Houzz Pro. To learn more about our best-in-class software for winning clients, managing projects, and simplifying your workflow, visit houzz.com/pro.