Taking on a new role can be an experience that is at once career-definingly thrilling, and a bit nerve-wracking. The inevitable questions of one’s own ability start to creep into mind — “I feel like I only just hit my stride in my last role! Why am I changing everything now?” or “What makes you qualified to be a [your fancy new role here]? You’ve never done that before!” With time, those doubts typically disperse as you remember the reason you pursued your new role in the first place: you’re passionate about the work (and, as it eventually turns out, you’re not half bad at it).
My experience transitioning from my prior role as a senior engineering manager to a new role as an architect was no different. I’ve now reached a point where I’m well past the six month mark as an architect, and it’s also been about six months since I fully transitioned to individual contribution, transferring management of my last few direct reports. With that in mind, this is a particularly opportune time to share some of my reflections on what being an architect at Wayfair means in practice.
I joined Wayfair in 2016 a month after receiving my undergrad degree. I joined the Search Engine Optimization (SEO) team’s engineering wing, and couldn’t have been luckier; not only did I get the chance to work with a team of incredibly talented people, but (as I quickly discovered) SEO is a fascinating domain, and I became deeply interested in it.
The next several years saw a ton of growth for Wayfair and for the SEO team, which afforded me plenty of opportunities: from building new features and platforms, to serving as a scrum master and tech lead, to eventually managing ten engineers across three scrums. The SEO team grew from a scrappy group of a few engineers and marketing analysts to a group of 60+, including a newly minted product team, analytics specialists, and more. After nearly two years as a manager, I decided that it was too early in my career to set aside more hands-on technical involvement as much as the management role had required up to that point, and realized it was time to make a change.
As I prepared to transition to my new role as an architect, I spoke to a few people in and outside of Wayfair who were in similar roles, or had made similar transitions from management to individual contribution. I received some sound advice: “You’re going to be rustier than you think, give yourself time to ramp back up,” “Keep in constant contact with the team, make sure your work is relevant to them,” and, helpfully, once the WFH shift started, “Find a way to whiteboard from home ASAP.”
As I got into the role, all of this advice proved useful. I knew one thing I desperately wanted to avoid was becoming Mr. Programmer, doing all sorts of Special Esoteric Work in relative isolation — stepping on the team’s toes and creating more problems than I’m solving. Especially coming on the heels of a global pandemic and a re-org that saw my team welcome several talented new engineers, keeping tight feedback loops with the team and finding ways to effectively document and communicate about ideas, proposals, and design decisions was more crucial than ever.
After taking a step back from my old responsibilities and having a chance to hit the reset button, I quickly realized I’d need to figure out how to influence the team without directly managing them. In fact, even without writing all that much code, since writing everything oneself is not the most effective way to scale output. Understanding that I’d be out of luck trying to persuade anyone around here of any particular course of action without some numbers (and rightfully so!), as my first order of business I set out to gather some baseline metrics describing our technical footprint.
I helped the team build this visibility through newly-available-to-Wayfair tooling like DataDog APM and SonarQube in order to better understand the performance and quality of our features & systems. Having established this new layer of observability, and having socialized the resulting data with the team, we became aware of a few immediate opportunities around performance and testing that we were able to act on.
The first was that we had very little test coverage to speak of. As a result, we embarked on a journey as a team to build a culture of quality, with the goal of making testing part of the bread and butter of our development cycles. My part in this involved educating the team about various development methodologies which include testing as a first class citizen: test driven development, behavior driven development, etc. I provided the team with some unit and API test suites as references, a means of measuring progress (test coverage metrics via SonarQube), and made sure to highlight progress and examples of exceptionally well-written tests.
There was a similar story around performance. With the introduction of instrumentation via DataDog, we discovered a good amount of opportunity in the performance of our various customer-facing features. The team set out to make various improvements highlighted by this new instrumentation. I provided the team with a dashboard highlighting these opportunities, created a few monitors to ensure our hard work didn’t regress, and publicized some best practices around what/how to monitor and alert on the performance of our features.
In turn, both of these immediate steps around testing and performance highlighted more deeply rooted opportunities in terms of our architecture and design. Wayfair’s storefront is a monolithic application. This architecture has a particular set of consequences by design which were beneficial for us in some contexts, and worked against us in others. As we dug into the most challenging testing and performance problems we uncovered, it became evident that adopting a different strategy would be beneficial for the team.
It was easy for the team to continue to build things into this monolith by inertia rather than by intentional design. However, there was already a broader organization-wide initiative underway to adopt event-driven microservices, as there was broad recognition that this architecture would better suit the needs of the business (our team being no exception); so I set out with the team to pump the breaks on building more things into the monolith, and provide some alternatives.
First, we identified a project being undertaken by one of the SEO sprint teams as an opportunity to apply such an alternative design. We chose to design it such that it could be deployed independently of the monolith. Then, in order to properly equip that team, I produced a prototype providing them a framework to work within. This was a crucial step, since in order to build this service we adopted a programming language and application framework (Spring Boot) that was brand new to the team. This prototype was then handed off to the team for further iteration. Having a prototype in place provided a solid foundation which accelerated the team’s ability to get things done and ramp up gradually, without them having to learn everything about Spring Boot at once. This service also provided a reference for the other SEO sprint teams as they thought about how to design services in their own business domains. Finally, I provided a decision flowchart advising how to independently reason about what goes in the monolith, without my acting as a gatekeeper.
Having helped the team stop the flow of unnecessary things into the monolith, we then had the luxury of starting to think ahead in terms of what set of services would best model our business domain. Having identified a couple short-term opportunities to build things according to our new strategy for the next six months or so, we then set out to work with our product team to model our business domain and its various workflows from the top down. We focused on modeling this in a way that would easily lend itself to an automatable event-driven structure, which would form our long-term vision.
What the Role Looks Like Now
Having discussed what starting the role looked like, it’s probably time to answer the question at hand: after having gotten situated into the role, what does an architect actually do? The answer, as it turns out, is one we’re quite familiar with as engineers: it depends. Specifically, it’s a function of what your team is up to and what its needs are. No two days look exactly alike. Rather than drily walking through the “day in the life” format we’ve all read a million times (“First I grab a big cup of coffee. Then I look at my dashboards, and then at 10:00 I check in with the team…”) I’ll instead describe what I view as some of the main categories my work has fit into thus far. It’s essentially shaped up as a few broad streams of work that reflect the sorts of work I described above.
Planning for the Future
This is where a lot of interaction with your cross-functional partners comes into play. Ultimately this takes many forms. This includes identifying newly required business capabilities and translating them into a technical solution. Or vice versa: identifying new, emergent business capabilities made available by the design of some existing system.
This also isn’t an activity to be undertaken alone. Effective planning requires collaboration with the team during its usual cross-functional roadmapping process, as well as providing lanes for the team to surface their own ideas (I provided a lightweight RFC framework for this purpose), and of course bringing your own ideas to the table. However, these ideas must be informed by the needs of the team in order to be effective. The most important needs aren’t always immediately apparent, cleanly stated, or recognizable in the context of a single agile team. In light of that, keeping close to the day-to-day work of the various agile teams by attending stand ups and sprint ceremonies, as well keeping 1:1s with engineering leads and stakeholders in product & marketing, are all ways to stay well-informed about their needs.
Things like establishing visibility into code quality with static analysis tools like SonarQube, building observability with distributed tracing instrumentation like APM, stronger test suites, and quality checkpoints during the development process (design and code review) would fall into this category.
It’s important to note that the bulk of the work here is around building a culture of quality, rather than “doing” quality yourself. For example, identifying tools, equipping the team with the knowledge of how to use them, providing a solid set of baseline measurements (e.g. a dashboard), and providing some example solutions — rather than exhausting your time trying to solve a million and one problems yourself without bringing the team along with you.
Preventing backslide on quality can also, to a certain extent, be automated through tools like SonarQube, which can block changes that do not meet the standards of a quality gate which takes into account things like user-defined code smells and minimum test coverage. Creating these tools for the team, and handing them off for appropriate turning, is another strategy to decentralize effective decision making.
De-Risking New Technology/Projects
Sometimes the team will embark on a project (perhaps at your suggestion) using some unfamiliar technology or tool because it’s been identified as the right solution for the job. Rather than sending them down this path completely unequipped, something I’ve found useful as an as-necessary line of work is providing a solid foundation in the form of a prototype which can be handed off to the team for further iteration. Ideally, in addition to providing the foundation of the system, the prototype also contains a good amount of reference code which the team can use as an example as they continue to build.
Education is another big part of de-risking new technology. Prototypes are also a good tool for this purpose, but we’ve also taken advantage of other tools like hands-on workshops, tech talks, and documentation.
Improving the Software Development Process
This takes several forms: providing active support by unblocking the team on ongoing projects, providing new tools to the team, evangelizing best practices, and helping the team shift continually left on important design decisions to reduce churn.
For SEO, this has translated to numerous changes. To name a few: implementing a design review process prior to implementation, defining or publicizing best practices around the team’s use of various technologies/tools, running trainings and hands-on workshops, sampling code reviews, etc. This bucket also captures the work I’ve done with the team around incorporating automated testing into their development cycles.
With regard to code reviews specifically, it’s important to emphasize sampling. It’s easy to fall into the trap of trying to get eyes on every single code change, acting as a gatekeeper and ultimately getting in the way of progress — not to mention robbing other engineers of the chance to build some reviewing skills themselves! I’ve found it to be effective enough to sample a small share of code reviews, which can give me a good enough idea of whether there are any recurring themes that should be revisited in broad strokes with the team.
Bringing It All Together
So, what did I learn about being an architect at Wayfair? Unsurprisingly, it boils down to the same things as any other role. It’s about making a business impact and getting things done. In this role in particular, it’s about doing that under a couple of constraints. Namely, you’re typically not managing people; yet you have to figure out how to make an impact that scales across multiple agile teams. This necessarily means you have to do (more or less) what people tend to think an architect does. Broadly, “big picture stuff.” Exactly what that looks like evolves over time and depends heavily on the team’s needs, but I’ve found that the important thing is to create sufficient space to detach from the day-to-day and think about problems that are broader in scope and that transcend the work of any given sprint in order to pave the road ahead for the team. It also means staying sufficiently informed about the day-to-day work of the team to make sure they’re still on the same road you’re helping to pave.
Importantly, I’ve found that the role is also about managing change, and stewarding the process of change for the team. It’s not enough to identify big problems, propose solutions, and then check back in with the team six months later to see how they did. I’m responsible for making sure the team is equipped with the confidence to successfully realize a technical vision. This means educating, facilitating debate, and providing tools. Finally, since the role is about change, it’s also crucial to be open to new ideas and to change driven by others. In fact, it requires a good deal of proactivity in identifying and incorporating those things. Change can’t happen in a bubble. It requires the input of the people in the domain next door, the people building your team’s systems, managing its processes, and determining the overall direction of its business.
I’m looking forward to helping the team continue to own and improve many of the focus areas mentioned previously. I’m also looking forward to the next challenge in my journey as an architect, which will be more exploratory work with the continued goal of providing the team with sophisticated tools to help realize an even more ambitious technical vision for a (more) perfect SEO machine. Only time will tell what will come after that as priorities and needs change, but I’m excited to find out!
Interested in joining the Wayfair Engineering team? Explore our open roles here: https://www.wayfair.com/careers