SWIMM UPSTREAM

This may come as a surprise, but Compass’ engineering organization has over 1000 developers powering their end-to-end tech platform that supports real estate transactions across the United States. Basia Mucha, Director of Engineering at Compass, joins the show to share her experience scaling a platform across different geographies and the art of balancing new features while also growing your team.

What is SWIMM UPSTREAM?

The Swimm Upstream Podcast is a collection of conversations about knowledge sharing, code documentation, change management, scaling dev teams and more. Our guests come from all over the tech world, with some really interesting insights, stories, and… coffee hacks. Join Tom Ahi Dror, Co-Founder of Swimm (a Continuous Documentation platform that streamlines onboarding and knowledge sharing within software engineering teams), as he talks with some of the most inspiring engineering and dev team leaders in the industry.

Tom 0:00
They say that change is the only constant in life. On this season of Swimm Upstream, we're breaking down specific instances of change in software organizations when both technical and human aspects were involved.

Basia Mucha is a director of engineering at Compass, a US-based real estate brokerage meets tech stack. Fun fact about Compass there are over 1000 engineers building their platform. Welcome, Basia.

Let’s dive in.

Let’s start with some warm-up questions. What have you been listening to on Spotify?

Basia 0:45
So due to COVID, mostly I work from home, and I have a toddler at home. So I feel like every morning, it's either "Wheels on the Bus" or "Run Baby Run." I'm sure many people could refer to this when they have toddlers. So I don't have as many songs like I used to. So it's all toddler songs now.

Tom 0:28
Yeah, what about the "Baby Shark" song?

Basia 0:28
There is definitely Baby Shark too.

Tom 1:20
So tell us a bit about where you are and when the story that we're going to focus on happened.

Basia 1:25
Okay, so I've started at Compass as a senior manager in the data platform organization. Now, I am the Director of Engineering in transaction management. So I kind of moved teams from big kind of many datas of listings into the transaction world of Compass. Compass is a leading technology-enabled residential real estate broker, providing an end-to-end platform for the agents to deliver exceptional services to sellers and buyers. So I grew further and further in Compass throughout the years.

Tom 2:01
So I know a lot of people in the US at least know Compass, but not necessarily as a software company. Like do you know how many software developers there are in Compass at the moment?

Basia 2:14
Yeah, so there are over 1000 software developers at Compass, all are in different parts all over the US a lot in the East Coast and the West Coast. We also have three India offices, and we have contractors all over the country from Argentina, China, Ukraine, and India.

Tom 2:35
Okay. That sounds big. Hopefully, your employees in Ukraine are okay.

Tom 2:41
So you saw the R&D organization grow times 10 and in a pretty short timeframe. Isn't that crazy?

Basia 2:52
It is crazy. I think I joined when there was the Series E or like we had so many series, and then we went IPO about a year ago.

Tom 3:05
A lot of this happened during COVID. Did it feel like there were more and more names in the Slack channel? Or was it also that you were meeting all these new people all the time?

Basia 3:17
At the beginning, I joined right before COVID, so you would meet a lot of new people. For example, we opened our Seattle office and we had people fly in from Seattle to meet us. And then all of a sudden, everything changed. At that time it was only engineers in New York and mostly in Seattle. When we went remote because of COVID you know, Compass didn't know what to expect from the market. It definitely was a positive thing for Compass during COVID but we weren't expecting, you know, the markets changing as you know, people are outbidding each other. About six months into COVID, we started hiring significantly. And at the beginning we were asking do we hire remote? Do we not? How do you interview? And it just started growing significantly during COVID times.

Tom 4:16
We covered the personal angle, what was the situation from a Compass angle?

Basia 4:23
So Compass has created kind of like a best in class platform for agents, including search marketing CRM, that also achieved significant market share. We were just ranked number one in the US real estate market with 251 billion in sales volumes in 2021. So we had to extend the platform end to end. And this is where transaction management has evolved. Basically, in the past, certain transactions were paid out manually by operational. So it made sense to build this end-to-end platform for time to pay for reporting and to reduce operational costs. In addition, Compass acquired Glide, which is a transaction management platform for external agents or other clients.

Tom 5:13
It sounds like you're adding new capabilities, but also maybe adding something that has a different type of character to the company, right? And also to the R&D organization?

Basia 5:27
Yes. So as I'm not sure if many people know about real estate, but many things in real estate happen manually, or using many third-party tools. For example, offers it's all paperwork, then, you know, compliance is all the brokers have to have scanned documents for, like auditing purposes. And then there's also like commission to pay the agent. Not many brokerages have created an end-to-end platform for that. And that makes it easier for agents to do their job and be kind of like an entrepreneur because they could see everything in one system versus logging into multiple systems of like, what our offers will be a separate system. In order to get paid, I have to log into a separate system etc.

