Leading your engineering team through an unexpected product pivot

How to recover really quickly from failing really slowly.

In tech, we talk a lot about failing fast: implementing small, incremental changes so we can learn quickly, prevent codebases from getting unwieldy, and ultimately, create better products for our customers.

I want to share how my team at Etsy recovered from failing really slowly. We launched a high-profile product that didn’t meet customer needs after doing a nine-month waterfall buildout, and senior leadership decided that we needed to rethink our approach from the ground up. We didn’t know exactly what the end result would be, but we agreed to pivot the product over a three-month timeline.

Not only was the timeline aggressive, but it was also very public. The launch of this pivot was announced at our quarterly earnings call, which meant that we were on the hook for having a success story at the following quarter’s call.

After this initial rollout, my team was demoralized that a lot of our work would be thrown out, and we were just plain tired. How did we keep going? And importantly, how could we prevent ourselves from making the same mistakes so that we could deliver the new product in a third of the time? I want to share how we set ourselves up for success in this rapid pivot.

Reflection

The first step was for us to take a breather and reflect on what happened, which we did through a series of retrospectives, postmortems, and one-on-one discussions. From those, there were two standout takeaways that have since made me a better leader.

Meet your people where they are

As a line manager, I needed to understand where the engineers on the team were, mentally. We had worked really hard on the first launch, and the news that we would have to start over again felt daunting, even though we knew it was the right thing to do for our customers and the business.

Knowing that the team had worked at maximum capacity already gave a good benchmark for how much work we could actually complete in the next few months. Because we had tracked that data so well in the first launch, it was easy to use our engineering capacity as a hard constraint, allowing us to focus more on reducing scope with stakeholders.

Workload aside, there were other risks of burnout. While it seemed counterintuitive at the time, our management team knew that we needed to continue creating moments of growth and learning for our engineers and to take the time to celebrate the wins of that first launch.

On the positive side, our team – which had been newly assembled only nine months prior – noted that they had gained a lot more trust in each other, which enabled us to be really candid about these issues.

Become a decision-making machine

A lot of the pain points we discussed were ultimately related to how we made decisions at all levels of the project. Since this endeavor required close collaboration with many engineering teams – in addition to marketing, finance, legal, product, and design – we needed to streamline the decision points. From major strategies that these teams wanted to implement, to the actual lines of code that were being written by engineers, we created several mechanisms to catch ourselves and talk through the tough stuff.

Bring engineering to the forefront

A lot of voices were involved in these discussions, and I knew that to hit our deliverables, I would need to amplify my own. In the first launch, my team received a lot of directives from senior engineering and product leadership, which we later realized could have been implemented much faster and simpler had we been there to negotiate requirements. If we want engineers to deliver on something quickly, then engineering needs to have a stronger voice in the conversation.

I’ll admit, I didn’t cleverly craft these executive check-ins or daily stakeholder standups. I wasn’t even invited to them, since they had already included my manager, a VP of Engineering. When I found out about them, I told my manager that I would join and basically just started showing up. There were so many people in the room for those meetings that we had overflow rows, which I politely sat in, until I realized that I could just sit at the table (a cliché, I know). Not only were we able to reduce complexity with more direct engineering involvement, but the engineers on my team were able to gain more context from summaries of these daily meetings as well.

Execution

Moving into execution, we remained vigilant. Even though the team was moving fast while doing the buildout, it was imperative to continue with our regular team processes, especially retros, and to commit to making tweaks that would help us run more smoothly. Similarly, we acknowledged that it was okay to take some shortcuts in the code, and we took time to document those areas to resolve later on.

As leaders, we realized that it was also important to keep storytelling throughout the buildout to remind the team that the work was important, and that ultimately, this pivot would provide much more value to our users. This, combined with celebrating small wins along the way, helped to curb signs of burnout.

Enter COVID-19

During the project, New York City not only went into lockdown, causing us to suddenly start working from home, but the city became the epicenter of the pandemic. Plainly said, we had a lot of fear and uncertainty.

In spite of all that, we were ready. All of the hard work we had put into setting up the project paid off; we were already continuously checking in with each other emotionally, being overly communicative about the work, and leveraging the escalation channels that we had set up. Reminding individuals of the greater goals we were trying to achieve and why gave a sense of purpose in an otherwise ambiguous time.

Results

In the end, we successfully launched the product and provided immense value to our customers. Now, a year since the launch, it’s evident that we had other noteworthy wins.

• No one quit, and our team received high scores in the company’s annual engagement survey.
• We had spun up and onboarded a completely new team to support the initiative during that time, and were able to reward several employees for their growth with promotions.
• We are slowly but surely clearing out the tech debt that was accrued over both launches.
• Upon completion, we successfully transferred ownership of the product to another team to give it the support that it deserves.

Unplanned situations can arise at any moment, but they don’t have to be debilitating. By capitalizing on our learnings, bringing engineering into the decision-making process, and empowering those focused on technical execution, our team was proudly able to persevere.