And my name is Najla and I'm an engineering manager at Etsy. Today. I'm gonna talk to you about leading your team through unexpected changes. So first, let me share a story of how I ended up in this particular situation.There's this really famous mantra in tech that I'm sure a lot of you have heard that we should fail fast. We should build and launch projects in batches as small and as incremental as possible. So we can learn quickly prevent code bases from getting unwieldy and ultimately to create better products for our customers. It's a great philosophy, but that's not the scenario that we had gotten ourselves into. My team at Etsy had to recover from failing really slowly. We launched a high profile product that didn't meet customer needs after doing a nine month waterfall build out and I'm not exaggerating. I'm showing you here a real post that I found with some not so kind words from some of our customers. When we looked at the feedback from the customers and looked at the data, we knew that they were right to feel this way about the product that we had built. So we worked with senior leadership and decided that we needed to rethink our approach from the ground up. We didn't know what exactly the end result would be, but we agreed to pivot the product over a three month timeline. So basically, we had to do this all over again. And not only was the timeline aggressive, but it was also very public.

The reason for that is because Etsy is a publicly traded company. And if some of you work at publicly traded companies, um you know that the news that gets out is important and the launch of our pivot were, was uh announced at our quarterly earnings call. And what that meant was we were on the hook for having a success story by the following quarter's call. I see a comment saying that's so rude. There's a better way for customers to provide feedback. I totally agree. But uh I think feedback is important no matter how we get it from our customers. So I'm happy to get it no matter what. Um But yeah, so all in all seeing how we didn't feel the great product in the beginning and we uh needed, we had a deadline to meet. It was kind of a stressful situation for my team. So after working through this entire initial roll out, my team was really demoralized that a lot of our work would be thrown out and we were just plain tired, but like I said, we had to do it all over again. And I think we all have these moments in life when what we're feeling and what lies in front of us don't feel completely aligned and this was one of them.

But at the same time, those are the moments where real leadership kicks in getting from point A to point B when there isn't a clear path. So how do we keep going and importantly, how could we prevent ourselves from making the same mistakes so that we could deliver the product in a third of the time? I'm gonna talk to you about setting yourself up for success in these types of rapid pip situations. By the way, if you've ever been in a situation like this, please drop a note in the chat because I would love to hear about it. OK. So when you're in this situation with a million things going on, the first instinct is usually to try and work as quickly as possible. But instead, my suggestion is to take the time to breathe and really reflect on what happened on my team. We went through many activities like retrospectives, post mortems and one on one discussions from all of those, there were two stand up takeaways that have really made me a better leader and helped us move forward. The first takeaway I had is to really consider your people meet them where they are in all of this. What that meant for me as a manager. Was understanding the mental state of the engineers on my team. You know, how are they feeling about everything?

Were they motivated or demotivated by the project? Did they have feedback about the team? Did they have feedback for me about the product? These are all questions that I asked and when you take the time to understand this, it can actually impact project planning. I knew that in the first launch, the engineers were working at maximum capacity. So for this new project, we already had an upper bound for how much work the team could actually complete in the next few months without making them work overtime because we had tracked that data so well. In the first launch, it was much easier to say, ok, this is our maximum engineering capacity. If we start falling behind or getting stressed out, we can't just add more people and we can't change the timeline. So let's focus our energy more on reducing scope with the stakeholders.

And uh later on when we would have these scope, changing discussions, uh it was really easy to justify because we had all of that data workload. Aside, there were other risks of burnout again. From the team's perspective, we had worked really, really hard on the first launch.

And the sudden news that we would have to start over again was quite overwhelming, even though we knew that it was the right thing to do for our customers and for our business teams need to be happy and motivated to be successful. So while it seemed counterintuitive at the time, we learned from all of the discussions that we had, that we needed to continue creating moments of professional growth for engineers, things like creating leadership opportunities, giving new technologies to learn and offering continuous support and constructive feedback.

We also learned that we needed to take the time to celebrate all of the positive outcomes in the first launch. You know, even though the product wasn't a huge success, the engineers still did a great job. So we needed to celebrate that and we also needed to give room to celebrate new wins that we'd have along the way on the positive side. It was really great to hear that our team which had been newly assembled for this project commented on how they had gained a lot more trust in each other over the last nine months, which enabled us to be really candid about all of the issues that we were having and implement changes.

