video • 10MIN

Engineering Screw Ups: How (not) to reorg

Hear Equinix's Senior Director of Engineering Shweta Saraf share her experience learning the hard lessons of engineering leadership, as she tells the INTERACT audience the story of a "screw up" she's made before while trying to reorg!



Conor Bronsdon:
Welcome back to INTERACT, everybody. I am joined now by Shweta Saraf.
She is the Senior Director of Engineering at Equinix and a fantastic engineering leader. Thank you so much for joining us for INTERACT today.

Shweta Saraf:
Hey Conor, thanks for having me back.
It's great to talk to the dev community here.

Yeah. We love talking to you.
She did an incredible job for those who missed it on our remote engineering panel a few weeks back, and we're really excited to have her back to share her engineering leadership screw-ups stories with us today for INTERACT. So what's the story you're going to tell us here?

Yeah, so when Conor reached out, I was like,
wow, there are so many stories and we don't talk about screw ups, but it's right important to talk about them and normalize the failure and what you learn from it, right? So today my story is going to be around when we were starting a team, when we were in high growth phase, how did we make decisions around having a full stack team versus a very domain focused team and what works to help with that. So are you ready?

Yeah, good. I'm excited.

Yeah, so basically the sort of time when I had eight people on my team,
all engineers who had a strong background knowledge, I inherited another team, which was really solid on the frontend and the UX side of it so it was an important decision as a leader. Like, how do I allow teams to work together and prosper in it and improve our velocity and delivery of results? So while we had a lot of metrics and dashboards like, one decision I made as a leader after talking to a bunch of people was let's create a full stack team. So we took a couple of people from the back end, domain expertise and people with front-end knowledge and put them into a team. And, you know, the results were very mixed. But the story I want to share today is how we failed at full stack teams, because the work we were doing was very back-end focused. It wasn't the case where we were iterating on a portal very fast or something like front-end work was very much driven by the back-end features. So on this one specific full stack team, the members of the team who were experts in front end would not have enough stories in their backlog, they felt like it was a big ask to get familiar with coding in stack that they are not experts in. Some people were more open to it than the others, and as a result of it, like the team sort of had their productivity just go down and happiness go down. So that was something that I learned quickly from because I saw that people are not happy. And when you do a design or a re-org as a leader, it's very important to understand the reason why you're doing this. And there's no one size fit all or just because full stack teams work in one setting, doesn't mean it will always work in this setting.

Yeah. I'm sorry to cut you off,
but I think you're totally on point there where it's just like, things are really different depending on the team and the situation and the people involved, which sounds like you realized pretty quick.

So I think when we made those decisions to sort of reconsider it, doing all the front end people together, then I feel like the team was much more happier. They were able to work as a team and help each other out and make things faster, while the back-end folks were more focused on intricate complex architectural work and work at a different pace. So, I mean, I think it was worth, like, trying this out and, you know, experimenting and making the time bound so that, you know, we don't have people sort of go through these waves, which really something that people don't like in terms of engineering or going through multiple changes without the change leading to a positive effect. Yeah, but I'm happy to share that once we reversed the changes and did the right things, the team velocity shot up and they were able to deliver all the projects, we didn't lose anybody. So we were able to lead in each one of them. And we also found one person who showed more interest in the back-end work and started picking up that end of the staff. So overall, I think it was a screw up where we lived through it. We came more on the positive side of it.

Well, I love that you're addressing that. You're saying, yeah,
we screwed up with the initial decision, but we thought about it. And like you said, your timebox, it was at 90 days, six months. Like, how long were you doing it for? Just kinda curious.

Yeah, I think it was around six months
because, like, that amount of time you need a team to, like, get together and...

Really experience it, yeah.

orming, storming, performing, that kind of thing.

Could you tell, like, quickly that it probably wasn't going to work?
Was it a couple of months and you went, oh we'll see. Or when did you kind of realize fully that wasn't working?

Yeah. That's a great question, Conor.
So I think as a leader, you have to exercise so much patience, right? Because you see sometimes that you have an intuition on C science that things are not working, but you have just to trust people and power them and give them an opportunity to succeed at this, right? But the point where it was not... It was very obvious that this is not working is when I was speaking to one of these engineers and it was a female engineer, and the conversation was just around, like, how unhappy they are. And why were they feeling this way? Because, like, overall, we still had the same goals. We still had the same benefits. We still had the same projects. But to them, they enjoyed pairing with people, and that's how they were really productive. But in this new setting, they felt very lonely. They didn't have anybody to pair with for the exact PR they would be putting forth. And at that point, it was an a-ha moment for me. This is not working for the people, so we cannot just continue with that, even though the idea of it sounded really good in terms of achieving cross team collaboration.

I love that you're really using this "people first" idea of saying,
okay, we can't just shove people into a form and expect it to work. We have to actually think through, like, how does this impact them? And track and measure and talk to them. What kind of ways where you doing that tracking or doing that measurement of how successful these individuals were being?

Yeah, I mean, definitely.
I think one thing that sums all these things up is engagement. And that is like, how frequently are we committing forward? How good is that goal? Are they able to meet the deliverables? But also more on the personal side of it, right? Are they engaged? Are they working well with their coworkers? Are they lifting the team, or are they dragging the team? Those were some of the measures. And we used to do, like, one service too, which sort of also gave us some quantitative data where we saw the pulse of the team sort of go down. A specific feedback around this whole reorg.

So I guess my question now would be... Obviously you've learned from experience.
You've grown. I'm sure done re-org since then. What is your strategy now when you're approaching a re-org? What kind of things do you do differently or what improvements have you added?

Yeah, that's a great question, because this topic is very interesting to me,
especially when you're in a high growth phase when you have single digit engineers, to then two digit or digits or more, right? So for me, some of the things that I consider I approach, we all got org designers I like to color. Similar to how you would design a software component. And what are the goals? Like, where I'm trying to optimize on? What kind of trade offs? And then also considering what is the gap. Because somebody... Like a change always allows people to sort of step up, right? For some people and for some people, it's a risk you want to work. Because there is covers or whatever. But I mean, I also look at like if I'm putting somebody new in the role, what do I need to do to invest in their success, right? So it's not like you got this thing and go figure it out. Those are some of the things that I consider but I think it also starts by grounding. What are our values? What is our culture? And it requires a degree of change management, which also needs to influence how people feel about things, how they show up, and how they have responsibility or accountability towards that work. And to me, that's why my approach is I don't need changes on this unless it's absolutely necessary. And when I do, because it’s very thought through and have worked through multiple combinations and the trade-off analysis before I put forward for the presentation on what I want to do to my leadership. And once I have buy in and I also have a very thoughtful process of how I roll it out, that it's important to me that people who are affected by any kind of change. The item form first and then rest of the organization is made up. Everyone knows who the go-to person is.

Absolutely, I think you're very smart to be doing
that intentional organizational design, as you put it, because not only is it important regularly, but especially as we have transitioned to this hybrid or remote world where we don't have the kind of advantages of having people in the office to easily talk things out, that intentionality upfront is really important. And I think that's super crucial and one of the reasons that you and Equinix have been so successful. So thank you so much for taking the time to share that with our audience. I know a lot of folks in the chat and attendees today are leaders who are starting their own organizations or scaling and working to learn and that experience and that perspective, I think, is so valuable. So thank you. It's always such a pleasure, Shweta to have you join us for any Dev Interrupted event and we're so excited you could join us for INTERACT.

Yeah. Thank you so much.
And I enjoyed talking to this community, and I appreciate the opportunity.

Explore your dev team's metrics in less than 3 mins!

I'm interested