Who do you work with? Who do you report to? Who do you collaborate with? The answers are obvious in both extremely small companies (answer: everyone) and very large companies (answer: there’s a pretty clear structure that was set up before you joined). As a leader at a growing company, you’ll need to help answer these questions for your team and your company at least once, and probably multiple times. What should the answers be?
I want to take some time to talk about one of the best things I experienced in my work at Rent the Runway: the evolution of our product engineering organization. When I joined, the engineering team was divided into roughly two groups: storefront, which did all development for the customer-facing website, and warehouse, which supported the software that ran the warehouse operations. We quickly evolved storefront to be frontend and backend because we were rewriting the code from a PHP monolith to a Java- and Ruby-based microservices architecture.
Toward the end of my first year, we ran an experiment. We had a new product we wanted to build for the customer, a feature based on our customer photo reviews. Because finding a dress that would fit well was a challenge for our customers, we wanted to enable shoppers to see photos that other customers had uploaded showing themselves in the dresses, along with customer-provided information about their normal size, height, weight, and “shape” (athletic, pear, curvy, etc.). To implement this feature, we created a cross-functional team. We had engineers who specialized in the frontend user experience development, and engineers who worked on the backend services. We had a product manager, designers, a data analyst, and even a representative from the customer service team. This cross-functional team worked as a group to design and deliver this feature to our customers.
This project was a massive success. We delivered a good feature, fairly quickly, and the contributors all felt that they understood the goals of the project and were able to work better because of this cross-functional team. Prior to this project we had been deep in a pattern of “us versus them,” where your particular business function was “us” (tech, product, analytics, marketing, etc.), and the rest of the organization was “them.” Creating these collaboration units gave people a chance to see the whole group as “us.” It was a clear win in terms of organizational health, so we evolved our whole organization to have all product engineering performed by cross-functional teams like this. Call them what you want — “pods” or “squads” or “pillars” — but cross-functional product development groups are a popular structure for a good reason. By putting everyone who is needed to make a project successful together in one group, you help the members of those teams focus on the project at hand, and you make the communication for the whole group much more effective.
Conway’s Law is often cited in discussions of this kind of structure. It states: “Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.”
When we put cross-functional teams together, we are acknowledging that the most important communication — the communication that we need to favor above all else — is that which leads to effective product development and iteration. Note that this structure will not necessarily produce the most effective technology! In fact, it will probably produce systems that have some inefficiencies compared to companies that have a more engineering-centered team structure. So, should you adopt this structure, you have to decide where you’re willing to take some system design hits in order to most effectively create products.