When your dev team outgrew itself

Software is eating the world. Sometimes I feel like the (post-)covid eCommerce boom raised the bar of the digital transformation even higher. I mean - even the last laggards finally experienced - in many cases physically - that not having an e-business can quickly turn into not having a business. At all.

eCommerce products, booking products, digital platforms are all growing evaporating the last available engineers from the HR market at a rapid pace. Folks who haven't got the digital presence finally launched it.

Folks who already have it saw tremendous growth resulting in the need of growing internal teams, investing more, or moving the engineering skills inside core structures. This is the moment they very often see that ...

... what got you here won't get you there.

I mean, I'm in the software business for almost 21 years and I used to be a CTO of Divante - 300 people software company for the last 13 years. I saw a lot of different team structures and setups including different company cultures. I can say I also saw some repeated patterns of growing and outgrowing its teams getting to its limits.

Here's an article based on my own experiences scaling the dev teams. At CatchTheTornado we're helping startups and enterprises catch their momentum and scale the business. Feel free to contact me if I could potentially help you too :)

Let the team strive for success

“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

Melvin Conway, April 1968

I’d risk saying that successful projects depend more on the proper organizational structure than any other factor. In my recent interview with Kelly Goetsch , we concluded that one of the key factors for changing eCommerce architecture is having a project sponsor with a budget and vision, and then adding the proper team structure. Only those factors combined will let you hit full speed.

We can add that successful architecture stands on three legs: a proper domain model, people, and an operating model.

The structure of the people and teams, as well as the operating model, differs from company to company, product to product, and project to project. However, I really liked the observation, which was made by Sam Newman in his ‘Monolith to microservices’ book, that the best structure is the one that gives the team full ownership. Usually, this ownership means the independent deployability of the services the teams are working on.

“Adding more people will only continue to improve how quickly you can deliver if the work itself can be partitioned into separate pieces of work with limited interactions between them.”

Sam Newman, Monolith to Microservices – after the “Mythical Man Month”

This means that, in order to achieve performance, the team has to have full competencies—developers, design, DevOps—to build and ship new features to production.?

In such a product-oriented setup there is less need to communicate with different structures company structures. Of course, the team needs to fulfill the API service contracts and interfaces. Other than that, they should be able to experiment and ship new features solely on their own.

Sounds like a piece of cake. However, it is more easily said than done.

When a company operates on a certain scale, there is no golden rule on how to structure the services, and therefore the teams. No wonder there is a lot of experimentation. Let me share just three interesting cases of dealing with this problem.

Let them own the problem

When we started the Vue Storefront Next initiative at Divante, we had a very small team of two former Vue Storefront Core developers. It was 2018, 2 years before Vue Storefront spun off (now, having nice VC funding and YC backing it :))

The dev team members - they knew each other very well. They’ve figured out the core principles of the Next architecture. They actually loved working together.

The first months of building a new product were extremely productive. They could just focus on creating the new concept, discuss it on Hangouts for 30 minutes, and then start coding right while away doing a cross-code review.

I think it’s an ideal environment for starting up. However, in our case—and probably in your case, too—the ideal conditions don’t last forever.?

This setup worked well when we were working on a single workstream, building the core platform.

However, shortly after as we reached around 50% of the initial scope, new projects aroused - including - in our case - new integrations: the commercetools and then and AboutYou Cloud. Meanwhile, a remote team from a different company simultaneously started a Shopify integration.

We were so successful! We needed to grow and build more things, of course: faster :)

Team Structure Too Good To Change

I saw this situation many times - quite recently mentoring a successful fin-tech organization we encountered pretty much the same situation.

Super effective, small team, led by the hands-on CTO who still coded large pieces of the core system by himself. Naturally, he was the go-to person for all: tech and business folks. It was fine while they've worked on a single project but with the business growing new opportunities and new products came out. It was first CRM, now it's CRM, eCommerce page, self-service, and few internal tools used by almost 1000 sales reps. All of them calling for support at times...

The team structure didn't follow the organization's growth. Any single super-hero however thoughtful and effective can lead your company to a point when he/she needs more partners, tech, and product owners leading their own small teams. It's probably a moment for the retrospection and the business decision on not only re-structuring the team, but first and foremostly: coaching, mentoring, and promoting the tech and business product owners.

The first thing was: Scrum of scrums? Maybe (below I present some case studies of how could it be structured). Product and platform teams ? Maybe.

OK, let's talk about communication and ownership first.

Democracy is overrated?

Let's get back to the production situation we had at Divante. Just with the first remote team and an unfinished core product, it started to be fun! Communication and ownership clearly became the name of the game. In our case, the unfortunate structure of the parallel teams working altogether and depending on each other caused a lot of challenges.

I think that by not spotting the problems right away, not setting clear leadership in the project we took the ownership away and discouraged the individual teams. I think we added about +150% of the efforts required for the integrations to be done. But let me tell you the story and how we solved it...

OK back in the day - with the second team, I thought it would be great if the product owners start sharing the ideas and actually making the decisions in the form of a weekly Product Forum while using the Slack channel for ongoing communication.?

Furthermore, they started doing an RFC discussion on new ideas. For example: How should we handle the checkout (among all the platforms they’ve been working on)? How do we do product filtering??

The Forum format is great for getting the teams in sync but it can easily lead to problems when it comes to making decisions and taking ownership.

It was a great idea on paper. In reality, the teams were constantly getting into deadlocks waiting for the approvals and decisions. They, therefore, struggled to take any fast steps forward.?

