REA Group creates 'Colab' as a central store of reusable tools

Digital property powerhouse REA Group has started using an internal brand called 'Colab' to encourage the creation of generic, reusable tools and platforms that solve common technology problems experienced by product development squads.

Chief engineer Tomas Varsavsky told the recent Yow! CTO summit in Melbourne that Colab was “a little bit like the Heart Foundation tick” - given to tools and platforms internally that met certain criteria, such as being reusable and supported on an ongoing basis.

Featuring brands like realestate.com.au, about 650 of REA’s 1700 Australian staff are technology workers, but unlike many other tech shops they sit in the lines of business where they can work closely on solving external-facing customer problems.

“That's really challenging from a technology point of view, because we have a very distributed organisation,” Varsavsky said.

“At a squad level, we have a lot of autonomy, so teams can make decisions around their technology.

“When you lift the hood into what's happening in these squads, there are a lot of common concerns that these squads have to solve for.”

Learning to grow

When REA was much smaller, Varsavsky noted that these kind of common concerns “are not really top of mind. Your primary job as a startup is to find product market fit,” he said.

However, as REA grew and multiple autonomous squads formed, their individual technology choices started to become a management problem.

“When you have autonomy in squads, sometimes they choose the same things but sometimes they choose divergent things, and over time those diverging things start to hurt because quite often that divergence is not really adding value to your business,” Varsavsky said.

“When you start getting really big, it's a really big problem, because now you've got different factions between teams, you've got different attitudes to solution a, b or c for a problem, and - if left unmanaged - it can be a serious drain on productivity.”

Varsavsky’s challenge was to find ways to “extract commonality” and achieve economies of scale for REA, without sacrificing autonomy which was seen as a core trait of the internal culture.

The drive to common components was in part motivated by what Varsavsky saw happening within REA.

“Like all other companies, we were making lots of investments in our platform,” he said.

“I'm of the belief that as you make investments in your platform, your platform grows in breadth and scale, and over time you should actually be speeding up because the waterline of the platform rises, a lot of the common problems are solved, and so the job of a product team gets easier because they have more capability to lean on and therefore should be getting faster in getting products to market.

“Instead, we felt like, over time, we were actually grinding to a slower cadence.

“This came up in different forums, by different people and different stakeholders. Even engineers were getting to the point of feeling they were reinventing wheels that didn’t need to be reinvented.”

Searching for reuse

REA had created some tools that had gone on to be reused by other teams and squads, with good results.

“There's a product called Shipper, which is an internal Dockerisation tool,” Varsavsky said.

“Over time, there are hundreds of code bases and systems that have adopted this tool.

“This is very compelling because I can show this to my CFO and I can say every time a team has used this tool was a time when it didn't have to do some work, so we save some money.

“And I can show that over time, we can advance this tool and make changes and keep everybody in lockstep so there's a lower cost of maintenance overall.”

Tooling up

The key question for Varsavsky was: why weren’t there more tools like it?

The answer was multi-faceted.

First, it was a by-product of the company’s structure of having product development teams focused on solving problems for external customers.

Even teams that found a common problem to solve, and had the best intentions of solving it, did not always follow through.

“The insight for us is that it's actually really, really hard for a team whose primary focus is to build something for an external customer to, at the same time, deliver a ‘platform’ outcome,” Varsavsky said.

“Teams start with the right intent, so they'll start a project or product, and they'll see a common need, and say they’ll build it as a byproduct of their primary mission.

“Even though the intent is there, it never pans out that way, because when push comes to shove, the project or priorities change, or the scope increases, the secondary act - the ‘platform’ outcome - gets deprioritised.”

Second, Varsavsky found the issue of reuse had been tried before but hadn’t worked, leading to resistance in some areas to his own efforts.

“There were some ghosts of the past, where we had made efforts to get to a ‘platform’ outcome and somehow they hadn't really delivered,” he said.

“But a lot of those had failed where we tried to predict a future need.

“The conversation went a little bit like this: we see a market trend or a need that's going to show up in the next six to 12 months, put a team together to build that ahead of demand, so by the time we actually have the need we'll be ahead of the curve because we would have built it already.

“The truth is that doesn't really work because by the time you spend 6-9-12 months to assemble a team and build the platform, the original need for that thing has moved on, the team that originally needed it has found a different way to do it, the thing you predicted would be a need has probably changed over time, and you actually don't know enough about the problem to really predict what the outcome should be.

