Applying a Systems Thinking Lens to Management

Aydin Mirzaee (Fellow.app)  00:00

 Smruti, Welcome to the show!

Smruti Patel (Stripe)  00:17

Thank you Aydin, excited to be here. 

Aydin Mirzaee (Fellow.app)  00:22

Yeah, I’m I’ve been looking forward to the conversation. You know, we haven’t had anybody from Stripe yet on the show. And you know, I’m a big fan of the company. And I know you think a lot about systems at Stripe and I’m very curious to dig in. But before we get into all of that, I know you’ve been managing diverse teams for the last 12 years, you’ve done a lot of work in quality engineering today, your head of engineering as part of the lead group, as you mentioned. And I’d love to just start by asking you in your career has there been a manager that you remember favorably or someone who’s been someone you have good memories with?

Smruti Patel (Stripe)  02:56

Oh, that’s a fun one to kick off. Alright, so let’s talk a little bit about me before we get into that. So I’m at heart a very independent person. And I always have been, I grew up in Mumbai, and was very fortunate to be raised by parents with two daughters. And they basically taught us that if he worked hard and didn’t take any shortcuts to success, the sky was the limit. And I personally loved stem from the beginning, which was solving puzzles, asking questions, and being curious about the why. So naturally, I got into engineering. And after my bachelor’s degree, I wanted to study further. So I packed my bags, moved to New York, and got a master’s in computer science. Then I had a few offers in the financial world from the cities and the governments. But then I came to Palo Alto for an interview with VMware, which back then was at the helm of virtualization, blue skies, white fluffy clouds, rolling meadows, and even horses, it was like paradise on earth. And so I didn’t believe it or not, my twenty-year-old self decided to move for that. And then I worked on the hypervisor, and then the control plane, and then the disaster recovery solution. And by the time I left, we were working on data protection for the cloud. And so over my tenure, I realized that I loved solving ambiguous problems, and then driving clarity and delivering results just came naturally. And somehow, for some reason, one consistent thing about each of the managers I had these last two decades was this other independent streak in me and each of them gave me that autonomy. And so I’m extremely grateful to each and everyone who gave me that space to explore, to stretch myself to see some potential and basically take a chance on me and let me grow. But my very, very favorite one is someone who said Smruti, define your job description. You are wired for results and you will get them no matter where you go or what you do. And that struck a chord with me, because I’ve always worked hard and continue to do so. And so often tend to focus on what could be better, or how could I improve about myself. But then you sometimes forget to take a step back and realize, damn, you’re the one who now has privilege and choice, and consequently your responsibility to sort of pay it forward. And by this, what I mean is, you know, you don’t have to anymore be waited to court to be called upon to effect change or drive impact, but to then lead by example, and then create that reality that you want to live in, whether it’s for yourself and or those underprivileged around you. So that was the most favorite thing or most memorable thing.

Aydin Mirzaee (Fellow.app)  05:46

Lots to unpack there. I’d love to start with just this concept of defining your own job description. What does that mean, in practicality? 

Smruti Patel (Stripe)  05:57

That’s a lovely question. I think this is where self I think a lot about being self-aware. I, for one, always a straight-A student, my career was like no one baby step in front of the other kind of thing. And so it was in my early 30s, when I came across this book, fixed mindset versus growth mindset. And I was like, wow, I have been living all my life with a fixed mindset. And so that book basically revolutionized my life, in some ways, I think, because I said, Alright, you know, time to stop playing it safe in some ways. And the way I think about career progression or shifting role, I think about it in three axes. One is where you sort of changing the domain you’re working on, be it you know, working in financial payments, or working in a different healthcare sector, you could still be in tech. But the domain that you’re working on for your systems is slightly different. Another axis is the role that you’re working in. And you could be an engineer, or an engineering manager, or product manager, or a manager of managers. And so the second axes I talk about is the role that you’re working in. Lastly, is the organization you work in, the social capital, you have the systemic culture, the environment you work in. And so it could be anywhere where I was there for about 12 years, I worked on changing one of those three axes at every point in time, where I either had a change and rule or change the product I worked on. And then I came across this book, and I said, You know what, it’s about time to change some things. As you would expect, if you change one of those three axes, you’d likely be able to leverage some of your strengths and pick up a new area. If you change two out of those three axes, you’re likely to have a slightly steeper ramp up. But if you change all three, then you better be ready for a nice, fun bumpy ride. And so I went from managing managers on an infrastructure product at VMware to leading a team that optimized cloud costs in the financial area at Stripe. So I basically changed all my three axes. And over the last three and a half years, I started grew that team, into the leap organization, which focuses on cloud optimization, and solving for stripes, user latency, and I also lead the data infrastructure. So coming back to your question about defining job description, the way I think about it is, evaluate where you are in your career in your life. And if you have the privilege to do So ask yourself, what brings you joy? And then what are you optimizing for? Where I’m in my life, I want to work with an excellent set of people solving ambiguous problems and with enough autonomy. And I love being at Stripe because it gives me all of that plus a sense of community. And giving back to the word.

