Scaling Work for Fast Flow: a Team Topologies story

Authors Note

This story is based on an amalgam of real cases, obfuscated to protect the innocent.

Project COVID

“Demand for products online is going through the roof, we need to scale up our e-commerce development”, exclaimed Dan, Director of Product Development at Smooth Retail Group, as he addressed his audience over video chat.

“I have secured a doubling of investment into our online development activities. My team, augmented by management consultants from GRB, are preparing a list of product features that will position us to deliver massive improvements in sales and profit through our online business.”

“All I need from you”, he pointed at Julie, the head of IT, “is that you ramp up the development capability to deliver all these features.”

“Through our work with GRB the product roadmap will be prioritised and refined so that all the most valuable features are on the top of the backlog. Every feature will have metrics to justify it, expected sales, revenue, conversion rates, profit. That’s the advantage of having the consultants from GRB on board, we can create a detailed and realistic online retail model with their expertise.”

Julie smiled broadly. It was nice to get this injection of funds to support her engineering team, who were severely stretched maitaining and trying to upgrade a creaking old e-commerce website that had been built 10 years ago before mobile was really a thing and had links to antiquated payment gateways that needed modernisation.

She looked at her team of engineering managers, their faces keenly listening to Dan on the video chat, and wondered how they would go with scaling up their teams. Most them had come up through the engineering team ranks so they knew the technology inside-out. Julie wondered how she would manage the increased expectation from Dan. Having your budget doubled was great but it came with an expectation of double the output. She briefly wished this meeting had been face-to-face so she could ready the body language a bit better.

Scaling the Team

Julie organised a meeting with Joe and Sunita to discuss plans for scaling the online team. Joe ran the Australian-based team, mostly veterans of the 10-year old e-commerce platform, while Sunita was running the Bangalore-based team, who were mostly learning the old system. The Bangalore operation had been setup to reduce the exhorbitant costs of hiring contractors in Australia but it was still new so hard to judge its success.

Julie opened the discussion. “We need to double the team in a very short time frame, we have 2 months. So hiring permanents from the market is out, we need to get teams of contractors on board.”

Joe smiled, “I know that a few of our old staff are on the contract market, and some of them went to one of the big SI firms. I can see how we could get some of them back on board. They’d be excited to know that Smooth Retail is investing in online. Most of them left because of their frustration with a lack of investment.”

They drew up a list of options. Sunita proposed a ramping up of the team in Bangalore. Julie and Joe agreed that was possible but only with a small number of new people as the cost to train up the new people in Bangalore weighed heavily on the Australian team productivity.

In the end they came up with a plan. They had 4 existing teams (2 in Australia, 2 in Bangalore) and they would hire 2 more in Australia and 2 more in Bangalore as a sort of like-for-like replication. Each of the new teams would have the same mix of skills as the existing team, they would have team level mentoring where the original team would mentor the replica team, and they might even work off the same backlog with web features being sent to one of two web teams, and mobile features sent to one of the two mobile teams.

The worry was the 2 new Bangalore teams, trying to replicate the existing Bangalore teams was risky as the existing teams were still new. But if they tried to hire in Australia it would be too expensive and they could not overload the Australian teams to mentor both new teams in Australia and Bangalore, work needed to get done.

Over the next month Julie, Joe and Sunita went out to market, sourced an SI partner that had hired some of their old engineers, so they could guarantee pre-existing knowledge of Smooth Retail’s e-commerce software, and they onboarded 4 new teams. The only thing that changed was the SI partner convinced them to put in mixed onshore-offshore teams. This made sense to Julie as it maximised the learning across the teams. She did worry a bit about how they would communicate and work across time zones but that was the SI partner’s challenge to manage.

4 Months Later

“This is not acceptable”, thundered Dan as he had one of his rare face-to face meetings with Julie and her team of engineering managers. “You are taking some of the best engineers off the online project to work on resolving some CDN issue. We are already progressing too slowly with Project COVID and I need your focus on delivering the backlog of features we need to expand online sales.”

The meeting ended badly. Dan and his product managers had delivered a long list of features. Sunita had extrapolated some early estimates to indicate there was 2 years worth of work. Julie pointed out that a 2 year backlog was not realistic, so much could change in that time (including the end of COVID perhaps). Dan was furious that some of Joe’s most experienced developers were working to resolve a CDN issue that did not deliver any new features.

As Julie, Joe and Sunita did their meeting recap there was a quizzical, faraway look from Joe. He didn’t seem quite connected to the meeting. Eventually Julie asked him what was up.

“I had a meeting with Claire recently that got me thinking”, Joe admitted. “She started talking about Conways Law, how we tend to develop software that matches our communication structure. Like, if 3 teams are building a compiler they will tend to build a 3-pass compiler.”

“Claire also talked to me about cognitive load in the development teams”, Joe went on.

Julie and Sunita lent in, interested to hear more. Claire was one of their best front-end developers, who also had managed to learn quite a bit about the back-end of the e-commerce package and was well regarded for getting things done on the website. Things that others tended to say were impossible or would take too much work.