“So the result was we built it, but nobody came. So we had examples where that was the case, and we never got the ‘platform’ outcome as a result.”

Shifting the thinking

Varsavsky examined REA’s successful reusable platforms and tools like Shipper, and saw some common themes.

“First, it solved a real problem that we had at scale, so a problem that lots of teams had right now that we could do a better job on,” he said.

“Secondly, we had a strong visionary - somebody that really understood the problem, had a vision for what the solution would be, was passionate to get it done, and was driving that conversation through the organisation.

“Thirdly, we had a committed ongoing investment, so a team whose job it was, who had time and capacity not as their secondary job but as a primary job, to maintain the platform. These people spent their time building great user support, great documentation, and even creating training.”

That led Varsavsky to a shift in thinking about reuse that would ultimately see it become widely adopted within REA.

“The a-ha moment for us is when you stand back from all this, this is actually product management,” he said.

“These are all attributes that make our external product successful.

“When you apply product thinking to your internal platform, it unlocks a whole new way of thinking about the product.

“This is the approach we're taking. We're really thinking about our internal platform as a product in the same way that we think about our external products.”

Taking that concept further, Varsavsky knew the initiative needed a brand.

“Products really have a strong brand. When you have a product, you have a brand that very easily represents what that brand stands for and what it means,” he said.

“What we wanted to do is create an internal brand for our internal platform. We came up with this brand called Colab.

“It's a made-up word, but we made this word mean what we wanted it to mean - to have the right conversation in the organisation and drive that culture change - and then we put it everywhere.”

Within Colab are a number of different tools and platforms that meet the criteria - immediately beneficial, generic and well-supported.

The tools and platforms are easily recognisable as being part of Colab since they carry a kind of “Heart Foundation tick” of approval.

Teams and squads are not forced to use Colab tools; they still have the autonomy to make their own technology choices.

However, Varsavsky said he hoped that they would take advantage of the tools, since they were an easy and readily-available option.

The result of Colab for REA is now an organisational model consisting of “a bunch of teams whose job it is to serve the market and build things for your external customers, and then a bunch of teams that are platform teams that are building for your internal customers.”

“One of the questions I get a lot is: what's the right ratio of investment in either one of these things? I think the answer depends, and it depends a lot on your context,” he said.

“For organisations like us, with the scale we're at, I'm finding that between 20-35 percent [on platform teams]  is kind of the range where organisations are landing.

“That's about where we're at in terms of our investment as well.”

Authentication in Colab

About a year ago, Varsavsky said there was a team that wanted to build a new set of applications for customers.

“They did their inception and requirements analysis and figured out that they need to do authentication so that users could log in to use their product,” he said.

“So they said, ‘Well, surely we're not the first people to hit a need for authentication. So there must be something out there that already does this for us’.

“They surveyed the organisation, and I'm ashamed to say we had 35 different ways to authenticate people”.

Varsavsky said the team had a number of choices at that point.

There's 35 ways that we're doing this. None of these ways are great - when you've got 35 ways to authenticate people, you can imagine that none of those are best practice,” he said.

“So the choices were: they could either adopt one of those 35 ways and it would come with limitations; they could invent a 36th way and that'll compound the problem; or they could try and deliver a platform outcome as part of their project.”

However, developing an authentication system was well beyond the team’s primary reason for existence.

“None of those choices were really a great choice for that team, so they put their hand up and said, ‘We think this is something that should be solved globally for all of REA as part of the Colab brand’.”

The idea was considered by an internal Colab panel which examines the viability of opportunities. It passed, and was allocated additional funding.

“We appointed a product manager, gave them a team to execute it and said, ‘Go for it. Your job is to solve this problem not as part of another job’,” Varsavsky said.

The result is a reusable authentication product called Lock.

“In just six months, we've got four different applications already running in production that are using this thing, and we've got another nine or so planned for the next quarter, including our core website with most of our users, realestate.com.au,” Varsavsky said.

“We delivered a massive cost saving, so every time this thing gets adopted, there's a team that's not having to solve this problem from first principles.

“We also have massive security advantages as well. Having a common security approach delivers a better security outcome, and then we can evolve that independently and improve security in lockstep, which is really important.

“It's also got a huge uplift for our consumer and customer teams as well because now we have a place where we can encapsulate best practices around onboarding users, pulling people into our platform for the first time.

“And we have the ability to see users and their behavior and the data across multiple brands, which, again, has got a business benefit.

“It’s an amazing result.”