Aydin Mirzaee (Fellow.app)  08:56

It’s very interesting that your manager like at that time, was able to, you know, give you that freedom and autonomy. And is that something that I wonder how you think about it with your teams? Is that something that you try to lead with autonomy as well? How does that work for your immediate organization? Or how do you, I guess, get more people to follow that way of being?

Smruti Patel (Stripe)  09:20

So that’s a really fun question. I think when I think about autonomy, the first thing that comes to mind is the sense of intrinsic motivation, which is what makes each of us tick. And that theory of intrinsic motivation basically talks about three things, which is convenience, purpose, and autonomy. Now, let’s say you’ve got your perfect team of super doers in Korea team of engineers or managers. And you’ve also got a good vision and mission established for the team or org space to see you know, what we’re doing and why we’re doing it. And so the question I’ve been thinking a lot about is what does fostering autonomy look like? And what does that look like as your organization scales? What does it look like in a team of six? What does it look like in an organization of 60? And what does it look like in a company, not 600, potentially? And so as you scale, and you want to drive that autonomy, it starts fundamentally with trust, how were you sort of going about building trust with your immediate team. And once you’ve sort of focused on building trust, which also involves things like being open, being vulnerable, making sure that you are providing clarity and transparency as you go, the next bit to focus on is how are you then delegating scope and responsibility to the folks on your team such that you can build for sustainability and scalability. And so when I think about fostering autonomy, it comes down to building trust, delegating scope, and authority and then providing the right guardrails around it, because you can’t sort of giving someone a problem, which is going to stretch them without creating like psychological safety to feel or, and support them. And you also want to create those feedback loops, whether it is through feedback by mentoring by coaching or by sponsoring. And so once you delegate scope, responsibility authority, and you make sure you start on nurturing that environment, where you’ve sort of set the others up for success. The last bit is the flow of information. Now, this is something which gets, which I’m personally working on as an area to improve. Because as you sort of scale, your organization’s how your information flows, is supercritical. And that changes as an org scales too, so I think autonomy to summarize, it’s a trust, delegation and information flow. And both you know, how workflows between your teams and our exterior.

Aydin Mirzaee (Fellow.app)  11:53

Sometimes when I think about trust, it’s if you I think if you do a good job at hiring the right people for the job, then it makes sense to trust them to do you know what it is that they’re supposed to do. And if you trust them, then of course, you can give them the autonomy to let them work on those things. So you know, how much of this is about, in your opinion, hiring the right people? And, and is it as easy to establish trust, if you’re not the person that has hired those people to begin with, say, like, you start managing a team that you weren’t responsible for hiring, but now you get deployed in there, and then you have to build trust? Are there any things that you have done or things that you would recommend for teams, and in general to build trust?

Smruti Patel (Stripe)  12:42

That’s a really good question. And I think the way I think about trust is, especially when a new leader comes in, the onus is on you to be able to establish that. And so what does that look like when you get parachuted into a new team? And the best thing that I have found the most, most effective is listening, right? Be open, be curious, understand what constraints the teams working with understanding what they’re optimizing for. Build that sense and mental model by asking a lot of questions. I think one thing, which sometimes leaders tend to do is just getting there and saying, okay, and all this is broken, how do I fix that? Right. But I think it is, it’s very important to first build the context and hear folks out. So for one of the data infrastructure teams that I recently inherited, a big part of my journey in the first 30, 60 days was just, you know, doing that tour with folks on the teams to say, you know, What, are you seeing what’s working? Well, what is not working? Well? What are things that you would like to work on? But we aren’t getting to? What are the reasons behind that? And what are we optimizing for? So to me, a big part of driving trust is not just about hiring, I mean, if you can control that aspect, great. But if you sort of get a team, listen and listen well. And then it once you have done that, and you’ve established your mental model of what is going on with the team, you will also build a sense of the capability and the capabilities that the team has. And there if you’ve seen any gaps, the question is, what I what is the support that is provided to them? Is it through mentoring and coaching? Or is it just a lack of skillset that you can also complement depending on what the team needs?