Tom 6:08
It sounds like you're offering something great. So is there a challenge from a technical standpoint, from a business standpoint?

Basia 6:15
Definitely, there are many challenges. Every region has different legal aspects, or different requirements and features. For example, in California, the agents get paid at table on the East Coast more or uncentered. They could get paid, you know, one to two days later or even further, depending on when they submit their payments. Some regions have legalities of there has to be an order in between or a broker that approves it. Some regions don't. So the platform is not just like Instagram, or Facebook, where you give it to the users and expand the market, you have to build each region differently. And as Compass expands, you have to figure out research in that region. Are there any legal differences and continue expanding this platform?

Tom 7:02
So I guess with smaller companies, they might, like startups just starting off. They might have the luxury of being able to focus only on one geography and maybe life is simpler. It sounds like you were growing very fast. I guess expectations were high. So the rate in which you had to absorb these new geographies probably was very high. Right?

Basia 7:26
Yes. And we are still in the process of releasing this end-to-end transaction management to all regions. We're 50% there and hope to be 100%, somewhere in Q3 of this year.

Tom 7:38
So does this mean that the product needs to behave differently in different geographies? Or is it just something different in the database only?

Basia 7:47
So, both. It is different sometimes in the database because there's different aspects, like I talked about. There's an order, so you might have to have an order or flag or there's a broker approver. And there's different features. One example is in certain features for compliance purposes. Let's say there's a listing agreement. In the first regions, we went out, it's one listing agreement. In other regions, there's amendments and there's like a multitrack upload, how do you build those features? And usually, when we build a feature, we try to release it to all regions, if it makes sense. Or we only enable it for those regions, if it's specifically legal aspects, and they'll just make the other regions more complicated versus better.

Tom 8:29
This sounds like something that's even hard to grasp, for like one person understanding the entirety of the complexity of that. So I mean, how do you go about doing something like that? How do you teach an organization how to move forward that way?

Basia 8:45
Yeah. So how we did that is we collaborated with one region to start about a year and a half ago, which was Florida. We gathered all their requirements from Florida. Built that MVP, released what we call early access of 200 agents in Florida, got the feedback iterated, and then released all of Florida. Then we go to the next region as engineers are building Florida, product and research goes to the next regions starting today - demoing what you have in the region previously, gather more requirements on that, and build that and continue on and on and on. And of course, as the platform is there, there's always going to be agents that want to have new features or ideas. So product and engineering have to work very closely on what region do we release next? Or do we build out features that agents or staff want for all of the regions that we released?

Tom 9:43
Okay, so you're doing this one by one. That's very convenient. It gives you the focus you need each time. But is that good enough in terms of speed?

Basia 9:52
Well, definitely, not always. Right. There's aspects of you know, really sync and also growing the team. Originally, about a year and a half ago, we started out being a very small team, learning about Florida. And then we hired and kind of divided the teams into multiple sub-flow teams. So, therefore, we could move much faster from region to region. So you can have groups of people working not just on one region.You could have three or four regions getting built out at the same time by different engineers.

Tom 10:24
Do different engineers focus on different geographies at that point?

Basia 10:30
So we divided the teams based on the flow of originally entering the data, then doing the compliance and commission. And in those teams, different team members might work on different regions. But the team members should understand what the other regions' features are for on-call process, or in case there are issues you can't rely on one engineer or two engineers knowing one region. Because you don't want to have you know, one person being the one point of failure in the way. So we do have the knowledge to transfer a lot of that data to many engineers and teams.

Tom 11:13
Basically, it sounds like you're creating different versions of the same product. Now, let's say you're in the fifth version. And now someone in the product comes up with his great idea that could be implemented for the last four. It seems like anytime you add another version, it becomes harder and harder to add new features. Because you need to go back and start remembering, okay, what happened there? And does that even work there? And what do we need to do and so on? Is that true?

Basia 11:44
Yes, that is true. So as we are building features, of course, with any company startup, you're going to have a lot of refactoring or backfilling the data where necessary. So in the beginning, I think we moved very, very fast, and we're still moving fast. But sometimes you do have to slow down and understand why did we do things a certain way in the past? How we're going to do it, what makes sense, how we're going to restructure either the database or micro-services, and are we going to split them? And then, you know, enable that feature behind what we call feature flags. We try to implement our code where everything works the way it is. We enable it for a couple of users, then see if it's six, and then start migrating the rest of the deals or users onto the new feature.