“So Claire said that the way we are working now is overloading the development teams”, he continued. “Currently we have 2 teams working on the checkout, which is one of our most complex pieces of code.”

“How did that happen?”, interrupted Julie.

“Well its because we gave the new loyalty program, which impacts the checkout, to the Blue Badgers team since it is mostly mobile focussed. At the same time the Yellow Yabbies web team were doing some improvements to the overall website purchasing process that also impacts checkout. Of course the checkout is both mobile and web so when the Yellow Yabbies got delayed by the CDN issue both teams end up touching the same code at the same time. We couldn’t avoid it” admitted Joe.

“Hmm, that doesn’t seem good”, contemplated Julie.

“Yes”, continued Joe. “Claire is suggesting that we would be better off re-forming the new teams around functional areas of the system, not simply copying the existing web-mobile divide which is all mixed up since our mobile app re-directs to the website when you go into the product details page.”

“We need a team structure that better reflects what we are trying to develop”, Joe stated.

Sunita was looking very agitated, almost jumping out of her virtual chair with excitement. Julie turned to her and asked, “What’s up?”

“I’ve read about this”, exclaimed Sunita. “It’s called Team Topologies. This is exciting, we can form our engineering organisation to enable fast flow between teams.”

“What do you mean?” asked Julie.

Sunita was enthusiastic and seemed to know what she was talking about. She explained the team types of Team Topologies. How stream-aligned teams were the normal way that teams worked, how complicated sub-system teams would handle something like the combined mobile-web checkout and its various payment gateways, how a platform team might help with some of the foundation developer experience stuff that they wanted to do but never managed to fit in because of the 2-year backlog, what the difference between a platform team and an enabling team was.

Julie and Joe listened patiently and at the end Joe opened his mouth to say, “it sounds like you know what you are talking about Sunita, would you like to work with Claire on putting something together than could re-structure our teams better?”

Sunita nodded but Julie looked angry, “why did you never say anything about this before?”

Sunita looked sad, “we’ve been too busy on-boarding the new teams, and my teams are also new so we have a lot to learn. It seemed like the priority was to get immediate features started, thinking about improvement was not really on the menu.”

There was silence, everyone looked away not quite sure what to say.

Team Topologies in Action

Two months later and the engineering team at Smooth Retail were gathered for a team update. These were video meetings where each of the engineering leads would normally get a team member to demo something of significance. This time was different, Dan the Director of Product Management had requested a speaking slot.

After an update on recent website and mobile stats from Julie, she introduced Dan and he opened up with a big smile.

“I’m really pleased with progress of the new team structures and I am discussing with our CEO and Logistics, Warehousing teams whether there is something for us to learn from you folks in Engineering.Yes, we are thinking of applying Team Topologies and the principles of fast flow across the business”, he started.

“Let me recap what I have learnt over the past 2 months.”

“I think the first thing was the value of cross-organisation collaboration to help set the foundations for fast flow. As you know I had hired GRB Consulting for their retail expertise to help build an online feature set that would make Smooth Retail a leader in our industry. Thanks to Sunita I learnt that having a big backlog of product features but no alignment to the teams that deliver the work is like putting a Ferrari on a crowded freeway at rush hour — the Ferrari goes at the same speed as every other car in the traffic jam.”

“And it was Sunita and Claire that helped implement the first phase of Team Topologies, where we ran an event storming session to clearly identify all our business domains across the online business and worked out where the seams where so we could create stream-aligned teams to those domains.”

“As Joe pointed out, some of those domains get pretty complex. For example the checkout, which is where we created a complicated sub-system team purely to handle the changes to the checkout process. I thought that was going to prove to be a bottleneck but having a focussed team, with good domain knowledge, handling requests in priority order actually delivered more checkout features faster. So I’m really happy.”

“It was then Julie that helped organise the previous CDN work that was slowing us down into part of an enabling team that was looking into new technologies. Funnily enough when it was given to a dedicated team that was looking for web acceleration and caching technologies everything seemed to move faster. It was like a CDN for our software.”

Dan stepped back, smiling broadly, obviously pleased with his joke. When all he got was blank stares from the video audience he stopped laughing and carried on.

“However the big innovation that Julie introduced was the to-be team interaction modes. Julie noticed how most teams only collaborated when they needed. She researched the different interaction modes in Team Topologies and helped educate us all to work better together. Including our leadership team at Smooth Retail.”

Julie felt she had to clarify what Dan was saying for the audience. So she added, “For example the infrastructure team has focussed on developing scripts and software that enables our release process and testing harnesses to be run as-a-service by any of the other teams, reducing friction that previously existed. Sometimes the web product display team facilitates work for the mobile search team when they need to get product details, this is an example of the facilitation style of Team Topologies.”

“While we feel we are getting better at organising teams for fast flow we still have lots to learn”, Julie started to wrap up the meeting. “And with Dan’s support we will be learning with the logistics, warehousing and product management team — collaboration all the way up and down the organisation.”

Everyone clapped (virtually) and released balloon emojis. It certainly felt better working with Team Topologies.