Aydin Mirzaee (Fellow.app)  13:18

Yeah. So it seems like I mean, the sense that I’m getting is that you are generally a very systems thinker. And you have a lot of thoughts and opinions on just thinking in systems in general. So I think like coming from a world of engineering, you know, most things are systems in engineering. But I’d love for you to maybe elaborate on why you think people or teams can be thought of as systems as well?

Smruti Patel (Stripe)  14:55

Yeah. So this is another book that kind of blew my mind and sort of changed how I was Thinking things, right? So typically, when we think about high performance or high productivity teams, a nine view is to imagine a bunch of developers sort of burning the midnight oil and just shipping faster or shipping more stuff or cold beer behind the bar. Or you could have security loopholes, or maybe it doesn’t even serve the user’s needs. So in theory, you could have a highly productive team. But does it really serve the purpose? And so over the last two decades, I’ve worked as an engineer or manager and our Magento. And through this sort of led diverse teams of smart, talented engineers, and then ship infrastructure, whether it was as a product for enterprise customers, or as a platform for internal users, like I now do at Stripe. And through all of this, I think that the two things that have helped Well, for me, one is the theory of motivation that I talked about where engineers don’t like motivation, they’re here to do their best work. So how do we as leaders then create those environments for engineers to sort of just come together and work their magic. And, and this is where thinking in systems by Donella Meadows really through my mind, is essentially what it talks about is how for any system, you want to identify that set of elements, how they interconnect, and then the function or purpose that that system is aiming to serve. So what, what this tells us is, if you’re sort of map this to the engineering productivity problem, there’s basically more to leading high-performing teams, than then that just goes through the tactical stuff of sprints, or agile or story points, or okrs. And so, basically, nothing works but is drawn in isolation. And so then it becomes important and crucial to define what success or high productivity looks like. And so in theory, to me, what is most consistent across all the high-performing teams I’ve laid is three things like business success, like what is the precision and impact in terms of what we are building? And why the second esteem level of success, which is how well are the set of individuals working together? And how effectively are they shipping code with agility or with quality? And lastly, you know, success, which is like how engaged are motivated individuals on those teams are amazing, how are they growing or stretching themselves? And so when you look at all of this, as leaders, you want to create those for dial inclusive environments, you want to create that psychological safety that I talked about, and have a growth mindset to say, you know, can individuals grow given the feedback and mentoring, and to do all that you have both qualitative or quantitative metrics to help with that? So I think about debugging productivity, to me, it isn’t about measuring how many commits or how many lines of code and engineers written, it comes a lot into, you know, what is the environment or the system that they also working on? And what could be better there? Like, I’ll give you an example for one of our key batch computation systems, we were starting to see this increase in job landing times. And we were routinely getting paged. So we said, You know what, let’s keep our plant project execution on hold. And let’s do a four-week reliability search, we did that we diagnosed a bunch of the issues that popped up. And we then also fix some key bugs in Hadoop upstream. And for the first time, in over six months, we actually had fun. Trade two weeks of no incidents are no pages. And so if I look back upon that decision, it’d be fairly naive to sort of just evaluate that project sprint points in isolation and view the team as being unproductive during that period. But if you see that technical debt is growing, you will also notice that the number of incidents or your pages or your toil, is also increasing. And so when you think about sprint over the sprint, if teams are finding it hard to deliver committed work, what I’ve also noticed is it is important to not get into that downward spiral, where engineers can get be motivated, they want to leave the team the team gets harder to hire into, and then its technical systems get much harder to maintain. So that is where you want to then assess like, what is the cost-benefit analysis of solving it now and sacrificing temporary speed over a longer-term increase in that velocity?

Aydin Mirzaee (Fellow.app)  19:32

Yeah, so I’d love to dig in there. I mean, you talked about you know, avoiding getting into a downward spiral and making sure that people don’t leave the team. So in your experience, what typically are things that lead to that downward spiral? And like, how can you solve that with a system in place?

Smruti Patel (Stripe)  19:53