OK. The second big takeaway I had is that you should create frameworks for making decisions or as I like to say, become a decision making machine, a lot of the pain points we discussed as a team were very related to how we made decisions at all levels of the project. There was a lot of miscommunication and in this next phase, not only do we need to collaborate closely with other engineering teams. But with marketing finance, legal product and design teams as well, we needed to streamline the ways in which we made decisions. So we created several mechanisms to, to make decisions that I'm going to share with you about anything from major strategies that the marketing team wanted to implement to the actual lines of code that were being written by engineers. OK. So the first thing we implemented was a daily stand up with leaders from each department including a dedicated project manager. We would discuss scoping tradeoffs, review strategies for marketing finance and product escalate risks and document any key decisions to share out later.

Since we are under such a tight timeline, we created this very fast feedback loop and built rapid trust among the different departments. Quickly, we created weekly check ins with the executive team for broader visibility. We would where we would review major decisions the teams had made, get feedback and ask for any additional support that was needed. We did demos of the progress we made which gave everyone a more realistic understanding of of how far along we actually were. Next. We created an engineering pro project lead project lead role. I'm gonna drink some water. So we created an engineering project lead role where we delegated these well scope distinct units of product work. The project lead would would review all of the requirements with the product manager.

They would understand all of the dependencies and talk to adjoining teams escalate any big architecture decisions that we had to make and created roll out and testing strategies. This is where we got to really incorporate new career growth opportunities for engineers and by empowering more people on the ground, we also reduced risk in rolling features out. Finally, we created a culture of having ad hoc engineering walkthroughs across different teams that they need to share knowledge with about about the different systems that they were working on. It, created forums for discussing trade offs and dependencies which ultimately reduce the complexity of our solutions.

And it also built in these natural moments for engineers to mentor each other and present their work to each other. Something that I realized in all of this was if we want engineers to deliver on something quickly, then engineering used to have a stronger place in the conversation.

A lot of the voices were, were involved in this discussion. And I knew that for us to hit our deliverables, I would need to amplify my own voice. In the first launch, my team received a lot of directives from way more senior leadership which we later realized could have been implemented much faster and simpler had we been there to negotiate requirements? So I'll tell you a little secret. I didn't invent these stakeholder meetings and I was not even invited to them. I wasn't even invited them to them because my um because they already included way more senior engineering leadership But when they found out about the meetings, I told my manager that I wanted an invite and basically just started showing up. There were so many people in the room for these meetings back when we had meetings in physical rooms. If any of you remember that uh that they had these like these rows in the back for extra people to sit in. And that's where I sat in the first few meetings until I realized that I could just sit at the table with everyone else. And not only were we able to reduce complexity with this more direct engineering involvement, but I also passed information along.

So the engineers on my team were instantly able to gain way more context. So moving into execution of the actual project, we stayed tactical and remained on our toes even though the team was moving really fast while doing the build out. It was crucial to continue with the regular team processes especially retrospective where we talk about what was going well and what wasn't and where we would commit to making tweaks that would help us run more smoothly. And we also acknowledge that it was OK to take some shortcuts in the code, we documented those areas so that we could reso resolve them later on as leaders. We also knew that it was important to keep telling stories throughout the build out to remind the team that the work was important. And ultimately that this pivot would provide much more value to our users. We also helped them to tell stories about themselves about how the work was really aligned with making them better engineers. So this combined with celebrating those wins along the way, helped to curb signs of burnout. I would be remiss not to mention COVID-19. So during this project, New York City, not only went into lockdown causing us to suddenly start working from home, but our city became the epicenter of the pandemic. And that's where my team was located.

This was way before we knew what the right protocols around um how to live our lives were before we knew what would happen to our family and friends. And on top of that, most of us were just not set up to work from home. So we had a lot of fear, uncertainty and worry about the future. In spite of all that though, we were ready because all of the hard work we had put into setting up the project paid off. We were already continuously checking in with each other on an emotional level. We were already overly communicative about the work and we were leveraging the escalation channels that we had already set up reminding ourselves of the greater goals we are working towards and why gave a sense of purpose in an otherwise ambiguous time. However, in the end, we successfully launched the product and provided immense value to our customers. It was really nice to see the positive feedback come in. And personally, I'm really proud of the work. And now a while since the launch, it's evident that we had other big wins.