“It’s like a dysfunctional Enterprise simulator,” one developer said at the time.

Culture is the key to any changes

I suppose that the objection like this would be very difficult to >be officially raised< at some rigid, enterprise ;) I mean the culture of Radical Candor is a key for improving your organization and get all folks on board. Only with it the right problems can be heard and addressed.

Write down your expectations

As the discussions progressed, I was not quite sure if all the project streams were even aligned to the core principles we’d set at the very beginning. Somewhere along the way, we had misaligned on what should’ve been set out, at the core principles. For example: what can be customized within the individual lines of the framework and the user apps and what cannot? This caused even more further conflicts. The motivation was low.

While I was wondering how to solve this issue and how to remove the communication obstacles, I’ve started asking each individual team leader, including the teams of different work-streams related to the Core platform: What do you understand as the Vue Storefront Next goals? What are the key principles we need to follow? What it is and what's not?

I saw slightly different answers and this worried me a little. However, I think that, as a project leader, you must always fight against so-called ‘mind reader syndrome’ :)?

What I mean by this, is that when something is not clearly articulated, you need to be a mind reader to properly get all the expectations :-) If you’ve got more than a single team, the problem gets multiplied.

I asked the team leaders to write an essay on how they get the Vue Storefront Next idea, saying “just write down every assumption; even if you think it is obvious”. It was pretty fun and we joked that it was like a primary school exercise :) The results, however, surprised all of us.

You might be really surprised how just the process of putting things into writing changes the perspective. Shortly we realized that even as the teams saw the general principles of VSF Next actually more or less the same way, they can hardly agree on any details. The details that were stoping the actual development progress.

The first idea I then had was something like this: “Guys, if you just differ in the details, you should definitely discuss those once, write down the ground rules, and then never get back to it again” :-)?

I was half-joking, of course. The idea was to set the rules that let the teams work on their own and make the decisions independently of their own - within clear boundaries - interfaces making all the projects work together.

They did a really great job formulating the Core principles.

The key outcome of this overall discussion was decentralization. We let the individual teams work on the “Vue Storefront Next for commercetools”, “Vue Storefront Next for AboutYou Cloud”, and so on, making the decisions on their own, very close to the problem.

There was a price paid for this individuality as there were some minor discrepancies between the resulting frameworks. I can say that the speed at which the teams were able to operate and the encouragement they felt made these discrepancies made it more than worth the cost. It was like bringing the fun back to the development.

I’ll now describe another attempt to make teams self-sufficient and truly agile, based on the cases of Divante, ASOS, and About You.?

Case study: Divante team based on tribes

We grew up Divante from 1 employee to almost 300. First, we've been pretty much centralized with the software development, UX, marketing departments - all working on the client's projects. It worked smoothly probably to somewhere around 100 people. It's around the limit of people you can keep the relation with, keep the one to ones, etc. We decided to move towards the Tribes structure ceding quite a lot of ownership and decisiveness to individual teams.

[Here you can find the full case study. ]

Case study: ASOS Team Structure

ASOS made a distinction between the Enterprise domain in which they usually try to “Buy” the solution on the market and the Digital Domain, where they predominantly “Build”. Building means fulfilling the customer’s needs as the digital domain is very much product- and client-centric.

The ASOS structure is divided into Digital Domains and Platforms. They’ve got 9 Digital Domains, 19 Platforms, and 35 Dev Teams. Domains are the organizational structure for managing the Platform teams. The Platform Teams are maintaining and building the collections of aligned services, being 100% responsible for the full lifecycle of those services.

Each Platform team is led by the Product manager supported by the Platform lead and the team of Product Designers, Architects, and Business Analysts. They’re creating the product vision and designing and maintaining the backlog that is then executed (implemented) by development teams. Development teams at ASOS consist of BAs, Data Analysts, developers, and QA so they can ship the new features solely on their own. [Source: Microservices architecture at ASOS ].

If your company isn’t as big as ASOS—including 19 platforms and 35 DevOps teams!—you can still apply some of the lessons. I guess the two most important ones are:

• Have the product/business link/person within the team working on the particular microservice, as there are a lot of quick decisions to be made on a daily basis.?
• Make sure development teams include everything required for your business domain to ship new features (usually devs, BA, QA, and UX).

Case study: MOVE structure by AboutYou

AboutYou is a pretty unique company. The unicorn eCommerce originated from Germany and, interestingly, is a headless, API-first eCommerce platform. With more than 130 developers, the question of the right structural fit obviously arose. They introduced the MOVE operating model as a response to this growth.

“We believe in small and fast teams. The number of people working cooperatively on the same project at the same time should not exceed 8. This makes the communication and development process more quick and efficient.”

[Read more: Introducing MOVE ]

They resigned from having the traditional business units, rather focusing on the business/product domain. Each unit is a standalone product that is led by the technical and business leads, in order to balance the requirements. These units are representing specific domains like Checkout & Order Handling, Core Processes, and Mobile Apps. The teams work using SCRUM or Kanban to improve transparency and ensure continuous improvement of teamwork and processes.

Within the teams, there are one or more Circles with two predefined roles: Circle Manager (who’s in charge of gathering the business requirements) and the Lead developer (who is a go-to tech person within the circle). Interestingly, the circle structure and roles can be re-defined every 9 months and developers can even migrate between circles (they should, however, stay within a single circle for six months or until their individual skill-set is better for another Circle).