Right. So I think there what becomes important is to say, Okay, do you even have a problem with your hand? And one way to assess if you have an engineering velocity problem is like, what markers? Are you seeing? Are you seeing your users unhappy with what your team is shipping? Or are you hearing or the organization? Cut your budget, either a budget in terms of headcount or in terms of promotions? Are you not having buy-in? Or are you having regretted attrition where folks are leaving you if you seeing certain markers in the thing to figure out is, where is the problem? And how do you debug it? Right? And so to do that, all you got to think about is, what is the team working on? So evaluate which of your three phases of software development urine, typically, even if you’re doing agile, you go through these phases where you’re sort of doing some planning, what you’re trying to build? And why are you building it. And then you are in this execution phase, where you’re sort of implementing your systems, writing your code, testing things out, rolling it to production. And lastly, the delivery aspect. By this, what I mean is, you know, what is the marketing or advocacy you have to do to imagine that you’re empowered to to see that your impact has truly landed? So when we talk about, you know, what does that downward spiral look like? What do you want to talk about? In your regular one on ones, what is that sense of engagement and motivation that is coming through from individuals on your team? And if you started hearing some discontent, you know, I don’t know how my work relates to the business. Or if you’re hearing one of the engineers is, like, you know, unhappy about the predictability at which we are no source shipping code, like I give the year example, were we seeing a sudden surge of incidents and toil. And so my natural reaction was to talk to someone on the team and say, Hey, you know, how are we handling this? How can I support you? What can I do better? And the engineers like, yes, I’m not getting to do what we committed. And I can be super demotivating. Because, you know, here I am, I’ve committed to the schools, I really want to ship. But all this unplanned, unpredictable stuff comes in from the left. And so the key to do is ask yourself is how do you have a pulse on? What is the team doing? And how are folks on the team feeling, and then sort of start diagnosing how, where you are that you need to sort of put the pressure on sometimes it could also be, you’ve got multiple, too many cooks in the kitchen kind of situation? In which case, you start to zoom out and see, okay, do we have our rules and norms established on how a set of individuals will work together on a project? For this, I found the RACI Matrix by Lara Hogan, very useful, which talks about who’s responsible, who’s accountable, who needs to be informed and consulted. And I recently did that. When we were working with where I was the engineering manager, we had a tech lead, we had a technical program manager, and we like, okay, who’s handling what, let’s make sure we draw that Venn diagram of responsibility. So we all know who’s doing what. And, and that was, again, a systemic thing, because we realized we were either multiple people doing the same thing or some balls were getting dropped. And so when you come back to how to avoid the downward spiral, you want to see where you are in your software development, where the problem is. And by and large, the problem isn’t just, you know, one rotten mango, or one rotten fruit, so to speak. And that is something that has been super interesting to see, and then adapt and evolve. In your playbook based on what situation you are in.

Aydin Mirzaee (Fellow.app)  23:41

You said a few things which were interesting. One was the, you know, do you have a problem? Because sometimes you just hear something. And if you acted on every little thing that you heard, you’ll be in 1000 different directions. So it sounds like you’re almost going on like this detective quest. Have you heard something like I don’t know how to say in a one-on-one, someone says, I don’t know how the work that I’m doing relates to the main mission of the company. Okay. So that’s the thing that you heard and then I assume you you go and you dig and you see, is this something that is happening everywhere? Is it this? You know, the one-off thing that that you heard? I’m curious, how do you what kind of questions are you asking during the one on ones? I think like, in an ideal world, you obviously have trust and people come and tell you everything. But we all know that doesn’t necessarily happen. So I’m curious what are some questions that you might ask during a one on one to get to the heart of the matter and some of the feelings that you have that you uncover?

Smruti Patel (Stripe)  24:42

