Many managers struggle with how teams need to be structured. It's a hard decision to make. There are many articles out there on this topic, but I wanted to share with you our Wix story and the progress which we have achieved over the last few years with this.
Photo by Javier Allegue Barros on Unsplash
There are many ways to structure a team. But I want to focus on those formats that have existed across a number of companies for the last several years: disciplinary teams vs streaming teams (Multi-disciplinary teams).
A disciplinary team is a team where all members share the same discipline, for example: Server engineers team, front-end engineers team, QA team…
A streaming (MTD - Multi-disciplinary) team comprises people representing all the relevant disciplines and is focused on business needs instead. Example:
B2b team - manages all premium solutions for big scale users like: resellers, partners…
Domain team - manages domain registrations and connections to sites
User impact team - focuses on user experience for all premium products, connects with support team to resolve high pains score problems
The main difference here is in the focus of a given team.
The Premium company
Wix enables our users to create the best websites with little required knowledge and effort. Each big enough section of business at Wix is split into independent companies that enable it to run fast.
The Wix Premium company works with those users who want to upgrade their site and purchase a premium Wix subscription to gain access to certain premium services, like removing ad banners and connecting a personal domain name, for example. The premium company handles all the purchase flow, checkout process, payment process, subscription lifecycle and management for all premium users.
We enable all other Wix companies to gain access to our premium users and to sell those new capabilities to our users. The premium company is mostly business-oriented and driven mostly by business needs, so structuring our team correctly is quite crucial.
Our history
Eight years ago, when I just started at Wix, we used to structure our teams around the various business focuses - we had a billing team, the premium services team, etc. Then inside those large teams we split to disciplinary teams - back then most of our developers were doing full stack, so we could run fast and it was easier to onboard new members, planning team deliverables was easier as well with one developer owning the whole product cycle. Most Wix teams have worked that way, adhering to the same structure.
When a product was ready, we would have 1-2 people who could lead the process and complete the whole path to production.
But Wix changed rapidly as it grew and so one of the early stage changes back then was to switch to a more disciplinary focus for backend engineering vs fed engineering. That resulted in us being more focused professionally, leading to more knowledge sharing on various topics and when working on solving issues, to sharing constraints and infrastructure needs, growth focus… It’s led to our structure becoming much more disciplinary-oriented with teams structured around Backend/Fed engineering.
The challenge
Collaboration, Collaboration, Collaboration.
Think about working on a new feature requiring large collaboration between all those disciplines: you need to sync all teams on requirements, make sure those teams work simultaneously on that feature, enforce cross-team collaboration and the sharing of knowledge. You need someone to become project management full time.
On the other hand you get many advantages when all your team members share the same discipline, like: knowledge sharing, same topic to discuss, a more professional approach, many team members around to ask for advice or a review, more standard code base, and don’t forget the team spirit of course. So how can you decide what’s best for you and your company?
New structure
I think what can help you in deciding on team structure is your business focus and the goals of your teams. In the premium team we need to be able to deliver fast - new capabilities, features and services both for our users and internally - so how can we achieve that when most of our efforts revolve around better collaboration? We decided to try something new and shift our internal teams to become business-focused instead:
Domain team - includes all the engineers that cover the necessary tech stack like Bed / Fed / Qa / Analyst /Product / UX. Their focus is on the domain product we sell to our users, which enables more and more features to come out and constant improvements to this domain.
User Impact team - includes people with backgrounds in Bed / Fed / Qa / Analyst / Product / UX. The focus of this team is to look for the pain points our premium users have and to resolve them with the best product and features we can develop.
B2B team - includes people working in Bed / Fed / Qa / Analyst /Product / UX. Focus - research and develop new solutions and capabilities for our b2b resellers and enterprise users, while improving existing ones.
Each team includes people from all the needed areas and can contribute to any other team’s code base. This structure enables us to run faster than before. Knowledge sharing used to be somewhat complicated at the beginning, but after a few iterations and changes in structure and processes it has become easier to ask for a review and advice in a topic you might not be familiar with / an expert in.
Advantage and disadvantage
| Multi-disciplinary | Single-disciplinary |
Developing new features | Your team can handle developing said features by itself, completely | Much collaboration is needed, mostly when features include involving people from other disciplines |
Execution time | Everyone is quickly focused on the same goals | Team focus isn’t always aligned with business goals, which can lead to delays and focus shifting |
Dev capacity utilization | Mostly well utilized | We need extra people for project management |
Team spirit | Very business oriented, KPI and needs are transparent for all team members | Team focus is mostly professional which can lead to a gap in understanding the actual business needs |
Technical growth / expertise | Team members focus on business needs rather than on the technical knowledge | Acquiring new technical knowledge is the more prevalent mindset because all team member share the same focus and knowledge |
Artifact ownership and technical maintenance | It is harder to define ownership when every team member can contribute to all micro services | Each team owns their share of the knowledge base with a clear ownership border |
MDT challenges
Like any decision you make, you are always facing advantages and disadvantages. I’ll share some of the challenges we faced when moving to an MDT structure.
Domain area expertise - we know that each one of us has special expertise in some domain, but in our new structure that domain expertise is split across many teams, and so we needed some guidelines on how to share knowledge and make it available for anyone in any team to contribute to. So we decided that each potential contributor needs to advise first with the domain expertise person and include them in the review process.
Artifact ownership - we could not make a concrete distinction between which team owned what artifact, and so we distributed artifacts based on how they were most commonly used and by which team made the most changes to each. This resulted in a more balanced artifact ownership with some artifacts are more change-intensive then others.
Small team spirit - we always want to have two people per team responsible for team building. But at some of our teams we have one person like that per team which can sometimes result in them feeling left out and lonely. We manage that by rotating such people across a number of teams and planning joint team activities.
Matrix management - some of our team members are not there full time, like UX, BI, or QA - those resources can be shared between 2-3 teams, which makes our planning harder - so we try to plan how we distribute those people in advance before each quarter.
Another issue here is that your team can now also include outside management, that’s when some of your team members are not directly managed by you. We try to address that with high collaboration across our entire Tel Aviv location and by sharing our thoughts and reviews with all team members and managers.
Code contribution - when changes need to be added to a feature by people outside of the MDT team, it can become a challenge from both the knowledge and the focus perspective. All dev team members should be able to invest more time and effort to learn, research and collaborate with many artifacts they aren’t very familiar with, and stay aligned with the team goals and the feature ETA.
There are many other challenges we face, of course, but here I just wanted to give you some quick insight into the progress we have with our continuous changes, which we keep making all the time.
Summary
The MTD team structure enables us to have a clearer view at our KPI as a team and to better align our goals with our business needs and stay better focused - even our OKR (objective key result) became easier to define. I believe that your team structure needs to reflect your business needs and focus.
What is your product? If you need to develop features and business capabilities, build your team to focus on that. Otherwise, the disciplinary team structure might be a better option for your case.
This post was written by Ittay Mizrahi
For more engineering updates and insights:
Join our Telegram channel
Visit us on GitHub
Subscribe to our YouTube channel