When it comes to mobile platforms, Wayfair has multiple end user focused apps across iOS and Android, with over 100 engineers working on them. As the recently appointed lead of the App Team here at Wayfair, I chose to ask fairly generic yet consistent questions upon my arrival to get the lay of the land. These questions included:

  • What are your team’s challenges?
  • What are the opportunities?
  • What should my focus be?
  • What is there to like at Wayfair?
  • What could be better for you?
  • Who do you rely on most?
  • Are there any missing amenities?
  • Are there any missing tools?
  • Is there any problem with the current tech stack?

Once here, I went about my fact-finding mission for about a month. On my very first day on the job though, I got a very consistent vibe about what was going on in App Land. As a result, I started listing my focus areas on Day 1 and got to work.

What Challenges Were We Facing?

App development is inherently hard at scale. On one side, app developers have to create new features that are usable, which in turn helps the business. On the flip side, app developers need to keep the apps “appy”: fast, consistent, fluid, and fun; exactly what users expect from a native app. However, this requires an investment in performance that can be at odds with pure feature work. Balancing both is fine when the App Team is small, but as the team and codebase scales, keeping focus on these two things equally, in a connected way as both efforts evolve together, is actually very hard. This is especially true when the App Team is as big as it is at Wayfair.

The App Team wasn’t always this big. The native apps on Android were only created a couple of years ago, after all. Wayfair has been growing fast, with the App Team growing way faster; ultimately, the organization structure that was so successful a couple of years ago no longer made sense. The App Team was actually two teams, split between iOS and Android. QA, engineering leadership, and even product management were split by platform. There was a growing imbalance between the number of iOS developers and Android developers (3:1), with iOS developers focused on specific business needs and trying to work with counterparts in each business area. In contrast, Android work was fully centralized. Moreover, native apps were also being created in other parts of the organization with minimal support. Pain points spread across different areas such as coordination, platform support, ability to scale, and product strategy.

Coordination and Ownership

There was ambiguous accountability for tech leaders within this group, with up to four engineering managers needed to get alignment on cross-platform projects. Each of these groups also employed different agile ceremonies. The same ambiguity in accountability existed in product management as well. App development was not really top of mind; at best, it was an afterthought. A fast-follow model from Web to App was adopted due to the scarcity of app engineers, fueled by a drive for feature parity, which means features were developed first on Web then duplicated on App almost as-is. This caused issues in terms of reworking, the inability to catch-up, and apps eventually looking like mobile websites.

Platform Support and Scaling

Full-stack developers were not approaching work in a true client-server architecture, focusing on developing APIs only useful for the website and not thinking about app capabilities and constraints. The user experience ended up being inconsistent, slow, and too much like mobile web, especially on iOS.

Having a centralized reporting structure also doesn’t scale well. As the app organization grew, it had become more and more difficult for Associate Directors to do their jobs effectively. This was only getting worse as we kept on hiring. The career growth of existing Senior App Managers was limited by the number of leaders needed.

Product

The team responsible for giving end users a great shopping experience for their home had no clear vision of app development from a product perspective, with just a quarterly prioritized roadmap for App. App Product Managers were more so project managers – leaving product responsibility to Product Managers across teams. Alas, these Product Managers and Designers were not designing for App at the outset, but instead adapting web designs.

Our Approach

Any organization that designs software will inevitably produce a design whose structure is a copy of the organization’s communication structure (as inspired by Conway’s Law).

Not all of the challenges presented above can be fixed with a magic change; far from it. Some were also rooted in the culture of the organization. But many of the concerns were seeded by a lack of ownership of native app in each team. iOS engineers were already “distributed,” sitting with the rest of each feature team, yet these iOS engineers did not interact with the rest of the App Team. The Android team was a pure service organization. There was no real incentive for teams across this part of the Engineering organization to work with native app; none from the organizational model and even less from the concept of feature parity. Moreover, we did not know what we wanted these native apps to “be” in the first place.

We first decided to come up with a vision and a strategy for the app using a tool called the One Pager. The One Pager helps distill a vision and strategy in a succinct fashion, asking simple questions about why the team exists, what it would take to achieve the team’s mission, and how the team plans to deliver on their goals.