I’m smiling because a lot of the one-on-one questions from Fellow have been super useful. And one which I regularly get interesting questions or interesting responses around is what are you optimizing for and I think this is especially very relevant for the senior engineers, you know, staff engineers and above or senior leaders, where it becomes important to do that gut check and align, to see, you know, what are the constraints? And what are the trade-offs that each is sort of facing? And what is their response? Like? And depending on what responses I get, we sort of say, you know, does this make sense? Is there something else that we want to sort of move, right, you don’t really have a good fast or cheap kind of thing? Either you can move time out, or you can sort out, you know, compromise on quality? Or you can say, okay, you know, what, can we shed scope in some ways? And so one question that I typically go to is, you know, like, what are we optimizing for? Does it still make sense? And in cases where we have these long-running projects, or initiatives, which we’ve not singularly left, but where we have a company-wide impact on or where we need agency, the question around, what trade-offs must be made? And what do we need to which assumptions Do we need to revisit, because for long-running projects, what I’ve often noticed is, I like to think about it as stepping stones, not milestones because at every stage, the idea is to shrink that realm of unknown unknowns and get enough data where you can either course-correct your 18-month project and sort of fix your Miss correction, so to speak. And so they’re asking where, hey, the assumptions we made six months ago about what we were going to build, does that still hold at this particular point in time? And so the second question that I lean a lot on is, you know, do our assumptions still hold. And lastly, for engineering managers, and senior leaders, this is more to sort of anchor around what your horizon of thought looks like. The question I try doing is, you know, which of the decisions that you’ve made, which held well, and which didn’t? And again, you know, the assumption is, I’ve built enough trust in psychological safety where, you know, folks find the need to sort of answer and we started, this is the auto-grading exercise, it’s more to sort of creating your own awareness of, you know, what does that gut go to call that you’re making? Which ones were good, which ones weren’t? And I’ve also always had the person be positively surprised, by a moment of self-reflection to look back and say, why did that well, since that moment of self-validation and recognition as well, which typically lands well with that third question. So for me, those are my three sort of good tools.

Aydin Mirzaee (Fellow.app)  27:36

[AD BREAK BEGINS] Hey, there before moving to the next part of the interview, quick interjection to tell you about one of the internet’s best-kept secrets, the manager TLDR newsletter. So every two weeks, we read the best content out there, the greatest articles, the advice, the case studies, whatever the latest and greatest is, we summarize it, and we send it to your inbox, we know you don’t have the time to read everything, but because we’re doing the work, we’ll summarize it and send it to your inbox once every two weeks. And the best news is completely free. So go on over to fellow dot app slash newsletter, and sign up today. And with that said, let’s go back to the interview. [AD BREAK ENDS] Yeah, I love that. I mean, you know, what are you optimizing for makes a lot of sense. And the other one is, when you’re saying that, you know, are the things or the assumptions that were that we made in the past? Are they still relevant? Today? I think that’s a really, really good question. Because I think the, you know, over the long term, you start doing something or there’s a process that you’re running, and then you’re in, in the mode of repetition, and you keep having that meeting, or you keep running that process. And nobody takes a step back to say, Hey, does this still make sense? I mean, the world has changed in the last six months, is it, you know, still make sense for us to do things this way. But the other thing that you have talked about is I like what you said, Is that Is just a random, you know, rotten, rotten fruit here? Or is this something more systematic? And I think it’s kind of like if you’re a doctor, and, you know, you see a symptom, you can kind of treat the symptom, or you can kind of see, is there something systematically going wrong? I’m wondering, is there like, Can you think of an example of a situation where maybe you heard of a symptom or you, you know, you found a problem, but when you dug deeper, it was actually something else that was just causing a lot of problems, but there was like one main root cause, you know, as it relates to systems or teams or some sort of structure in that way.

Smruti Patel (Stripe)  29:43

Yes, I think one comes to mind. So this is back in the day where there was this different role between development and QA engineers. And one of the symptoms we were observing was the career growth for QA engineers, there weren’t much of a trajectory past staff engineers. So the track, there was stuff engineers, you know, Principal engineers and sort of ended up principal. And then I think you became a fellow. And the career trajectory for senior QA engineers was harder to chart out or drive a narrative around. So one of the symptoms as we were not seeing enough senior engineers, senior QA engineers in the organization, another symptom that used to consistently come up with, hey, you know, the quality of our testing, the quality of our test automation isn’t where we’d like it to be. And so when I dug deeper into that some of my analysis on talking to folks talking to senior leaders, was around what is the system or the environment we’ve created in terms of career progression for this set of engineers, where we have certain expectations, but that mobility does not exist. And as a result, what we were seeing was either attrition at the senior levels, or migration from QE roles transition, transitioning to either engineering managers or development engineers. And he said, the reason the effect we’re seeing is not enough senior QA engineers, is it to do to folks leaving the system for different needs, or isn’t that we have not created a good enough progression story where the scope of influence and impact really exists. And so it wasn’t a case of like, person x is not the right QE engineer for this automation plan. And hence, testing sucks, and hence, the product quality sucks, right? Because if you pull on that thread, a naive view is to just say, okay, you know, engineer x is not doing what they need to just all of QE is not where we need it to be. And hence, the product quality isn’t where we like it to be. And so when you dig on that there’s clearly different systems at play here. The system that was at play is, you know, what was your career framework for your senior QA engineers? And did they have the right support? Did they have the mentorship that they have the coaching, and it is seeing the recognition and validation from the system, to see that that progression existed for them? But it was a compelling career path? And had we done enough of that, to actually support those folks through it? Let’s assume you fix that. And you could have a principal QA engineer who started designing the product quality for all the organization, what is the world like that look like? And then do you now have more top-of-line funnel? For folks who’s like, you know, I’m gonna be that person of their who consulted determine what product quality and user experience look like. So I think that is one example that comes to mind when I say, you know, an eye view could have just been to sort of single one engineer there and say, Hey, person, x could be so much better, let’s bring a person y, but then what is your why story to get to seniority or increase the scope of influence and impact they can have?