Tom 12:33
It sounds like there's a lot of knowledge about reasons like this we did because of that. And because we did that we changed this. So where does all that live? And how do you make sure that you have it on hand when you need it?

Basia 12:51
So one, of course, product, and research has to be very strong. And documentation has to be more or less up to date. Every company I've worked on, always documentation is never up to date. We try to keep our documentation as close as possible. And a lot of it I think is in our heads, to be very honest. So people that have been here longer tried to give that knowledge to others. And as we promote certain engineers to lead, the longer you're here, the more knowledge you have. And you know, we all have like open slack groups in case there's a question that somebody doesn't remember. Anybody from multiple teams could answer that and give reasons of like, why was it done this way? And then we go through that process. Okay, what should we do now? So we do have weekly meetings, and discussions of certain regions and certain features to make sure we're all aligned.

Tom 13:47
Okay, so now, I'm assuming that you're adding more geographies and so on. And maybe you think back - how you started, and you think, wow, we really should have done this differently, or this would have been faster and so on. Are there is there anything like substantial that you would change, go back and change?

Basia 14:05
So Compass has been around for quite a while, but I don't think they put that much engineering resources into that transaction management. And if I could go back, you know, let's say it was in Compass, you know, five years ago, versus three years ago, this started about two years ago building, I would say, Let's build as much early. We were, we had a lot less regions, we were out in. It would have been easier and learn from it. We started this process where we have been already very successful as a brokerage, but had to do a lot of manual stuff. So, you know, I think these things have been brought up by leadership, had ideas of other things for Compass. There were many products in Compass; they didn't concentrate on transaction management. So if we did it earlier, we might have been already much more successful at this point.

Tom 14:53
Okay. Yeah, so building the knowledge and infrastructure in advance. Now, if someone is in a different company, that's already mature, and now creating this new business line, this new offering from scratch - do you have like any important pointers for someone in that situation? What they should look out for how they should prepare?

Basia 15:17
Yes, I think I kind of pointed out, you know, this region or legal nuances in the real estate is very hard. It's a hurry, you gather all of the requirements. Compass, I think that very good job from product and research, where they did a thing called "Learn from reality" - another principle they have where they went out into the world and understand in different companies, what do agents have, what are agents feedback, and try to gather all those requirements. You know, there's some requirements that we missed, there's requirements that we misunderstood, maybe better communication, with product and engineering, and like iterating on that. Like, the longer time you have an iteration, the easier it is, if you're trying to like, move very fast. If you're gonna, there's gonna be mistakes that happened and then we have to, like, rebuild it.

Tom 16:06
So invest a lot in proper research, and also move gradually.

Basia 16:15
Yeah, and invest in your people too, right? If you kind of what I went through, you know, engineer starting as a startup, you know, you can't keep engineers at the same level. How to invest in the people: some people want to be tech lead, and some people want to be managers. So the longer people are in the company, I think, the more knowledge they have, and they could drive a certain way. But you also want new people to come in and give you new ideas. Because if you work too long, you're kind of like in your own box. And maybe you don't think outside the box. So it's like a nice balance of new people and people that have the knowledge to figure out the next steps.

Tom 16:55
How do you imagine this looking like, what do you imagine this looking like, at Compass like a few years from now? Now, it's all constantly changing. You haven't added all the geographies yet. What is it going to look like a few years from now?

Basia 17:09
Yes, I see this kind of like in two parts. By the end of this year, you're going to have 100 billions of dollars going through this transaction management platform. And agents are gonna be delighted and driving adoption and other parts of the Compass platform integrating with them. Down the line is how do we make this platform external for usage outside of Compass and for clients? I think that's kind of a North Star. But when will we get there and will not encompass agents actually be okay using this platform because you know, there's different brokerages do they come on board to Compass and maybe we get more agents, or does this become external where other brokerage companies can use it to?

Tom 18:01
Cool. So it sounds like there are already things to research now.

Basia 25:12
And there's also like many things. There's so many features, there's so many ideas that people have. I could see almost like a two-three year plan for this platform.

Tom 18:11
Amazing. So, unfortunately, that's all the time we have today. So thank you so much for coming on.

Basia 18:16
No problem. Thank you so much.

Tom 18:28
For the last episode of the season, we brought in our very own Swimm band. The Sultans of Swimm, who you can hear playing in the background. Head to our Instagram page for some photos from the recording session.

Thanks, everyone for tuning in, That's all the time we have for today. To read episode transcripts, check out our past season, suggest an episode or join our growing community of developers. Head to swimm.io that Swimm with two M's dot IO.