1:1 with Smruti Patel, Engineering Manager at Stripe [Interview]

For our series, 1:1 with Engineering Leaders, Code Climate and Codecademy for Business are speaking to managers and VPs about their career journey, leadership strategies, and advice for the next generation of engineers. Check out our previous interviews here.

Below is an excerpt from our conversation with Smruti Patel, Engineering Manager at Stripe. Smruti spoke about getting to know your team members, the importance of delegation, and the power of well-designed metrics. Edited for length and clarity.

For Smruti’s advice for early-career engineers, visit the Codecademy blog.

Tell us about your current role, and your career journey up to this point.

I currently lead the LEAP organization — that stands for Latency, Efficiency, Access & Attribution, & Performance — and Big Data platform engineering at Stripe. I came to Stripe after 11 years at VMware, where I worked on their enterprise disaster recovery solution and data protection for the cloud. So, looking back at my career, I’d say I’m a generalist at heart who loves bringing a rich, diverse set of people together to solve complex, ambiguous problems. And I’ve been leading teams and organizations for almost a decade.

Did you start out as an IC?

Yes, I started off as an engineer back at VMware after a Master’s in Computer Science. I moved from New York to California when I saw nice skies and better weather. I started off at VMware as an automation engineer. And then I moved to managing the team that I was working with. From there, I transitioned to managing and leading multiple teams.

What was the transition like from being an IC to managing one team? And then the transition to managing multiple teams?

VMware was very thoughtful, and still is, in developing its engineers and growing its engineers. There are dual tracks, where you can grow as an individual contributor, or you can pivot to the management track.

I was deciding whether I wanted to move to Staff Engineering or to be a manager. At that point, my manager approached me to manage the team I was on, and I was already owning a lot of the day-to-day tasks around technical design decisions, communicating to different stakeholders, figuring out release timelines, mentoring junior engineers, and in general defining the strategy for the team.

So it seemed like a logical next step, although looking back, I decided to switch to management in big part because I thought I’d have higher authority and autonomy in driving the product strategy. So I would say I probably got into it for the wrong reasons, because I soon realized I couldn’t do a lot of that.

But I stayed for the right reasons. I like seeing people grow, giving them feedback, identifying what made each engineer tick, and seeing an excited, motivated set of people come together to work magic to solve complex business needs.

And then another big switch came to me when a peer manager approached me to see if I wanted to manage one of the development teams alongside the automation team. And that was a second switch.

One thing I’ve learned, looking back, is always say, “yes.” Raise your hand when an opportunity comes knocking. I think the switch there was from managing engineers to managing engineers and managers or multiple managers. The shape of the challenge there is slightly different.

Got it, and how is it different?

One thing that is common to both is that you’re trying to walk that line of either being a mentor or a coach or a sponsor, and asking open-ended questions. The thing that I found different is that now there’s this level of indirection, so to speak.

Identifying how the team is doing, debugging team engagement or velocity required me to delegate a lot more. While managing managers, you have to let them drive some of the strategy and the vision for their team. So the scope of what you delegate changes.

What do you see as the role of a manager and the role of a leader? Are they different, or are they the same?

I think about that a lot, because walking that line and being one or the other at the right time is important. I’ll start with being a manager. Three to four things come to mind here. One is hiring the right set of people. The team composition based on diversity in skill set, in representation, in perspectives in experiences, is super crucial. That I think is almost the number one priority of the manager.

Now that you’ve got folks, and you’ve got them in the door, how do you then set them up for success? So the second thing that I think managers should focus on, which I personally do a lot of, is ongoing 1 on 1s. How do you set up expectations around what the business needs are? How do you determine what level each engineer is at? How do you support them through challenges, whether they are technical, or organizational, or even personal sometimes? You’re doing that by building trust through vulnerability both ways, and ongoing feedback. Radical Candor is a really good book on frameworks for providing that ongoing feedback, whether it is constructive or critical. Quite often managers focus on things that could be better, but it’s equally important to be able to reinforce the positive, and to say, “continue doing this,” or, “you’re doing great on this.”