Aydin Mirzaee (Fellow.app)  33:04

Yeah, I mean, that sounds like a really hard problem to solve. In the sense of like it, you know, you see something like, say, product quality, or quality testing is not where it should be. And to come up with an answer of, we need to create room for more Career Mobility, so people can become more senior, or that like, the number of senior QA engineers that we have is declining. And, and to be able to diagnose that, how hard was that actually to diagnose and get to that? And was it like a, you know, you just thought about it? And you came up with the answer? Or was, was there a process involved in getting to that solution?

Smruti Patel (Stripe)  33:46

That is, again, a very good question. I think right in the moment I didn’t know I had a process. I think for me, it came down to that openness and honesty to say, you know what, I’m not going to make a decision based on one conversation from someone who said over here is the problem and sort of just reacting to that. I think, this is where, you know, my inherent inquisitive comes in, which is like, what else is going on under the hood. And so when you sort of pull on that thread, be open to where it takes you and be able to at least check your premises that you are making all those assumptions you’re making and sort of open yourself up to the narrative that forms and I think this is where I tie it back to that thinking and systems, which is, it isn’t about one problem being bad as in itself, but as about what else is happening in the environment that either incentivizing or disincentivizing certain behaviors. And as organization leaders, that is what you want to sort of focus on where you sort of scaling your processes, scaling your systems and diagnosing the right problem, ideally, upstream and not sort of just sort of solving for the effect and one isolated case.

Aydin Mirzaee (Fellow.app)  34:53

Yeah, no, that makes a lot of sense. And I know that Stripe doesn’t have this problem, but I can imagine, you know, if I take this same problem that you just stated and say I applied it for if we had, if we didn’t have, say, at a company, a career ladder or career, I guess a career progression for engineers, as individual contributors, then you would start to see, hey, a lot of our senior engineers are disappearing or becoming managers. And maybe they’re not so great at management, actually. And maybe they should have really stayed there. And so I think this makes a lot of sense. And the lessons apply to many other places. But I think you have a, you have a lot of thoughts around that decision to become a manager. And that transition as well. In your experience, like from the people that you have promoted to, you know, from being an individual contributor to manager, what are the things that you’ve kind of looked at to, to know that that’s a good decision to make.

Smruti Patel (Stripe)  35:57

So this, it comes down to some of the mistakes that I have made in the past? I think some of the mistakes that I made when I transitioned from IC to the manager was this misplaced sense of having more power or authority over product strategy. That was the main reason when I decided to switch from IC to em. The reason I still was, you know, very early on, I enjoyed seeing people grow through the feedback on the conversations I’ve had with them. And so one thing that has stuck with me is it comes down to people, the people that you working with the people that you report to you, the people whom you report into. And so to me, when I talk to folks who are thinking about moving from IC to management, the one thing I ask folks to think about is, how much do you enjoy working through others where your influence and impact is not tied to the code that you’re writing or the design you’re building up, but a lot because of the people you’re working with, and how you affect what decisions they make and how you set them up for success. So when you realize that, that is the aspect of engineering that gives you joy, which is bringing together a set of other people to do the work that you’d be excited about and for the outcomes you want to see, then that is the moment when it is useful to consider being a manager. And ideally, you know, you brought about it to brought up to in earlier which was in an ideal engineering system, you do have individual tracks where you not being forced to move from IC to management, just because that is the only way to sort of level up in some ways, right? Ideally, you have two distinct career tracks the engineering track, which goes all the way up, and the disparity with the engineering management track such that you know, there appears at the higher levels. And assuming that that exists, the transition from IC to EM, I ask folks to think a lot about how much they enjoy working with others and seeing their impact come through others.

