[CTQ Smartcast] Smruti Patel and The Art & Science of Engineering Management
Prefer an audio version of the Smartcast?
Or listen here.
Follow CTQ Smartcast on Apple Podcasts, Spotify, Google Podcasts, or on your favourite podcast platform.
Read the shownotes below or skip to the transcript
Helping your engineers succeed involves both art and science. How can Engineering Managers in tech companies learn to do this well? What if you are an individual contributor (IC) and want to try your hand at management? Is it a career move up or a change of stage?
Smruti Patel is an experienced engineering manager at Stripe where she leads the LEAP organization (Latency, Efficiency, Access & Attribution, & Performance), and the Big Data platform engineering team. She has been on both sides of the fence, having been an engineer before becoming a manager. CTQ’s J Ramanand spoke to her about life as an engineering manager: what is it like to see the world from different lenses of management, engineering, and leadership.
Here are some things we talk about
What Smruti got wrong when she switched to management
What Smruti disliked about managers when she was an engineer, and now have more sympathy for?
What are the right and wrong reasons for an IC to become an engineering manager?
What’s it like working in a writing-led culture of communication
How to advocate for your team
How 2020 changed the way she managed teams
Tips for a good 1-1 conversation
Getting teams to think about their personal branding
Some books mentioned in this episode
Resilient Management by Lara Callender Hogan
Radical Candor: How To Get What You Want By Saying What You Mean by Kim Scott
Accelerate by Dr. Nicole Forsgren
Transcript of the episode
[CTQ Smartcast] Smruti Patel and The Art & Science of Engineering Management
[00:00:00]
Smruti Patel: What is engineering management these days?... My attitude toward management is more around identifying those 'stretch' opportunities, things which would stretch someone but not break someone... When it does come to recognition, engineers love recognition... Hoping more engineering managers decide to take up this craft. It's a very fulfilling and rewarding career for sure.
Ramanand: Engineering Management is often said to be the glue that takes technical teams forward. In this Smartcast episode, we are going to discuss the art and science of engineering management, which not a lot of people talk about. To help us do that, we have Smruti Patel, who's an engineering manager at Stripe. So that's Smruti's LinkedIn introduction. Smruti, welcome to the Smartcast. I'll let you introduce yourself as well.
Smruti: Thank you, Ramanand, thank you for having me here. Heard exciting things about CTQ as well. Smruti Patel, I started at Stripe about two and a half years ago. Here, I lead two organizations. The LEAP organization, which stands for Latency, Efficiency, Access and Attribution, and Performance, personally very proud of the term I've coined here; and the Big Data Platform engineering. Across these organizations, basically, I lead optimizing cloud infrastructure sends and Stripe’s end-to-end latency. And the Big Data Platform focuses on providing the right batch computation infrastructure for Stripe's business. Before Stripe, I was at VMware for about 12 years, worked on the hypervisor and worked my way up the stack into data protection for the cloud.
Ramanand: You've been leading teams for almost a decade, and before that you were an engineer. So you've been on both sides of the [00:02:00] fence. So tell me which side of the fence was greener?
Smruti: That's a good question. It's been a decade. I think this was a little bit about my decision-making into switching to management. I was fortunate to be at VMware, which supported two tracks, by which I mean, the IC track grew into MTS or the member of technical staff all the way to principal engineer, and the management track, at some point, you could switch over at the staff engineer level into management. That went up all the way to director, senior director, VP, and even GM. Looking back, I would say, when I was an IC, the grass didn't exactly seem greener, it was just a different kind of calling. I went into it for the wrong reasons, then, like I'd like to tell my teams these days. But over the decade, I've learned that I'm staying for the right ones.
Ramanand: What is one thing that when you were an IC that you hate about managers, now you have a lot of sympathy for now that you're one?
Smruti: I think that's a really good question. There are two things that come to mind. One is inconsistencies in communication flows. As an IC, I'd often get really annoyed about the sequence in which folks would know about performance or performance evaluation or uplevels and promotions, or even things like team merges or team splits or reorgs. Now, when I'm a manager, I see that it's a really hard problem. Because a decade, in fact, this week, I'm in the midst of rolling out a reorg for one of my organizations, and it is very, very crucial to get the communications right.
One of my colleagues, Julia Grace, whom I look up to, says you never "YOLO" the comms, because [00:04:00] people are inherently so afraid of change. Especially as any moves happen, you have to make sure you've informed the right folks in the right sequence. One thing that comes to mind, which I underestimated as an IC was how managers would relay that communication across.
The other thing that comes to mind is repetition. I'd be like why is my manager telling me the same thing that they told me a week ago. But now as a leader, what I see often happen is some things do need to be over communicated. The things around you like what's our North Star? What's our vision? Where are we going? What needs to happen? What are users talking about? So a lot of repetition in that regard, actually enables teams to have something at the back of their minds, which then enables better functioning as well. So I would call those two things out. I've got a bit more sympathy for the management section than I did previously.
Ramanand: Talk about making that decision perhaps not entirely for the right reasons. So what are the right reasons and the wrong reasons for an IC to consider before they become a manager? Walk me through the decision making that someone should think about.
Smruti: I'd share my own personal experience. We had two tracks, and at that point, when I was a senior engineer and thinking about should I evolve into staff engineering or management, my then manager approached me to say, hey, Smruti, you're already owning a lot of the day to day responsibilities, which involve mentoring junior engineers, defining the test release and strategy, and even making technical decisions and partnering with stakeholders.
At that point, I said, 'Yes'. I said yes to switching to management, because I thought I'd get more power and authority around determining the team's roadmap and vision. [00:06:00] Quite frankly, once I did switch to managing the team, I realized that a lot of that, at least at VMware, was not done by engineering managers, it was primarily driven by product managers, and they would determine what needed to be shipped. Engineering would just go through the motions and get that done. So engineering velocity, in terms of what needed to be built, wasn't a function determined purely by managers.
Going back to what I would tell folks, I'd say, tap into what excites and motivates you most, because to me, while I did get in for that wrong reason, one thing that I didn't know about was, I thoroughly enjoyed working with people and knowing what makes you tick, and sort of analyzing every person I worked with, whether it was my team, or whether it was my partners and stakeholders.
Looking back, this is the reason that I continue being an engineering manager, which is making sure I grow the people I work with, whether directly or indirectly. And then seeing an excited, motivated set come together to solve those challenging business and technical problems. As a leader, you then focus on what is the environment you can create? If you enjoy some of these things, then management is the space for you.
Ramanand: Does it help that, I think you mentioned, you've written that you're a generalist. And generalists have their strength, but they can also have their moments of feeling hesitant at times in terms of you're no longer the master of one niche. But now, suddenly, you need to know a lot. So was the generalist streak always there? Or did it blossom after you suddenly stumbled into management?
Smruti: That's a very good question. I think it's almost in the industry sometimes, the term 'generalist' gets a negative connotation. In fact, the first feedback I had received after the [00:08:00] last interview I did was like, hey, why do you call yourself a generalist and downplay it. To that, my first reaction is, honestly, I view generalist as yet another complementary function or a role to a set of team members. To me personally, in general, I worked on different parts of the VMware stack. I talked about working on the hypervisor, then into control plane management, and then into disaster recovery solutions, and then up into the cloud space.
Over that trajectory, I moved from being an IC to a manager. Over the two-decade career that I have, I think what has enabled me to pick up any new system is my background in a variety of distributed systems. That is something I think that is crucial not just for managers, but also for senior ICs. To that effect, what I quite recently did at Stripe, when we reworked the entire engineering ladder was at the senior levels. The Stripe IC chart goes from L-One, to L-Six, and L-Four and plus, we call them staff engineers. So for L-Fours, and L-Fives, when getting to the space where we said, hey, the shape of the problems are not all the same, but how do we still provide different career paths.
One thing that came across was we need solutions architects and product architects who can stitch things together. So coming back to me personally, what I enjoy being a generalist and what I think is now my hidden strength is this ability to take on any new problem and be able to understand how it works and diagnose it and then be able to relay that to what is the downstream impact. What are risks you want to think about upstream? How do things integrate well?
That I think has actually helped me well, where even at Stripe I started off with, building up the efficiency team, which does only [00:10:00] Cloud infrastructure costs. While doing that, we said, hey, you know, latency is going to become a problem, is what I told the CTO and we started doing latency. Now I'm doing the Big Data Platform, an area which I previously had no context on, but because of my generalist attitude, and this love for different kinds of systems and how they're put together, it makes it easier for me to be able to diagnose risks and mitigate it upstream than downstream. Sorry, it was a long winded answer.
Ramanand: Generalists can diverge and the good thing is that they converge. Because our audience is largely of generalists. I think a lot of our guests have been... And I think you're right that it's not a pejorative term. I think it's shorthand for someone who has different lenses to look at a situation through. What you said resonates a lot. It's not that to be a generalist, you have to sacrifice the technical side of things. That's not what you're doing, I presume.
Smruti: Absolutely. By generalist, I mean more around not having deep domain expertise, while having the ability to still understand technical systems well. The big thing about engineering management at Stripe is we need all managers to have deep functional expertise in whatever they are leading, whether it's breadth, kind of initiatives or depth. So, you can be a generalist, and absolutely can do it without forgoing the technical aspect.
Ramanand: One thing about management is that it's not like you can do an academic degree, and be an engineering manager the next day. It's largely self-taught, it's almost entirely self-taught. Tell me a little bit about how you ease yourself into a role like this? Is there an equivalent of a [00:12:00] practice ground, a lab, a sandbox, where you can make your mistakes and then grow into being in engineering management, but with all the accountability that comes with that? So looking back, what were those practice grounds for you?
Smruti: It's another lovely question. The great thing about... how do you bootstrap before your switch? The thing to consider here is more around creating that environment of setting up the right person for that. Having said that, there is a thing about an engineering pendulum, which Charity Majors talks about. And this is where you then take a step back to say, Okay, what is engineering management these days? The way I think about it is, it is no longer viewed as a promotion of sorts. In an ideal systemic environment where you have both trajectories, the IC track, and the management, switching to management is a change in role essentially. It isn't as much about an uplevel.
There is definitely a little bit of influence and authority associated because you know who makes how much and you're in control of uplevels and promotions. But in regards to making sure that you set up the sandbox, for me, what was useful was having my manager do his own succession planning, which I typically try doing when I'm setting up the next ICs. So what I tend to do, as part of every quarter is sit down with the ICs on my team, each of the folks on the team, as to where are you looking to grow your career into, what are your career aspirations? And then building up the bench, so to speak, to say, who's showing the markers for being a good manager? Now, this becomes very crucial, because the blast radius is slightly bigger to the point about accountability.
What happens when you've made someone a manager, but they're now responsible [00:14:00] for a set of four to five other engineers, and is the 'undo' or roll back, a safe roll back so to speak? So what you want to do is then set up the right person for success there. And in doing so, you then sort of front-load it. And I've seen different companies do it differently. They have a pilot or probation period where they're proxy managing the team, seeing how they go, or there could be slightly lower risk kind of opportunities, where you have a couple of interns, which you could manage for about a quarter to say, how are you giving feedback? How are you growing the person, how are you responsible for project management, and once you've identified the markers on your team about who would like to make that switch, you then set them up through these pivot pilot opportunities to see how they are doing. Once you then evaluate whether they still want to take on a bigger role and actually make the transition. Once they make that decision, we then want to support them through ongoing mentoring and coaching and make sure that they're set up for success.
Having said that, it's not unreasonable to expect them to change their mind. In fact, I'm working with a few ICs, who switched into management and who've now switched back to say, hey, I like writing code all day long, and not as much debugging people, and systems, so to speak. So people do make the switch a lot more these days.
Ramanand: I like the phrase, debugging people, because in some sense, it's almost the same mindset, as is the system that you're trying to figure out the innards of. But one big difference when you go from an IC to a manager is that it's almost like you're separated from direct levers that you can push and pull. And it's almost like learning to be a puppeteer of sorts. How do you debug [00:16:00] systems? Trying to figure out what is going wrong when you can't sit and get your hands dirty? There's a level of indirection that you have to work with.
Smruti: It depends. It's a short answer, right? I lead about seven teams, and each team is in its own state. So [Bruce] Tuckman's got four to five models, which are reforming, storming, norming, performing. And each of my seven teams is in its present its own team maturity. What that translates to is you've got people with individual strengths and areas of improvement, and they get together on some common footing. Hopefully, the common footing is a common vision, which you already set up for the team. Having said that, you want to make sure that each brings what they bring best.
The indirection, I think what becomes most crucial is then identifying depending on the team, and depending on the deliverables, and individual problems, where are individuals at. So one thing I rely very heavily on is my one-on-ones. In my one-on-ones is where I strive to sussing out what are individual problems that folks are going through. This is where reflective listening comes into play. I had an engineer come to me last week. And they're like, hey, Smruti, this project is required to be delivered by summer 2021. And I'm working with this other engineer, and I've given them feedback that they're not performing. And they need to take on these five JIRA items and they're lagging behind. And I'll debug the complexity, which is going to derail this project as well. So a big part of it is then started doing that reflective listening to say, hey, what I'm hearing you say is, and then you start to do the split tracking, which I love, which I picked up from Jill Wetzler, ...there are clearly multiple things going on.
So, identifying what is under the surface, [00:18:00] and then analyzing what is most crucial for the other person to help resolve, and then putting a coaching hat on to say, how do you then identify whether it's a feedback problem that the person has working with others? Or is it a systemic issue around a technical challenge for the design that they have in mind? Or is it more around the constraints that they're optimizing for? Like they brought up the summer 2021 deadline? Is that a constraint which is actually something you want to reinforce? Or last but not the least, additional support through people that you can then provide them with?
Coming back to how do you then debug systems of people? I think it depends a lot upon understanding where each individual is coming from, and then being able to zoom out to see what are the team's deliverables? And what are the big things that the team is accountable for? And then debugging that has its own bad stuff, which we could go into, depending on what the shape of the problem is?
Ramanand: Since you mentioned one-on-ones, I know every manager does that, but different people deal with it in their own style. Is there a tip or is there something that is your go-to way of running one-on-one?
Smruti: For me, again, I think I said it in a previous question, which is it comes back to listening very carefully and doing that reflective listening. I think something which I have had to especially pay extra attention to in 2020 because everything's been Zoom friendly. And there are tons of other notifications popping on Slack and your Gmail and everything, where you like, okay, I'm just tempted to sort of look elsewhere and see what I should respond to. And you know, clearly the camera captures your eye movement, right? So I think one big thing around one-on-ones is being fully present and listening reflectively and while you're doing that, I think being [00:20:00] able to decouple, what is the person trying to tell you and what are they not telling you in terms of behind the scenes and being able to suss that out.
What I found being most effective is sort of saying it back to them, which is like, hey, what I'm hearing you say is... And in that not making assumptions about your own state of mind. There what helps is curiosity. Seek to understand, not be understood, and focusing on that then enables you to drive your own mental model of where the person's coming from.
Ramanand: Incidentally, one of our previous guests is a child psychiatrist. One thing he spoke about was how he's now seeing patients, not in his clinic, but at their homes. He said that it brought a different dimension to his conversations, because what was said and done, seeing people in an environment that was different, that was their environment, taught him a lot of new things about patients that he'd known for a long time.
Things you mentioned about listening, saying things back, paraphrasing, these are all standard tools and tricks that these guys are taught to harness, and makes a huge difference. Are there a bunch of things, we've spoken a little bit about the mindset of a manager, but from a skills point of view, is there something that you wish you knew earlier, or managers everywhere were taught, almost like being a counsellor, being a being a psychologist, a psychiatrist, is this something that you've taught yourself that you wish more people would know about?
Smruti: To me, the things that come to mind, one is growth mindset, which I wish I [00:22:00] myself had picked up earlier. There is a very good book on fixed mindset versus growth mindset, which talks about just your attitude toward how you deal with failure, and consequently, the kinds of risks you take, and you're probably aware of it, so I won't go much into it. But I think where that becomes very crucial is there's this camp of thought around management, which is the 80-20, focus on the 20% of your team and give them 80% of your problems. Just focus on the high performers, so to speak. I saw I like to raise the mean, as well.
That's where a growth mindset comes into play, which is evaluating what is holding someone behind, and then clubbing that with having stretch opportunities identified for each. So I think at the meta-level, I would say, being able to yourself see the power of mind, and then be able to see that in others, and weed that out. That is one big thing I'd call out. And the other bit is this ability to be very clear and precise in giving feedback. Because that is at the heart of growing people then because if you sort of all over the place in what you're trying to communicate in areas you want the other person to grow, or even positive reinforcement, if you want to say hey, good job, right. But that doesn't communicate much. So I would say the second thing I would call and this is another good book by Kim Scott, which is Radical Candor, which talks a lot about how you give that feedback. So those are two things that have held well for me at the meta-level of working with people.
Ramanand: Alright, I read an interview of yours, where you said that you tell a lot of your reports that once I begin managing you, I'm going to manage you for life. How do people respond to that? [00:24:00]
Smruti: They don't think I'm very creepy when I say that. My attitude toward management is more around how I understand each of my reports into what makes them tick. And this is the long-range view toward it. It doesn't matter whether you report to me directly or to one of my teams. What I will be there to support you throughout is no matter whether I have opportunities on my team, ideally I do. But if not, I know you well enough to be able to club you with the right role, whether at a different team in the same company or even outside. There comes the second element, which is advocacy and sponsorship.
What I've noticed over the two decades is folks who have leaps and bounds, jumps in their career, come a lot because folks sponge up a lot and those opportunities are typically not handed out, equitably across everybody on your team. This is where you have this tech thing around the homogeneity of networks. I personally, am a woman, I identify as one, and I've had my fair share where access to opportunities ended up, there being a glass ceiling to it. So the other thing I very actively do for my teams is identifying the stretch opportunities, things which would stretch someone but not break someone, which are catered and in line to their career aspirations. And this is where it is about there's a long term view to how I manage you.
It could sometimes be like, hey, it is just not a fit anymore both ways. In which case, for me, it's like they land well in their next role, and then sort of doing the reference checks and things like that, to support them going out. Over the past teams that I have managed, I have folks reaching out every now and then to see how you're doing, are you still growing? [00:26:00] That's the regular check-ins that I do to make sure folks are on track.
Ramanand: There are some managers who think that over time, they should become less... I mean, it's almost like you look at making your role redundant. That's one view. I've heard from some people where they say that I empower my team to the extent that they really don't need me. But clearly, what you've said so far suggests that a good manager is someone that has a very strong role to play. It's not as if you're there to handhold them every day. That is not what you see your role as. It is pretty much about taking them to that next level whenever they're ready for it, or they have the right opportunities for that. So is that fair to say about your view of management?
Smruti: Yes, and a couple of things, I would add there. Three things that I attribute core to engineering management. One is building, nurturing, fostering high performing teams. Now what does that mean? There's this whole are you hiring the right set of folks? Are you hiring folks with complementary skill sets? Are they diverse enough? And are you setting them up for success? So a lot of this around building teams is not an individual point. This is where managers can make sure they're setting up the teams for success by making sure that every new addition to the team or folks who are leading the team are the right set of individuals coming together to actually form the team.
The second bit is then the engineering itself, which is what are you building? The alignment with your product, alignment with your stakeholders, alignment with the business, in identifying that the complexity of the problems you have and the business value your team needs to deliver [00:28:00] is actually at par with what someone's expecting out of you. Talking about Stripe, specifically, Stripe's scaling so fast that wherever you look, there are tons of fun problems to solve.
So, what becomes super crucial then is to be very laser-focused about solving the right problem at the right time, and making sure the next 18 months actually hold up well. The second key part where I think engineering managers can and should make a difference is in identifying the what, aligning the stakeholders with it, and making sure the team then has the ability to operate, where they are meeting those metrics or the business value. And last but not the least, this is where it's about bridging the gap between teams and upper leadership. It's not just about managing down, but it's managing up and across as well. This is where it's about the 'what' that you're building. What is your feedback loop into providing visibility into what the team is doing?
At Stripe, we do quarterly business reviews. And so making sure as an engineering manager that my teams are well represented at the org level function to make sure that their impact does get recognized. So a lot of that involves advocacy and sponsorship, because when it does come to recognition, engineers love recognition. So how do you start to create the systems to support it? So I would say, taking a step back, and to summarize, it would be these three things where engineering managers can make a difference. The building teams, making sure the engineers are focused on the right problems for a clear vision and last but not least, bridging the gap with stakeholders and leadership.
Ramanand: I have a couple of questions on how managers foster culture but before that, what we usually do in these Smartcasts is to ask you a quiz question. If you get it right, there is something at stake as well. So, gear up for this one. [00:30:00] The good thing is that we are very friendly with hints. We will help you get the answers. We'll do what you do for your teams. This is a management principle but a little bit of tongue in cheek. This management principle states that companies tend to systematically promote incompetent employees to management to get them out of everyone else's way. So, what is this principle called?
Smruti: There's actually a name for it?
Ramanand: The name is something that you've heard of. This is tongue in cheek; I'll give you a hint. This is named after a fictional character.
Smruti: Oh, my gosh. It's a fictional character?
Ramanand: Think of a fictional character in the world of officers and management. That's your hint.
Smruti: Dilbert!
Ramanand: Absolutely. Right. Scott Adams coined the Dilbert principle. He actually had a Wall Street Journal article on this, and it became a book and you can make money coining management principles.
Smruti: That resonates a lot, because for every good manager I've met, I've met at least 10x bad ones. Definitely, the meme is there for a reason.
Ramanand: There is this not so secret fantasy that engineers have or individual contributors sometimes have, where they live in a managerless world. They have all the autonomy in the world, and life couldn't be better. So, tell me why managers are still going to be around for say, the next [00:32:00] decade.
Smruti: I think the managers are basically dreaming about a managerless world. I think you've already lost; you clearly have to improve something about the system. Why managers might be around, one is pure scale. This is about, I don't want to call it like herding cattle, but I think there is an analogy to how do you set up the right set of folks, bring them together to work magic, and make sure you create an environment of trust and safety, where they can work with each other.
And it's a lot about then making sure that the systems around are incentivizing and disincentivizing the right and the wrong behaviour, so to speak. Because what is culture at the end of the day? I'm sure I'm going to attribute it incorrectly, but one of my colleagues talked about culture as the behaviours you reward and punish. And it's not to consider the transactional element about it. But this is a lot around what is the implicit stuff that you were allowing to happen, or not disempowering, so to speak. That is where engineering managers can and should play a very important role.
I for one see it as a craft in many ways, which is about the responsibility in creating those systemic environments, which allow every individual to succeed and make the most of what they have to offer. What even is the point of getting these talented people whom you interview for eight hours and put them through a creative process, when you're just going to get them in the door and have them screw up their lives. If left to their own devices, what is then important, especially as you scale, and you might not need your first engineering manager until your org size is four [00:34:00] or even 40.
But when you start looking at, say, 400, imagine a set of 400 engineers left to their own beautiful devices, what do you think you're going to get? And that is where engineering managers can make a difference. Having said that, I will preface that to say, not all do a good job of it. There are many of us who are stumbling and who would with the right support can do a lot better. But that requires analyzing what engineering managers can uniquely do. And it is around some of the things that I have already talked about, which is building and hiring teams, creating the environments where folks can work on the right set of problems, and then bridging gaps across your stakeholders in the business.
Ramanand: It almost sounds like you know, being a conductor of an orchestra in some sense, right? You have a lot of talented musicians but get them to be in tune, it does take someone with the baton.
Smruti: That's a beautiful analogy. I love it. I'm going to use it.
Ramanand: Thanks. Since I've heard a little bit about how companies like Stripe and Amazon, you guys are taking a writing led approach to communication, and that's what we've heard, where, unlike older companies, it's about putting things down on paper, giving yourself the time to think through problems. And that's something that resonates a lot with us, at Choose to Thinq, though, we're definitely much smaller. We've been remote-first from day one, and we love writing. So we take our time. Tell me a little bit about what you see are the advantages and also the disadvantages? Does it slow you down? Is there impatience among some people when it comes to writing culture, so tell me a little bit about that.
Smruti: This [00:36:00] year, especially, has been uniquely different for all of tech, for the entire world, so to speak. And one thing many companies have had to scramble to do was to suddenly change their working norms, from a physical first to a remote location. Stripe actually, it was a tad bit easier in that sense, because as you alluded to, we are a very written heavy culture. That is one thing I personally love about Stripe, everything is about first principle. I think a lot of my own management principles were better baked in thought and communication, because I was like, okay, why are some of these things working as they do? And so being able to write some of that down provides that clarity in thought.
What it also then enables is better remote communication and collaboration. So I think some of the obvious advantages are that you can tap into a skill set, which is now global, because you no longer required to hire either from San Francisco or London, or Tokyo or wherever else, and you can tap into a global workforce, which is a huge benefit, if you actually can streamline some of that communication, collaboration, make it happen there. Having considered that, obviously, different time zones and all add some more challenges.
But keeping that aside, I think, coming back to the beauty of written communication, what it also front-loads is, as we write, we clear a lot of our own thinking. And there are personalities where they think as they speak, which is me. And there are personalities, which think, and then they speak, and what often happens in discussions is if these two personalities meet, one or both are left frustrated at the end of such discussions. And I think what written-first kind of culture then enables is for such individuals to think through their thoughts before they need to, then [00:38:00] say now let's get together to discuss some of the aspects. So that I would say it, it actually frontloads, some of the back and forth and the discussion and the debate. And, in fact, even promotes agility. Some of the downsides that come to mind are more around the dual part of the same coin, which is that as you're tapping into a global workforce, English may not be the first written language.
Having said that, written comms obviously favoured those who got a leg up, so to speak, in terms of their writing. I have seen a few engineers struggle in terms of putting their thoughts down onto paper, and then struggle with okay, am I good enough and an imposter syndrome around that. That is something as engineering managers you want to look out for to make sure someone who's got the potential, who's got the talent, who's got the thoughts still can communicate effectively even in a written-first culture.
Ramanand: Since we're talking about writing, I also wanted to know, these days, because organizations are so heavily networked, especially when they're distributed and then you also have an external site to one's network now. Traditionally engineers have thought to be a little... they pooh-pooh the idea of personal branding or having a spotlight shone on you. But when you do your advocacy for engineers to give them their due, what is it that people should do for themselves, in terms of promoting themselves without it being seen as a bad word?
Smruti: That's a very good question. In fact, this is one of the things I would tell my younger self, and now I have to very consciously make the time for is the personal brand. [00:40;00] What does it mean, as times have evolved? To me personally, it's a lot about how you can do that self-advocacy that we talked about? At Stripe, we had Julia Evans, who created this brag doc template, which is, how do you promote your own work? And why is that important? I think the ‘why’ behind it is something which is useful to identify.
So I would say at the personal level, having engineers focus on personal brand, and what that means to you, what means to them, is a factor of tapping into how each likes to be rewarded and recognized, and each of us have our own individual preferences, right. And being able to then translate... I need recognition from my peers, or it could be in terms of, hey, I need the CEO of the company to call me out, goes a long way in also for letting me as a manager know, these are opportunities I should look forward to, to be able to recognize the impact. That's where some of the personal introspection into what are ways I want to be recognized goes into some of the personal branding. For some, it is about... I've worked with one of the engineers, which was about, hey, I need to improve my writing, because at Stripe you need to write to be successful. I also want to publish something out there. We worked on a very concrete plan to say, okay, what are the two technical blogs you're going to release either as part of Stripe or through others?
So, your self-advocacy can come not just in terms of the impact you've had, but also in terms of your knowledge, your experiences, and through conference talks, or through technical publications. If you zoom out a little bit, I also think about what does the branding for your team look like? In terms of that, the way I think about it is what is the face of your team, so to speak. Stripe is also very heavy into metrics. Each team has its own charter and vision statement and mission statement. You have [00:42:00] the metric which defines how you move the needle for the company. Being able to then stitch that narrative or story around this is where it was, like for example, my latency performance team owns Stripe wide, the P999 latency metric, and being able to say, here's where it was, here are the five things that team did. And this is how it dropped. This is the impact it had on customers. It is a very compelling story.
At that point, if I were to then sit in an upleveling cycle and say, hey, remember, engineer x moved this metric this way, automatically tells the brand there. I think about it, as you know, individual branding, which starts with identifying what individuals want to be recognized for, and then zooming out into what the team branding looks like, in terms of what are the metrics they want to be recognized for. So I think it's a factor of both.
Ramanand: That's quite fascinating because in some sense, engineers have got to be aware of something called as the brand. Not a lot of people speak that language. That vocabulary isn't something that comes naturally or you have exposure to. So what I'm taking away is that here is a way for people to understand not just what they do helps their team, their company, but also to be able to articulate that and be able to tell that story with the help of data and anecdotes, whatever it be. But I think the awareness and that vocabulary is quite fascinating because I don't think a lot of companies and teams speak that language.
Smruti: That is something I've learned. In fact, I ran this FAS, which was Feedback as a Service at Stripe because I was like, hey, I want to let engineers know how to talk about the impact of the work they had. So at Stripe, the performance evaluation happens every semester, every six months. Then engineers write their self evals, we have peer evals, we have manager evals, and then we do calibration where managers sit together and look through all the 1200 engineers, [00:44:00] and it happens in multiple weeks.
The one thing that is common, which keeps coming up in these questions is what is the impact they drove? Quite often what I've seen engineers do is they're just so myopic, and obviously, well-intentioned, but they spend so much time thinking about a problem is like, what did I solve? You talk about the technology; you talk about the problem you solve? But if you zoom out, what is the story it's telling? What does the before and after look like as a result of that work, becomes super crucial in being able to articulate the impact. Why did you even do this? And I think that goes a long way into a longer-term career trajectory about where do I want to now head into, given the scope and influence that I want to lead over the years to come?
Ramanand: Do you think that's where also the writing culture helps because now you're not in that mode, where after six months, you're wondering, what is it that I did, and you can only remember what you did in the last one week?
Smruti: Exactly. That is where what I also like to do for all my reports is through one on ones, we get a personal charter or a brag doc going to say, what have you shipped, because many times engineers are also helping other cross-company initiatives, and having a good changelog of that enables your half-year evaluation to say, hey, you remember, you got that feedback from engineer expert helping them out? Let's add that to the package. So you're aware of the recognition. It's a moment to celebrate some of the small wins, which you forget about.
What it also then helps you is, you're more intentional into where you want to be. So you're not looking back a year down, like what was this year of my life? All of us are here for probably a 40-year career. Hopefully, some of us can retire way sooner. But if you can't or if you just don't enjoy it, you still want to be able to see, where am I going? Am I going in the [00:46:00] right direction? What's your North Star? So the written culture adds up to it. Being intentional about it helps. But being able to articulate it is like the cherry on top of the cake.
Ramanand: We have about eight minutes left. So, I want to shift the spotlight on you away from your team. You spoke about a few books, you spoke about Radical Candor, you spoke about a few frameworks. Tell me a little bit about what I call the curiosity diet, right? What are you reading these days? What are you listening to these days? And more importantly, who gave you the time to do all this?
Smruti: That's a very good question. I'll be very honest. Over the last few weeks, I'm not reading or listening to anything other than stuff around the Big Data Platform, because it's a new org I have taken up and as a generalist, this is a new area for me to learn. So all my reading is about this domain and knowing what the best in class is doing. It is not related to management, but more about picking up my functional expertise, and that I've taken up a couple of courses online. But other than that, I think what you touched upon is, how do I make the time for it?
I have two boys, five and two, and in the pandemic, they've been absolutely nuts, as much as I love them. So making that time is very hard. It needs to be a very conscious decision. I for one, do the same exercise that I do for folks on my team, which is what does my one year look like? Every October, November, I sit down and see what my next 12 months will be like. Imagine it's November 2021. What do I want to be true in Smruti's life? It's a holistic view, not just about work, but also my hobbies, my growth, I haven't identified that. What I then do is break it up into roughly quarter over quarter. [00:48:00]
I have a very aggressive spreadsheet where I list out week over week, and I do like this month, here are the big things I want to accomplish. Then I do a review at the end of the month before the next one comes up. And every three months, I'm like okay, am I trending to my annual goals? So the reason I say all this is, as a manager, it's very easy to lose track of your time. For instance, today, I started the day talking to legal about immigration from Russia. I talked to a candidate from Russia who wants to move to London. I presented at the company all-hands about latency. And talking to you hoping we get more engineering managers interested in this realm and a bunch of other stuff as well. It's very easy to start to lose track of time.
So what I do is I calendar defrag very actively, use color codes and all that, which are then columnised based on what are the areas or buckets that I want to grow in. And every Wednesday, thanks to Stripe having a no meeting day, I focus on about two to three hours of just learning something new. LeadDev is this recent online platform, which has got tons of really good, very practical content that has started this year, which I absolutely love, and there's so much good stuff to learn there.
Ramanand: It sounds like you've turned your managerial acumen to your own life and in a sense, so it's good to hear you walk the talk, right? It's not just for someone else.
Smruti: Oh, yes. And then you learn from it because you know what works and what doesn't, right? I started with having a Kanban board of like, Okay, this is what I want my week to... and pretty soon I'm like, hey, this isn't working. Am I trending in the right direction? I realized, okay, a five-year career is way too long to think about in today's day and age. So let me start with what 12 months look like? So I think walking the talk also helps correct your own patterns and practices and then hopefully others learn from your mistakes. [00:50:00]
Ramanand: For someone who's interested in learning a few of these mental models, these ideas, what are your top three books that you usually recommend to people?
Smruti: Top three books that come to mind, Lara Hogan's Resilient Management has got very practical tips around team bonding, team forming, how to do one on ones, a lot of good content in that. So I would recommend Lara Hogan's Resilient Management for that. I spoke about Kim Scott's Radical Candor because for a successful engineering manager, you really have got to nail down how you give feedback and keep reinforcing the good stuff, while calling out areas of improvement. The third bit around the meta-level stuff around what you're building, how to track it, I like Dr. Nicole Forsgren's Accelerate, which is a metric-centric approach. And I think especially, you alluded to it earlier, when you said, engineers don't quite enjoy the concept of metrics. It makes it seem very accountant focused view. But I think this book captures very well what systemic things have to happen, and how metrics can actually enable your decision making, your prioritization and in fact, even the impact of what you are delivering. I would call out those three as the top three that come to mind.
Ramanand: That's a good place to start. The last couple of questions, looking ahead, what are the top new kinds of trends? It could be technology trends, it could be management trends, what do you have your eye out on for?
Smruti: I think for me, the biggest thing looking at 2021 and beyond is being evaluated as a lot of remote success, or not, or productivity wins with the lens of working in a pandemic. I think the tune needn't be conflated. So to me, one thing that I'm actively looking for is what are longer-term, sustainable [00:52:00] and systematic changes to working remotely. Consequently, what are the implications of Zoom, or things like that, to enable team collaboration, team communication, and just personal health.
For me, a lot of how all of this lands in a normal world is going to be key to how we actually generalize to is tech working in a healthy sustainable way, even post-pandemic, because we're not in normal times. It's been a long stretch, and it is going to be a long stretch into 2021. But it is not going to be the norm. And then having engineering practices, which are more dedicated towards the norm than the exception is something that I'm watching out for to see what the downstream implications might be, or good lessons to learn.
Ramanand: Before I ask my final question, I did mention that there was something at stake with the quiz question. We run a couple of groups around daily reading and spotting the future. So we'll give you one slot for that, that you can give to someone, you can use it for yourself, or you can give it to someone as well. So that's your prize for getting the Dilbert principle right.
Smruti: Thank you Ramanand, that was a surprise.
Ramanand: That's our pleasure. Last question is, 2020, as you said, year of change, disruption, all that. What is one thing that stayed the same that you look back and say, wow, I know, that stayed exactly the same. Everybody's talking about change, but surely something that stayed just the same?
Smruti: I think it's resilience. It comes down to who we are as people. And what makes us tick, and I think then focusing on people consequently. Because technology will pass, the norms, the practices, [00:54:00] the working styles pass, but I think what stays constant is people being flexible, adaptable, resilient, and knowing that we've got more and that's why I love Obama's Audacity of Hope. Because it talks about our inherent spirit to get through this and do what needs to be done.
Ramanand: On that wise and optimistic note, Smruti Patel, thank you so much for an hour with us. We learnt a lot. We'll catch you soon. Thank you.
Smruti: Thank you so much for the opportunity, take care and good luck and hoping more engineering managers decide to take up this craft. It's a very fulfilling and rewarding career for sure.
Ramanand: I'm sure they will. Thank you so much Smruti.
If you want to get into the habit of reading, or explore diverse topics that you wouldn't have read otherwise, CTQ compounds is for you. Compounds are expertly curated by us and are a great way to slip in 15 minutes of reading nonfiction every day. The FutureStack compound is perfect for anyone with their eye on the future. It gives you a regular dose of relevant info to keep you current and relevant in the future to come. For how you can be a part of a compound, go to ctqcompounds.com. You can also see what our compound members have to say about their experience there. That's ctqcompounds.com.