So, once you set them up for success, the other thing I especially try to do is to provide access to opportunities to all. Having been — well, I still am — a brown woman leader in tech, I’ve had my fair share of not having access. So something I’m extra mindful about is ensuring access to opportunities, to those big risk, big reward situations, for every person on my team. I go ahead and identify those stretch opportunities that are uniquely catered to their strengths, or their interests, or their career aspirations.

And so that’s on the hiring and the team building side. The other big area that managers focus on is engineering. There’s the planning: Why are we building? What are we building? And there’s the execution, which is: How are we going about building? How are we measuring it? This is where engineering velocity comes into picture. Third, there’s delivery, which is: Is it really done? And making sure your feedback loops are actually telling you the story you wanted to tell, and that users are happy. And as you’re building all these new, shiny things, they have to last the test of time or the orders and magnitude of scale.

So, building teams, setting them up for success, and ensuring that we are doing what we are actually here to do. And then you have to bridge the gap. I think quite often I see a gap between what the team is doing and what leadership expects the team to do. So it’s important to bridge the gap between the business and the individual by being the advocate for the team, the team’s impact, and the engineers’ contribution. That can involve getting stakeholder buy-in, resolving conflicts, addressing concerns, and sometimes even marketing the team’s work.

That’s management. The way I think about it is, if you were to draw a Venn Diagram, all leaders are not managers, and all managers are not leaders.

Leaders are the ones who drive changes organizationally. They are able to influence others, not through authority, power, or control, but by motivating the right set of goals, elevating the collective ambitions, and then demonstrating success. And that’s the subtle difference that I see between managers and leaders. Where managers have to be focused on a lot of the tactical side of things, I’ve seen leaders bring along the strategic and the visionary elements. And that means ICs can be leaders too.

How do you drive high performance on your team, both at the individual level, and at the team level?

This one really keeps me up at night. It goes a lot to not having a cookie cutter approach in general. That’s why I focus a lot on regular 1 on 1s with every person on the team, because that’s where I develop a better understanding of what motivates each person, what challenges each, what drives each. Everyone is at different stages, in their careers and in their lives, and a pandemic doesn’t help. Each situation is very different at home. So it’s important to be able to connect with everyone and understand what their unique strengths are and what are they looking to grow into, and to take a longterm career view.

I tell a lot of my reports that once I manage you, I manage you for life. Because it’s not about whether you are on a team that reports into me. It’s about where you see your career, and how I can best support you for the longer term. I try to marry the team’s deliverables with their individual aspirations. And I try to do it in a very transparent and consistent way, and to make sure that all the voices in the room are being heard, and that the access to opportunities is going across the team.

It’s important for everyone to have the opportunity to be the DRI, or Directly Responsible Individual. You lead a project from design through execution, leading other engineers, both within the team and across. So, being a DRI is sort of a big deal. I make sure that the same set of folks are not always raising their hands. And that’s why I run a very transparent, consistent DRI selection processes while highlighting what is required. And I’ll sort of nudge people and say, “Hey, you would be good at this, why don’t you apply?”

And then what is more important is making sure that folks have the psychological safety to fail. High growth comes for individuals when they take on big, risky things. So I try to make sure that all people on the team are taking those risks as well, and I give them the safe space with good feedback and space to fail. If they succeed, that’s awesome, they’ve stretched themselves and in the process, they learn.

The meta thing in all this that I communicate with the team, is the growth mindset, which ensures that everyone’s learning and growing as we go, because that’s what the organization needs.

Now that we’ve talked a bit about performance — how do you approach engineering velocity on your team?

I manage six teams right now, and each team is in a different state team maturity, so the shape of all six teams is very different. At the planning stage, I work on getting alignment, and then prioritizing and focusing on the right things.

In execution, you drive speed and quality, how you’re doing things. This is where Dr. Nicole Forsgren’s Accelerate book is really awesome. It helps you identify whether you are tracking the right metrics and evaluating whether the team’s execution is where it needs to be.