The first is not only did no one quit, but our team received exceptionally high scores in the company's engagement survey which is a survey that asks asks questions around job satisfaction. We had spun up and onboarded a completely new team to support the initiative during this time and we were able to reward several employees for their growth with promotions. We had accrued a lot of technical debt in order to move quickly and it's been cleared out of the code base. Since then, finally, upon completion, we successfully transferred ownership of this product to another actually larger team to give it the more dedicated support that it deserves unplanned situations can arise at any moment, but they don't have to be debilitating by capitalizing on learnings, bringing engineering into the decision making process and empowering those focused on tech technical execution.

Our team was really able to persevere and even though this scenario I went through was engineering specific. I hope you have some takeaways that can be applicable to many situations. Again, I'm Najla. You can find me on linkedin or Twitter and thank you so much for listening.

Hi Najla.

You're so speedy with your presentation. We about four minutes. If there's anything I know sometimes, you know, when you're like making sure that you're on time, there's things that you kind of are like, I'm gonna skim over this just in case, you know, we don't get through everything.

Is there anything in what you were describing to us that you would want to take a minute to go in like to just add on to for us? Is there anything that kind of comes to mind knowing that you have a couple more minutes that we can chat you? and I

Yeah, sure. I think something that I noticed throughout this entire process is that when you give engineers and when you give people on the team agency, they will go above and beyond all on their own, there's no need to micromanage. You know, we created these like big leadership opportunities for people and they took it and ran. And so when we actually went to launch the product, we had very few bugs we had uh not that many snags and everybody knew what was going on all the time. So all in all, it was a very smooth launch.

Yeah, that sounds great when you're not. So when you're in this atmosphere of not micromanaging, therefore, people are kind of doing their own pieces. What checks and balances do you typically have in place? Like you just said, we had no, not no bugs at the end really. But was there someone who is responsible for kind of checking throughout or how do you typically do manage that?

Yeah, so I you know, as the engineering lead on this project, what it's my responsibility to make sure that things get into production and nothing blows up. So even though I was delegating all of these kind of smaller tasks to different people, um I had regular check ins with everybody where we would uh go over the features, do quality testing, um manual testing, and we'd make sure that our code was up to the right standard by doing automated testing.

So there were a lot of checkpoints and we use all these decision making mechanisms. We had to make sure that everybody knew what was going on at all times.

Yeah, sounds very clear. Certainly. And Nigel, you're getting tons of really great um feedback in the chat too. Just, you know, saying, thank you and how incredible I thought your presentation was. Um while I have you here still too, I'm curious about afterwards because I know you said, you know, you did surveys and your team was really engaged and you even even managed to have that lead to kind of the reward of a promotion for some of those team members. How did you kind of go about structuring that piece of it too? Because I know a lot of us, we finish big projects and we think like, well, you know, I did an amazing job there or my team did an amazing job. You obviously don't want to lose great people from your team. But you want to reward them at the same time. What's the balance there that you've found?

Yeah, I mean, it's trickier because you're asking a lot of people all of a sudden you're saying like, hey, this, this thing that didn't work that you actually built, you have to do it again, slightly better. So uh the balance there is being real with people making sure you actually give them the constructive feedback that they need to hear. Um And at the same time being really proactive about the things that they're doing. Well. So when it comes down to a time to say, OK, how do we evaluate everyone on our team who, you know, deserves a promotion at this time or doesn't? And if someone doesn't, how else can we reward them for all of this hard work? How can we evaluate them relative to the complexity of this project uh as opposed to at an absolute basis? Yeah, it's a lot of uh it's a lot of conversations and luckily at Etsy, we have a lot of checks and balances that kind of help managers and individual contributors with this path that um made it easy to uh you know, facilitate these conversations.

Yeah, wonderful. And it's funny now we've got people Nigel saying they love Etsy and they want to know what the integration was and I'm sure you didn't name it for a reason. But um yeah, you've got fans out there. So there, you go.

Well, I am, uh you know, we're always hiring, so take a look at our careers page. And uh if anybody in this uh at the conference is based in Mexico City, I'm actually moving there for a new role within Etsy and I will be hiring quite a bit. So feel free to reach out to me on linkedin.

Exciting. OK. Thank you so much for sharing Najla and have a great rest of your

conference. Thank you. Bye bye for now.