Moving a couch across multiple countries to land in your living room, a couple of days after placing an order, is a challenging business. The Transportation Engineering team at Wayfair, who look after the transportation portion of our logistics, knows this all too well. This capability has given us a significant competitive advantage and, in the process of building it out, we have inevitably accumulated a considerable amount of what is often referred to as technical debt. Internally, we call this latency work because it is work we must do to reduce the future latency of our engineering efforts.
The Challenge We Faced and Our Approach
At Wayfair we are committed to reducing latency to ensure we are sustainably faster, more reliable, and scalable. We typically allocate around 20% of the capacity of every sprint to this latency work. Sometime near the end of Summer 2017, we were tracking possible latency work in a dedicated backlog. This backlog was continuously growing with small fixes, duplicated requests, and useful, yet isolated ideas that no one adequately owned. On top of this, different teams were creating platform improvement tickets for similar issues, but with different approaches. Grooming sessions and usual prioritization weren’t enough to handle the load. Coordination was needed in order to realize all of these isolated tasks as concrete projects. In this post, I’d like to talk about one of our most successful efforts in this area: the DevTech Promoter role.
Maintaining a product roadmap and associated backlogs is a complex undertaking that requires specific product management roles to be dedicated to it. We wouldn’t expect one of these product backlogs to produce valuable results with a pure crowdsourced model and no product management. So, we asked ourselves, why do we have no product management roles dedicated to our latency backlog? Smaller organizations might leave this product management work to their engineering team leads. However, for a company as large as Wayfair, this is less than optimal. Engineering leads need to have a deep-seated understanding of the business, build strong partnerships with their product counterparts, support sprint work, make technical vs. business tradeoffs, and monitor, mentor, and guide the career growth of their team. We wanted to define a role that could focus more intensely on ensuring that our latency backlog was groomed, and that the work we chose from it each sprint was valuable.
We created the DevTech Promoter role: An owner of our latency work, who’s responsible for efficiently handling the backlogs, the health of our codebase, and the overall technical satisfaction of the team. As a promoter, this role needs to make sure that our business stakeholders and other teams understand the value of this work and fundamentally share the same goal. Ultimately, it means getting buy-in from stakeholders to allocate more resources when needed and having external teams aligned in collaborative efforts that the larger organization can benefit from.
The Collateral Benefit
Creating an environment where developers with different skill sets can all valuably contribute, and have their contributions recognized, is essential if we want to elicit high performance out of teams. This is also important to support the continued development and career growth of the individuals who make up that team.
One of the most profound and common divides in developer skill sets is between the engineering manager and the individual contributor. Traditionally, the paths for growth and advancement at most technology companies are most explicit for engineers who want to grow into management, and much worse defined for those who want to grow and create increasing impact while remaining, at least in some form, individual contributors.
The Transportation Engineering team has engaged with the challenge of highlighting diverse and impactful career paths for engineers, and the DevTech Promoter role became a clear non-managerial growth path.
The scope of influence regarding this role was self-evident, both to higher management and other team members. This role was just what we needed to define a clear career step for individual contributors, and a valuable, impactful role that our business was due for.
What We Achieved with Our New Role
It’s been about ten months since we first introduced the DevTech Promoter role. Since then, we’ve managed to push forward several initiatives with a broader scope and impact than before. We have:
- Introduced PHPStan, a powerful static analysis tool that helps us to increase our overall code quality
- Consolidated object storage into a remote storage abstraction, significantly increasing the resilience of our label printing platform, which provides barcode and tracking information for boxes to be traced while they move through the supply chain
- Increased use of dependency injection in legacy code, unlocking our ability to increase code testability and interchangeability
- Improved our Business Process Monitor and its underlying event firing strategy, which enforces our system events to comply with business process expectations
- Substantially increased our test coverage
All of the above shows how we have taken control of our backlog of technical improvements and are managing the value it creates effectively. Continuous improvement has become an active and a natural part of our workflows. On top of creating this value, these improvements have created a shift in how the team purposely thinks about this work, empowering them to dive deeper and dream bigger about improvements to their own work and tooling.
Today, the backlog of our latency work is organized by platforms and epics that allow our Transportation teams to collectively focus on what matters most. Our team’s perception of technical improvement has soared, with more progress on the horizon.
And it doesn’t stop there. As the role finds its feet throughout the organization, there will be a need to coordinate initiatives across larger teams, taking the scope of influence that the DevTech Promoter has to the next level. We’re excited about what we can achieve in the future. In a follow-up post we’ll deep dive into our latency organization and handling process, so watch this space for more!