I tie it back to: here was the metric we signed up to solve for, here’s the problem we were looking to solve, and here’s how the needle has or has not moved. Tying that feedback loop together becomes super crucial during delivery.

You also have to pay attention to operations and maintenance, and make sure that the less glamorous bits are not sucking up all your soul, because you do want to keep doing the strategic innovative work. At the same time, if 80 to 85% of your team is bogged down, just keeping the lights on for the stuff that you’ve shipped, then you’re not going to be able to invest in new things.

We frequently hear that managers worry their team members will be resistant to using metrics. How did you approach that? How do you get your team members comfortable using them?

This happens so often that it makes me smile. I personally view metrics as something that has to be used carefully. They can do a lot of harm, and the right metrics, when crafted correctly, can also do a lot of good.

A well-defined metric can drive alignment with stakeholders and leadership. It can help drive prioritization and focus within the team. But it can also help the team say, “Hey, here’s a metric we really care about, which the company cares about, and clearly we’re under invested. Here are the projects we need to do to move the needle.” When done right, they can really increase the overall impact the team can have.

But there can also be times when the team may not feel like it’s in full control of its own priorities, or when it could be over-indexed on some wrong metrics. That can have them start losing faith in the system.

One of our teams was measuring their overall efficiency in terms of how our standard infrastructure is increasing as a function of Stripe’s business. This is a very company-level metric, because it’s not that my team actually spends the money on all the infrastructure. It’s about the money that everybody at Stripe engineering spends. So, a natural question the team had is, “How are we accountable? And why are we accountable for the top-line spend when we do not have the agency control a lot of it?”

That was a very interesting thing. It was very true, we couldn’t move the overall needle. But we’re Efficiency, we’re sort of the last line of defense. So how do we then push the envelope and bring about organizational change, so we can see areas with pockets of inefficiencies? The only way to do that is to have a true North Star, company-wide metric, which we drive, which we provide visibility on.

So these engineers saw leadership acknowledge that this needle moving up and down is not solely Efficiency’s responsibility, but that Efficiency is an enabler to that change, and will be the voice of reason. Leadership communicated that if it’s down, you’re obviously responsible for it being where it is. But if it were to go up, hearing from you on the causes and the drivers is what we would hold you accountable for.

I’m going to transition a little bit more into general advice. But before I do that, is there anything else around metrics that you feel is important to say?

Metric design sounds obvious, but it can be very challenging at times to measure the right stuff. It’s hard to walk that line in designing the right metrics, which the team can own, and which really move the needle on impact. Word of caution, but you know, with great power comes great responsibility.

What advice do you have for new managers, or for people looking to shift out of an IC role and become a manager?

At least in well-designed engineering systems, management isn’t the only way to up-level yourself. I personally would suggest running away from such systems if you have the privilege to do so. Truly well-designed systems have an IC track, and a management track.

And then, avoid the new manager death spiral, which happens when you want to own and control it all. When you’re in IC, you’re in full control of your destiny, you know what your project is, you know how to scope it, how to design it, how to execute. But as a manager, I think the first thing you need to do is give some of that control away. It’s worse if you actually go ahead and do everything, because you’re not letting your team take on some of that.

You also have to get comfortable in the unknown, because you’re not coding day to day. And if you are, then you’re you’re not doing what you are uniquely positioned to do and accountable to do, which is be there for the team, be there for individuals on the team and grow them and motivate them. You need to delegate, and to share your trust and faith that your team will grow into it.

Don’t see management as a promotion, see it as a shift in role, and acknowledge that it will be a bit uncomfortable for you, and give yourself space to be okay with that. The output of the manager is not very tangible in the near term. It’s a lagging indicator of success, and the feedback loop is longer. So, it takes time for you to see how you are being effective.

Remember, you don’t have to have all the answers. And you don’t have to always be right either. You need to be open, be curious, and at times be vulnerable. The job is to find and hire the most brilliant minds with a complementary and diverse skill set, and get them together. And your unique responsibility is to create the environment for that set of folks to flourish as they work together.

For more of Smruti’s advice for the next generation, visit the Codecademy blog.