A New Era in Development Team Structure Part 1 : Why did we need to reorganize our teams?

Photo by dylan nolte on Unsplash

Insider’s product development team’s structure is being transformed nowadays. I am excited to tell you why and how. Here are the steps of the story I will be telling you about in this very first part:

Definition of Problem

  • Scaling up: More Products & More Teams
  • Stability & Consistency Concerns

Research Phase

  • LeSS & LeSS Huge
  • Other Scaled Agile Frameworks

Definition of Problem

Scaling up and having a larger number of diverse products had different organizational needs than before. Insider’s development team has been expanded by 97% between 2018–2019 and by 46% between 2019–2020. Having more than 10 teams working on 8 diverse products with a new component-based design system on the way, coordination and consistency had become a big challenge. We have not only increased the number of our products, but also designed them in an interconnected way that they should be working in unison flawlessly. We aimed to enable “orchestration” and provide better user experience in every aspect with this new design. As our hand was getting stronger with a wide range of features, a dedicated partner support team and hardworking business units; the way we develop our products should have caught up with all of those. We needed both speed and quality to be achieved by more rapid iterations delivering the maximum business value. It turned out, that there are several pillars to achieve that.

The story has started off with the declaration and overview of issues that Insider is faced with at the time on co-founders level. What are the blocks that might stand in the way of this “catching up”? What are the issues in our daily life that are brought by the COVID-19 pandemic? What would hold us back from gaining speed and increasing quality at the same time? The collection of the feedback and observations replying to those questions have paved the way for taking a shifting action. Possible solutions could be grouped under major categories like increasing the headcount of the teams, more efficient coordination and communication and increasing the overall seniority or skillset. Some of them could be solved by improved hiring processes while some of them required a mindset shift to increase ownership on individual level. For the rest, the answer to our main question “Can we address our problems with a new organizational structure?” was: Yes!

That was the part when I got involved in the research phase of the project.

Research Phase

At Insider, we’ve had been using agile frameworks Scrum and Kanban for a while already. This is why the first model that drew our attention was LeSS : Large Scale Scrum. It seemed that LeSS might have been a suitable solution for our organization having a large number of development teams. Large Scale Scrum framework is basically nothing but a “scaled scrum”, which is a set of guides and principles for multiple teams working within a common sprint framework. LeSS is recommended to organizations having 2 to 8 teams working on the same product. Whoops! What if we have several products performing very different functions apart from each other? Well, LeSS has another version called “LeSS Huge”. It comprises more than 8 teams introducing the requirement area concept. Assume you have one product and one team working on it, and after some time, you need more developers and designers as your business gets bigger. However it’s hard to manage a larger team, so you divide the team like a mitotic division of a cell: multiple identical feature teams on the same product or feature constitute a requirement area. When you have multiple requirement areas, that is the LeSS Huge structure.

I see the description of “team” in the context of LeSS very important: Cross-functional, cross-component, full-stack feature teams. What does this mean? All of your development teams should be self-sufficient and work like a newly founded start-up. They should be able to handle everything from backend development to UX design within itself, so that it can deliver done items, that are potentially shippable to the direct customer. Well, we all kind of know that in real life not all development teams formed in this “dream team” structure. Either the nature of your products, or the temporary needs of your company might need different groupings as you are on the product development journey. You might need to develop and implement a single component very quickly, so you declare an emergency state and gather a bunch of developers to form a team. Voila! Plus, there are usually supporter teams like DevOps. This ideal definition of a team, made us realize that we have solid, successful and cross functional feature teams right now so congratulations to us! However, we also had component teams or temporary teams that we can’t rearrange overnight. Such daily life facts pushed us to build a tailored structure for ourselves, balancing between the ideal and the practical.

Photo by Kelly Sikkema on Unsplash

We continued the research phase by searching and discussing different development structures as well (Agile at Scale, Nexus, Safe, Spotify Engineering Model…). To melt everything in one pot and create our own recipe, we needed to be to the point and pragmatic. So we proceeded very mathematically. First, we narrowed down our critical issues list by grouping similar ones together and voting for the Top 3 of them. Then, we asked the question: “What kind of a mechanism or a person can address and solve this specific problem?”

In the next part, I will be telling you those top problems, how we came up with a plan to solve them and introduce our focus group of great minds behind all these brainstorming. Stay tuned!

Up next in the series:

Meetings & Brainstorming

  • Forming the Focus Group
  • LeSS Adaptation to Insider
  • New Roles
  • New Sprint Structure

If you are interested in working with us, check out our career page!




Insights from the tech minds behind our technology

Recommended from Medium

Analytic Techniques for Spies (And Product Teams): Structured Brainstorming

Velocity You Can Feel

7 Questions That Lead to a Roadmap

Data Sense for Product Managers

Team Health Index

Team Z: Meet Joan Kang, Product

How we built an app to fix our own meeting fatigue

The Making of Product Managers: Michael’s Story

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Hümeyra Cengiz

Hümeyra Cengiz

More from Medium

Should DevOps be Rebranded as “Platform Engineering”?

Re-Accelerate: Measuring Performance

An old-fashioned set of market scales

Ten Experiments Every Agile Team Should Try Once in a Lifetime

Lessons From Evolving Kustomer’s Engineering Org