At Wayfair, we know that software engineering is a team sport. Broadly speaking, we organize our engineers into small working teams of anywhere between three to eight people. When you have issues getting application code running on your development machine, or questions about features that your team supports, having that small, tight-knit working group to turn to is invaluable. We also organize these teams of engineers with additional cross-functional members such as product managers, design, QA, and analytics.
Generally when we onboard new engineers, we will add them to an existing team. This brings with it many benefits, such as an already established group that they can connect and build working relationships with. Over time, an engineer may outgrow this team, just as the software features we support grow in complexity as we discover more functionality we can build. As new ideas for products and software emerge, so too does the need to refocus and shift team structures.
One of the primary responsibilities for software engineering managers at Wayfair is the success of the teams that they manage. Our managers are always on the lookout for process or structural changes our teams can make make in order to keep our engineers organized happily and efficiently.
How organizational inefficiencies creep in
At our current rapid pace of growth, one of the ways in which teams can slowly become inefficient is by growing to a size that is unwieldy to coordinate. A lot of small inefficiencies can manifest when this starts to happen. This can be seen throughout the structure of our two week sprint cycles.
Using the sprint framework, we plan the work that a team will complete every two weeks at an all-team planning meeting. Once you start trying to plan work for eight or more engineers, all at once, those meetings easily become long and hard. This is due to the quantity of work you are trying to plan, and also because there will be work you are planning for some that will be unrelated to the work of others. Not everyone needs to know every explicit detail.
Additionally, we try to keep a balance of at least one product manager per team (sometimes more depending on product complexity) and there are practical limits to how much work a single product manager can coordinate on their own. What we’ve observed is that preparing and planning work for more than six engineers starts to become very difficult for a single product manager. If you need more than one product manager to plan, it also makes sense to assign each product manager ownership over specific features in order to become subject matter experts.
There has also been plenty of
research done on the limits of forming human connections. At the end of the day, there are only so many people one can keep up with and get to know closely. We try to target, ideally, 3-8 direct reports for our engineering managers, and those numbers tend to roughly correlate when targeting team size as well. Another factor that contributes to this rough goal for size is the fact that a
healthy team dynamic involves everyone on the team having a chance to speak and be heard by everyone else. Again, that starts to constrain team size once a team begins to grow beyond eight members.
Wayfair’s edge
So, all of this is a helpful background to answer the following question: At what point do we look at reorganizing our engineering teams into smaller sub-teams? As human beings we are naturally somewhat change averse. When we are thinking about drawing different lines of organizational ownership, this can feel like losing a certain number of team members. We all know that the folks on our team will be those that we get to work closely with. Even if we know that it’ll be better for everyone to break into sub-teams, it can be hard to go against these social and personal pressures. It is important to understand these competing interests and feelings when planning and enacting organizational change.
This is the point at which I believe Wayfair has a natural advantage. One of our core values is a manager-doer ethos. This means we want our managers to be willing, and even eager, to jump in and do the hands-on work required with teams that they manage. With this being the case, we promote for and hire engineering managers with highly technical backgrounds. How does this relate to team change, you might ask? Well, this is the point at which that practical hands-on understanding gives our engineering managers the context and empathy to understand the technical, as well as non-technical lines that we can draw to define our internal teams.
The new ‘Favorites’ Team post restructure, with Pikachu too!
Another reason we believe that managers are in an ideal position to draw team lines is that they have a vested interest in helping our engineers stay happy and engaged. Software engineering work is knowledge work, and as such, intrinsic motivation is critical to an efficient team. People naturally care about who they work with, as well as what they are working on. This means that an engineering manager working closely with their teams will have the appropriate context to reorganize when the time comes.
Enacting team change
Alright you might say, now we’ve understood the why and the who, but let’s get down to business. How does Wayfair Engineering enact team changes, and what techniques could you use to enact them smoothly yourself?
As with most things involving some number of people and leadership, the task is going to involve a good deal of talking. In order to help a team transition go smoothly, it is important to have a leader speaking to all members of a team one-to-one. They should be on hand to both hear everyone’s thoughts, and to take the time to explain the reasons behind why a team is changing. The last thing you want is for team members to feel like a change only serves a cold business purpose without also having genuine benefits and upsides for them professionally.
A specific strategy we have employed with success at Wayfair is to ask everyone to explicitly share their preference for the team they’d want to join, and in particular, to write it down. Additionally, it is also helpful to ask which other teammates they’d prefer to work with. It is not always possible to give everyone their preference, but it is critical to at least ask in order to keep their buy-in high for a restructure. You will almost certainly be surprised by the preference, or lack of preference, from at least one person.
We partner our engineering tech-leads and managers with product managers for the same teams. Once you know everyone’s preferences, you can use that to draw up some potential team lists and discuss with other leaders before making a final decision. This helps to ensure that whoever is making the final call isn’t doing so in a vacuum. Throughout the process it is important to communicate with everyone when the final decision will be made, and once you do make it, communicate it publicly through multiple communication channels (verbal, email, Slack, etc).
The current (new) lineup of the Room Planner team.
Switching to work on a different team can be a fairly big change for any software engineer, and we believe it is important to put a commensurate level of effort and care into when we organize these changes. In the same way that we don’t want performance review discussions to be a surprise, we also do not want to surprise teams with a sudden reorganization that leaves little to no warning or lead-time.
In any fast growing, dynamic organization, change is going to be a constant factor. We believe it is important to keep that change personal yet professional, and to make the best effort that we can to ensure our organizational changes serve to benefit those that it affects. As part of our most recent team changes, a spot has opened up for a Full Stack 3D Manager to help us continue being thoughtful and purposeful as we scale. Let us know if our leadership values resonate with you!