Aydin Mirzaee (Fellow.app)  38:16

Yeah, I think that’s a very good point. And I often hear that when people start to become engineers, sorry, engineering managers, it starts to become difficult because you’re so used to building things and seeing the things that you built and feeling good after seeing those things. And then it changes, right, like the type of work you produce changes. I’m very curious. So you know, when you so you know, what you’re doing today at Stripe, and now that you have saved multiple levels and multiple teams and having that kind of a hierarchy? How does that change? Like, the more you go up in an organization, so from like, you know, first-line manager, when you go past that point, like what is the feedback that you get that makes you think that I’m doing a good job at this?

Smruti Patel (Stripe)  39:02

That’s a very good question. I think it gets harder and harder to sort of keep that pulse or get that honest feedback. So for me, one thing I look out for is at Stripe, we do this thing called Stripe Sack, which is every six months we do this engagement survey to see how folks on the team are feeling how do they think about the environment they working in? How connected they are, you know, what is what decisions are being made. They’re focused conversations, even around their productivity around their manager. So for me, a big source of feedback is that anonymized aggregated information, which then sorts of determines how is my org really performing? And how do we take this data and sort of form a game plan where you don’t have to solve, solve for world hunger kind of thing, but you know, pick one or two things and come up with an actionable plan on something to improve. Like this cycle. There’s something that I want to do a better job of, which creates that space for learning and development, where, you know, and this is true, especially in like rapidly scaling organizations where the more problems to solve than people to solve it. And so, for existing people, it gets important to give them the space to be able to also learn and grow. And that learning can come in different forms, you can either learn on the job by stretching yourself and stretching your skills, or it could come through, you know, stepping out, or it could come through, you know, conferences, and providing a budget and things like that. And stripe is phenomenal about sort of making sure that we have a flavor of each of these four folks on the team. And so one thing that unconscious we’re gonna do is see how we doing in terms of learning and development for folks on the team. A couple of other ways to sort of keep that pulse is a regular one on ones, I do skip levels, monthly skip levels with, you know, a set of randomized folks from the oil to get a pulse again on like, you know, what are things that are going well, what are decisions? We’re doing? Well, how strategic are we about the future? And lastly, all hands monthly, all hands to get a sense of, you know, where are we? Where are we headed? What are our priorities in the coming quarter coming half? And so between those in a try getting developing the feedback loops, to try driving clarity. One thing I realized is, you know, repeat, repeat, repeat is the mantra of leadership. So you want to be seeing it enough number of times, especially as you want to set a culture of that constant evolution, learning development, and creating that inclusivity. So I think putting the information out at least along three different channels, and making sure it comes back to you and you have that pulse on what’s going well, and isn’t is super crucial.

Aydin Mirzaee (Fellow.app)  41:43

Yeah, no, that makes sense. I agree with the repeat, repeat, repeat and waiting to see if what you’re saying eventually comes back at you too. That’s always that’s, that’s always awesome. Smruti, this has been really fun, so many great insights and takeaways. One question that we ask all of our guests is for all the managers and leaders looking to get better at their craft. Are there any final tips, tricks, resources, or words of wisdom that you’d like to leave them with?

Smruti Patel (Stripe)  42:15

I’d say the heart of all of it, is people. There is a really good article about managing up down and across, I highly recommend reading it. And so being able to build relationships and foster trust, and provide that ongoing feedback to whether your peers, your leaders, with radical candor and kindness is super crucial. For new managers, I’d say you know, management is not a promotion, at least not in well design engineering systems. It is a shift in role. So please avoid the new manager’s death spiral. And for seasoned leaders who are navigating orgs. And trying to drive that influence and impact through instruction, I’d say thinking in systems is my personal favorite, which I can’t talk enough about. And at the mental level, growth mindset changed my life to in terms of, you know, bringing our own attitude toward self-awareness, reflection, and learning. And just to end it all, I’ll say, for everyone out there, engineering leadership is a lot about dealing with ambiguity, living with constraints, and being adaptable, flexible, and resilient. And even like you said earlier today, it’s both a science but more than art. And it starts with you. So please be self-aware, adapt, and evolve.

Aydin Mirzaee (Fellow.app)  43:32

And that’s a great place to end it Smruti, thank you so much for doing this. 

Smruti Patel (Stripe)  43:37

Absolutely. It is a pleasure. Thank you so much for having me. I’m a big fan.