Once we had a vision for the app, we came up with an organization strategy to support that vision. We had a few guiding principles:

  1. Each team at Wayfair should own customer problems and solutions across platforms: delivering features on App as much as they own delivering features on the website
  2. Under any reporting model, we need to maintain centralized platform teams with clear areas of ownership
  3. We had to change the feature delivery model from feature parity to job parity. Job parity means that rather than trying to simply copy every feature over from desktop or mobile web, we should understand what “jobs” customers “hire” our product to do and ensure that we’re providing them with a delightful way to solve that job in the mobile app
  4. Anyone should be able to work on any part of the codebase if they have the skills or will
  5. It’s impossible to have everyone know everything, so we need some technical specialization
  6. We need to support App development across Wayfair, not just in certain parts of the Engineering organization

This generated four related, major questions:

  1. We want to reduce duplication of work in App, but how should the iOS and Android hierarchies merge?
  2. We want all engineers to work together on solving customer and business problems, but how should App and other engineering hierarchies merge?
  3. Supporting the app as a platform is important, but how should we organize this support?
  4. How should we enable native apps across Wayfair?

To answer these questions, we proposed a multi-step organization change from decentralizing at the Superpod level (Step 1) down to the Pod level (Step 3). A Pod is the equivalent of a team focused on a business area (a single Scrum team, typically), while a Superpod is a collection of related Pods.

This can be summarized in a few bullets:

  • No centralized reporting from App Engineers in a Superpod into the App Director
  • No separate management hierarchy for iOS and Android
  • Explicit expectation for App Dev Platform to help with apps across Wayfair
  • Distinction between end-to-end experience and App Feature Differentiator teams
  • Introduction of Auxiliary Engineering and Reverse Auxiliary (study abroad)

The creation of a Core App Superpod is critical here and enables us to collaborate closely with all teams interested in App across the organization, while keeping a strong focus on the app as a platform. With the need for supporting app development across Wayfair, Core App has the mandate to help every team in the organization.

  • Step 2: No centralized reporting from App Engineers to App Managers in a Superpod. App Team Leads report to Engineering Managers in a Pod
  • Step 3: App Engineers report directly to Engineering Managers in a Pod, as Full-Stack Engineers do

Steps 2 and 3 can be implemented on a Superpod-per-Superpod basis. However, these steps have broader implications on the organization, as roles that are currently held by one person would need to be split across different people: Scrum Master, architect, people manager, and technical coach. These would have ripple effects not only on team structure, but also for performance management.

Our Implementation

We decided to implement Step 1 in early January. This meant first identifying exactly what the new org structure would look like in each Superpod and in Core App, and prepping all stakeholders for the change. A lot of communication went into it (and still is), but I want to call out a few important things:

  • We closely monitored the app reorganization before, during, and after the change with a monthly self-assessment survey for leads, some specific follow-up surveys, and quarterly employee surveys. For areas where we saw problems, we then had in-person discussions with a trusted facilitator to obtain actionable insights
  • As the reorganization unfolded, we understood that roles and expectations of key stakeholders would change, and we created a document describing these new expectations with some best practices across all impacted functions. We then met with each function’s leadership to go through these expectations and get buy-in
  • We seriously thought about how App stakeholders, including engineers, could collaborate and network closely – even as the organization is distributed. The App Cohesion Initiative is 25-projects long, which keeps cohesion strong
  • We recognized the need to adjust some of our processes, such as code reviews and technical design reviews, because of this decentralization
  • We learned a lot along the way and changed how to proceed as we went along. A good example is how we better defined how to distribute Android engineers to teams thanks to learning from our distribution pilots

The Benefits

We are already seeing the benefits of our app organization changes:

  • Now that Superpod engineering managers have ownership of App, they care much more about it, and are trying to set it up for success by becoming app advocates themselves
  • Thanks to the challenge of managing iOS and Android engineers, and a broader path for promotion by reporting to the Superpod, App Managers have embraced their new role, stand up more for App, and work even harder to accomplish their mission
  • The app self-assessment survey saw a jump in responses since January as soon the new organization was implemented in App Engineering, with greater satisfaction overall, especially in the ability to collaborate
  • Core App is already able to collaborate closely with other teams and get them to dramatically improve app screen performance, app stability, all while re-thinking how our apps should look like as a whole
  • Core App has also been helping to develop apps across Wayfair, promoting moduralization and module re-use across apps, with low-level modules like logging and tracking to start
  • App leaders have better and more focused ownership of their areas

What We Achieved

In a few months, we achieved a re-thinking of how App should be organized and part of Wayfair, but we are far from done. It will take time to implement all of the positive initiatives that can now be accomplished with this new organization as its foundation. These initiatives will help support the business, our overall user experience, and the work needed in recognizing app as a platform.

Stay tuned for more from our newly-organized App Team as we help the Wayfair App shine. This will continue to be an exciting 2019!