We want to make the Dev Interrupted podcast a vital, enjoyable part of your week. Please take 2 minutes and answer our new Listener Survey. It lets us know a bit about you, what you want from Dev Interrupted and what you want from podcasts in general!
If you looked up the term “firing on all cylinders” in the dictionary, I’m fairly confident there would be a picture of Sarvenaz Myslicki next to it.
A next-gen leader who earned the role of VP of Technology at American Express by the age of 30, Savernaz is a published author, an in-demand thought-leader on mentorship and has one of the largest followings on programmer TikTok.
Our favorite thing about Sarvenaz, though, is that all her work is aspirational but radically inclusive. She tailors her message, content and guidance based on wherever someone is in their professional journey – even if they’re just tinkering with code in a junior high classroom.
Sarvenaz joined us and 1700 other engineering leaders for an incredible live conversation at our INTERACT conference about the real trial and errors that have led to her role at Amex, as well as the beliefs, mindset and rituals that have allowed her to become a mentor for developers she’s never met.
We hope you enjoy this discussion as much as we did.
Episode Highlights Include:
- (4:30) Sarvenaz's team at AMEX
- (14:46) How to launch yourself from junior dev to senior dev
- (18:18) Why she never commits to an aggressive deadline
- (22:54) Personal productivity & habits
- (45:20) TikTok & mentorship, an unexpected perfect pairing
- (50:00) Maintaining success without making enemies
- (51:13) Contributing good ideas when you’re shy by nature
Episode Transcript (disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Dan Lines: Host
Sarvenaz Myslicki: VP of Technology at American Express
---
Dan: [01:08-01:17] Sarvenaz we're stoked to have you at Interact and on the Dev Interrupted podcast for this conversation. Thank you so much for joining.
Sarvenaz: [01:17-01:19] Thanks for the invite. I'm really excited.
Dan: [01:20-01:40] Yeah, you've had such a stellar career. You are now the VP of technology at American Express; very impressive! One of my favorite ways to better get to know our guests is to ask them how they got where they are today. Could you kinda walk us through who you are and your career path?
Sarvenaz: [01:40-03:21] Definitely. So, after graduating from the University of Florida, go Gators, in 2013 with a degree in computer science, I went into a rotational leadership program at a company called Nielsen, and it really appealed to me because one of its main purposes was to expedite your career growth, as a leader. It was pretty unheard of to get a senior level role at that company after two years but that's exactly what happened if you made it through the program. So, after the program, I moved into technical project and program management and then pursued my first people management role as a director of R&D. So suddenly I'm leading engineers with decades of specialized expertise and it actually pushed me to start a part-time master’s in computer science to make sure I kept honing my own technical skills. Then in 2018, an old connection that I made during an internship with American Express reached out and she's one of those leaders that you just dream of working for so I was sold pretty easily and I took a director role there focused on tech modernization. And then after about a year and a half, I applied for a VP role leading our credit and collection systems, coincidentally right before the start of the pandemic. So, [crosstalk 03:00] leading that team at a time when millions of people needed credit was definitely intense. Yeah, and so my current role I took in July and in this role, I lead organizations responsible for our member web experiences on americanexpress.com, loyalty experiences, enterprise services and site reliability engineering.
Dan: [03:00] Perfect
Dan: [03:22-03:28] Wow. That-that's awesome. You got your-you have the PhD in comp sci-computer science?
Sarvenaz: [03:29-03:31] Just Master’s, [crosstalk 03:30] I wish to get a PhD. One day.
Dan: [03:30-03:34] Master’s okay. Yeah Master’s. What-what kind of things did you do in that program?
Sarvenaz: [03:35-03:54] Oh man. Well-so, it was a part-time online master’s from Georgia tech. So, it had the flexibility I needed and the professors were like top tier. In fact, it's a top five comp sci program in the world. And I just learned things that really filled a lot of gaps from my undergrad.
Dan: [03:55-04:04] Yeah. That's awesome. And then you said you-you did like a rotational program, right? You get-what-can you give more detail on that? Like what did you do in that rotation program?
Sarvenaz: [04:04-04:29] Yeah, it was really cool. So over two years we did four different six-month rotations. And one of them was really technical. Two of them were more around leading teams, more like project management, and then one of them was as a client service partner. So, they took us completely out of engineering, showed us what it's like to deal with the customer to be kind of customer facing. And that was really, really helpful as well.
Dan: [04:30-04:39] So, yeah, I mean, obviously a-a meteoric rise. I think you have, maybe you're leading a team of about three-fifty plus, how many people are on your team today?
Sarvenaz: [04:40-04:47] Yeah, it's-it's roughly around there. We are growing fast, so we-we have probably like thirty or more open roles. It's a big team.
Dan: [04:48-04:56] So in your mind, what are the most important characteristics of an engineering leader or a great engineering leader?
Sarvenaz: [04:57-06:59] Hmm. Okay. I-I'll tackle this question from a leader of leaders perspective because the answer's a little different than just directly leading engineers. So, the first one is empathy for each other, for partners, for customers. I always try to make sure that the team and I are regularly experiencing other people's pain points. So, we'll do things like temporary job swaps, learning about a day in the life, and-and reviewing customer feedback about our products really regularly. The next one is approachability. I try to make a culture where anyone can message me anything, an idea, a complaint, I actually-when I get complaints, I'm very grateful for them, or just to say hello to me. I really learn a lot about our engineers this way and the state of our organization. And finally, this might be a unique one that you haven't heard, but I don't believe that a good leader asks for special treatment and what I mean by that is a common practice I see in le-in senior leaders is that they have these custom ceremonies, like biweekly progress meetings or business updates, and they're meant to make it easier for them to digest information. And I was on the side of preparing for these ceremonies for a large part of my career. And I learned two things in that-in that process is that one, the ceremonies take away from the leader's approachability. It sends the message that unless your message is formal and polished, don't share it with them. And two, they-the ceremonies almost imply that the leader's time is more important than the team's time, because so much time goes into them. And it's not even always that value-add time you're looking for, so that's why on my team, I have a no PowerPoint rule, a no custom ceremonies just for my sake rule, and I try to convey that everyone's time is equally important, and that documentation should exist for the benefit of the team and not just me.
Dan: [07:00-07:31] Yeah. I mean, I've been a part of those kinds of meetings too, you know, on, on both sides of it. When you're the one that's preparing for the meeting, sometimes it takes, you know, hours of preparation to do like a good thirty minutes or something like that. And then when you're, when you're on the other side of it, as-as a leader, it can feel, you know, I think it can feel nice because you get all this information in like a condensed period of time, but maybe you're wasting the time of the people reporting to you. How do you get the information that you need kind of without those formal updates?
Sarvenaz: [07:33-07:53] Well, that's where having the information available for the team comes in. So, if I can't find it, but I want to know about it, I feel like other people do too. So yes, I might ask people to make a place where that information is hosted. But it's publicly available to the team and it might not be just presented to me once and then lost forever.
Dan: [07:53-08:02] Yeah. Okay, cool. What do you, think's the number one soft skill that either you're great at, or you think that, you know, a great leader needs?
Sarvenaz: [08:03-08:31] Well, not already perfect at, but continuously trying to improve is just communication because it's the base skill for so many purposes: negotiation, having difficult conversations, marketing yourself, sharing goals with your teams, talking about technical topics, the list goes on. So, one of the best things I did in my career, and I'd recommend to everyone, is to get involved in Toastmasters, a public speaking organization, or anything along those lines.
Dan: [08:32-08:44] Yeah, that's awesome. I had a buddy do, uh, Toastmasters. It's like a-is it a once-a-week thing or once-a-month, you're kind of giving a speech or like doing some public-What goes on at Toastmaster?
Sarvenaz: [08:45-09:12] Oh, yeah, they have different phases. They have impromptu speaking, which is probably hardest when you're up in front of the room, getting a brand-new topic on the fly, and then they have a different part of their meeting where you come in with a prepared meeting, uh, sorry-you come in with a prepared presentation and people will give you feedback in real time. So, they will count your filler words, they will tell you your run on sentences, they will tell you if you could have structured it better. That real time feedback is really helpful.
Dan: [09:13-09:26] Yeah, really cool. I always like to give, you know, like concrete tips to people that are listening. So, Toastmaster sounds like a great avenue to improve communication style skills. What about on the, the hard skills side? How do you think about that?
Sarvenaz: [09:27-10:00] Oh, yeah. Well, the relevant and valuable hard skills are always changing, especially in tech. So, the short answer is always be learning, but a less obvious tip is to really become an expert only in the most problematic and the most relevant parts of your system. I see technical leaders. They fall into two common traps. They either stay too high level and rely on the expertise of their engineers, or they try to understand the details of the entire system and every possible technology, and it just takes too much of their time.
Dan: [10:00-10:32] Right. I mean, I, that's actually I think a really hard one, because I can even think back to myself, it's like, I don't want to be too high level, but then when I start diving into something, I have this engineering background so now I'm in the details and I have to know every single thing. Staying in that balance to know, like, do you have any tips to know if you're going too far or you're too high level? Is it a feeling, because I, I really like this piece of advice, how-how do you, how do you stay in that perfect balance?
Sarvenaz: [10:33-11:16] Well, it won't feel like a perfect balance, but usually it's like, what is the most important project going on right now? Or what is that one part of the system where one person is the only one who knows, or there's the most, most things that will probably go wrong with this project? That's the one. That's the one for you. And you have to be okay with not knowing some obvious things about the rest of your system. And this is the hard part. So, I-I do sometimes feel like, you know, if someone asks me this obvious question about a, a part of our system, that's running really well, I'm gonna look like I know nothing about the team because I'm only focused on the really critical or really on fire or really important strategic parts.
Dan: [11:17-11:55] Right. Yeah. I-I'm talking with engineering leaders, like, all the time, you know, at-at LinearB. And one of the things that we do with LinearB is provide some visibility and data and you can kind of see different bottlenecks within the system. And what they say is, “Oh, now that I can see where the bottlenecks are. Cause it's so hard to tell, like where should I focus my time? Then I decide to kind of dive in there because that's-that's the part of the system that has the most leverage for gain.” Are you use-like, how do you-how do you determine where you want to dive in? Are you, do you have any data stuff going on or like, what do you do?
Sarvenaz: [11:56-12:26] Well, we do have these predefined enterprise initiatives that it-it's easy to know, like focus on these for sure. And then part of what you said that really resonates is sometimes your next step has to be, how do I find out this information? A lot of times we have goal setting practices where we don't even know the baseline data. So how do we know how much we want to improve? Yeah, it-it's a good first step. Can we get the baseline of what's important first and then focus on what's important?
Dan: [12:27-12:37] Yeah. Very cool. During your time growing as an engineering leader, what are some of the experiences that have taught you the most.
Sarvenaz: [12:38-13:29] Ooh. Yeah. Well, I think most of us naturally look to learn from our leaders, but one thing I've come to appreciate is just how much you can learn from the people you lead. I'll never forget my first time as a manager, I felt so worried that everyone knew more than I did. And I expressed this to one of my mentors. So, she gave me really great advice because she had gone through the same thing. In fact, she knew that her new team was grumbling about her lack of experience behind her back. So in her first meeting, she called it out head on and said, “I know you all have experience and knowledge that I don’t. My goal is to help each and every one of you succeed, but I can't do that unless you teach me what you know.” And that's, what's so great about servant leadership is you're not there because you know the most, you're there because you're committed to helping the team succeed.
Dan: [13:30-14:00] That's actually a really tough situation to be in. If you know, like, oh, your team's like saying about you like hit-hitting it head-on really makes sense. I think I, you know, I-I totally feel the same way when I'm thinking about leadership. I'm saying to myself “Okay. I want people on my team that definitely know way more than me in whether-whatever area that they're working in. How do I make them 10X better? Or how do I, how do I help make them a 100X better?” Do you think that's kind of the right mindset?
Sarvenaz: [14:01-14:12] Oh, yeah. Not only how do you make them 10X better, but how can they make you 10X better? And how can you not feel bad about anyone else being better in the process?
Dan: [14:13-14:26] Yeah. Is there a particular success that you've had as an engineering leader that sticks out to you as something that you're proud of or like some game changing success?
Sarvenaz: [14:28-15:44] Well, I don't know about single moment of game changing success, but actually my favorite successes as an engineering leader are helping others achieve success in their own careers. I think it's really important to let people be ambitious and help them find ways to fuel their growth. So, sometimes I'll have these one on ones with engineers, and I notice a hesitation to share their ambitions. A junior engineer will say something like “I'd love to be a senior engineer… someday, like maybe in a couple years.” And what they're really thinking is “I'm ready to be a senior engineer now.” or-or “I do senior engineering work now” you know? So, when I hear those hesitations, I always like to ask “Why not now? What's holding you back?” Showing them it's okay if they want to be ambitious and go faster. And I also like to create a culture that promotes learning skills at the next level. For example, it was common for our senior engineers to present at design reviews and for junior engineers to listen in. But I changed that around. So, the expectation was that junior engineers have to be the presenters and senior engineers have to coach and prepare them. And then this way, juniors get to practice senior level presentation skills. And seniors get to practice developing and coaching others.
Dan: [15:45-16:05] Oh, that's really cool. I like that. When you're in those one on one conversations with an engineer and you feel like there's some resistance or holding back, you-you said-you said something like, you know, why not now for a senior engineer. What happens in the kind of like-when you do that? What-what response do you get?
Sarvenaz: [16:06-16:43] Yeah. Sometimes they'll look at me and they'll-it's almost like they're saying, “Am-am I allowed? Like, am I allowed to now tell you that I-I think I'm ready faster?” And I'll give them an example. I'll say like, you know, don't let an arbitrary amount of time in the role, be your guide. If you look at the next level role, and you're doing that now, let's get you an exception. Let's put you in that position. But you know, that-that's the biggest message. I feel like people go at a different pace and we sometimes try to put that into a-a standard timeline.
Dan: [16:44-17:13] Yeah, yeah. That-that makes sense. So, they're kind of like, yeah, I-I have to be, I don't know, a junior for three years. Well, you kind of broke-actually broke out of this. How many years at, you know, I don't know that your timeline was necessarily normal, right? So, you probably have the best advice of how to accelerate your timeline. Like what do you do for yourself to say, you know, I don't have to do something for five years before I become a senior whatever.
Sarvenaz: [17:14-17:48] And, and that's why I try to convey it to these people is that you look at what you're working on. I-there was one promotion I got, I think, faster than-it was a title change within a couple months of taking a role. And all I had to do was show that my day-to-day work for the past three months have been the exact same as the day-to-day work at the next level. And at-at some point you just, you show them that you-you need to be retitled. It's not even a-you know, a promotion or a change. You're just, that's the work you're doing.
Dan: [17:49-18:26] Yeah. Stick up for yourself, visualize it. Good things will happen. You know, at-at Dev Interrupted we're-we, you know, have the, I don't know, great ability or we're just getting these amazing guests that have all of these successes, like yourself, over and over again. But one thing that we always like to ask is about failures. So, in your career, what has been like your biggest failure or, you know, something that didn't go so well for you?
Sarvenaz: [18:27-20:20] Oh, yeah. Well, I'm, first of all, glad that you're focusing on both sides of the story. So, I-I once led a project where I was more or less duped into believing, maybe I was too gullible that we had to meet an aggressive timeline and I was new to the team and I let my own fear of failure and my need and desire to impress everyone lead me to put a lot of pressure on the team and it really burned a lot of them out in the process. And what makes it worse, we actually did deliver on time, which surprised a lot of people. And then we found out our operations teams weren't ready or planning to use the new feature for several weeks. So, after that I promised I'd never again commit to an aggressive deadline, unless one, every single one of our partners was ready to commit. And two, there was a tangible customer-company impact. Now, one example of putting this lesson to use, I was on a team that had a lot of work tied to legal and compliance requirements. These were really hard for the team to push back on because of course, regulatory deadlines can't, you know-they're not flexible and there's a tangible impact to the company. However, there was simply too much work for the team. So, I knew we'd have to prioritize at some point and to better understand the implications. I asked for an actual copy of the regulations that were driving the requirements. And I must have read over fifty pages of legalese to really understand it better. And what I discovered is that only a subset of our features were actually mandatory, absolutely mandatory, you know, and there had been some scope creep internally along the way. So, our backlog became much more manageable. The team realized it's okay to push back, they just might need to do a little extra research in the process.
Dan: [20:21-20:58] Yeah, I've seen like, talking to leaders or managers over and over again, it seems like whenever there's kind of this overly aggressive deadline, it's pretty rare that the-it's a positive experience for-for everyone. Everything has to line up perfectly to be a positive experience, but usually it's more, like, what you're saying with a failure. If-if you're an engineering leader and you're getting kind of these aggressive deadlines thrown at you over and over again, what do you think you should do in that situation?
Sarvenaz: [20:59-21:47] Yeah. I think one of the biggest things that a leader needs to do is be the protector of their team. Even if it comes at their own expense reputationally, but they can protect themselves and their teams with-with data, you know, like this is our capacity. This is the impact of overburdening and pushing our engineers too much. It might be attrition. It might be burnout. It might be quality. And then really pushing on the notion of prioritization and-and reducing scope. And knowing that there's something that might drive higher value and that should come first, but they can't all be number one priorities, which, which we have a joke on because we always have-we have a prioritized list and there'll be like five or six number ones on there.
Dan: [21:47-22:56] Yeah, yeah. Data seems to always kind of, I-I don't want to say win arguments, but it's something that can convey or bring everyone together. If you're talking to your CEO saying, “Hey, let's just first start with the data so we're all on the same page of where we're at. This is how fast we're moving. Here's maybe some issues that we've had, you know, in prod with our MTTR. Here's our cycle time. Here's our project predictability to date. And now, you know, you're asking my team to do this other thing, let’s say. Here's how I expect the data to now look, if you want to take on this, you know, challenge.” And I think a lot of the times the person on the other side says, “Oh, like, I-I don't know. I didn't know about this data. Like thank you for showing me this. Like, let's make a better decision together.” So, it's kind of like this unifying thing. You know, the theme of Interact 2.0 is developer productivity. You know, that's really what we're focusing on a lot here. And we're gonna talk about that, but how do you personally stay productive?
Sarvenaz: [22:57-23:54] Hmm. Okay. There's, there's three things that work for me best. It-it's energy management, habits, and reflection. So, I'm-I'm a big believer in energy management over time management. If I'm excited about a project and it brings me energy, I'm gonna work on that until I'm dead tired instead of trying to spread it out over time. Then when my energy fails me, I make sure I have the right habits backing me up. I'm a huge fan of James Clear and his book Atomic Habits, where he talks about building systems that make it easy to maintain good habits. And then one of my habits is making time to think and reflect. Every week I write down my top work accomplishments and every day I write down one positive outcome and one lesson learned, and without this reflection, you could honestly go weeks thinking you're super productive and being super busy and not be focusing on whether any of it is having an impact.
Dan: [23:55-24:31] Yeah, I'm seeing there's a trend now, as I'm talking to leaders around, I guess, reflection, and I'll add into their intention. So, one of the things that I-I'm doing, actually, I-I started on the kind of reflection as I'm hearing more and more people are doing that weekly. And then every, like, Monday or-or Sunday night what I'm saying to myself is “Okay, I did my-my reflection. What's my intention? What does good productivity look like this week or over the next two weeks?” And that has been helping a lot. Why do you think-
Sarvenaz: [24:32-24:35] I'm gonna steal that one! Reflection and intention.
Dan: [24:34-24:44] Yeah. You can steal-you can steal that one, but I was gonna, yeah, I was gonna ask you, like, why do you think there's like a trend on reflection right now and a lot of people are-are doing that?
Sarvenaz: [24:45-25:18] Well, probably because it helps a lot, but-but more so because we're being taken further and further from internal reflecting in general. I mean, everyone's saying it right? We're being bombarded with information all the time. We don't even want-we don't even allow ourselves moments of micro-boredom, so to speak, like you're in line, you're on your phone, you're waiting for something to happen, you're on your phone. And just reflecting on your own is really helpful in that whole incoming flow of information.
Dan: [25:19-25:51] Yeah. I mean, like at-in the remote world, the async world you're getting met, like we're on this, you know, live pod right now, I'm probably getting fifty messages on Slack. Do this, do the, or I need you, or what do you think of this? Right? It almost feels bad to have a reflection time or to allow yourself to like think more strateg-strategically and like not be available, but good tip to any leader, but engineering leaders. Take the time to do that, right? It will actually pay more dividends.
Sarvenaz: [25:52-25:53] Thinking hard is working hard.
Dan: [25:55-26:29] So, it's great that we got to learn, you know, a little bit about you. Talk about your journey. Let's talk a little bit and take a step back for a moment and talk about Amex. So, the team you lead is responsible, hopefully I get this right, global web engineering, so americanexpress.com, loyalty, SRE, and enterprise services. So, it's a lot of stuff going on there. What's your approach to ensuring these critical services stay active?
Sarvenaz: [26:30- 27:18] Oh yeah. Very important topic. I feel like I need to pass some of the initial credit to my team for this one because when I joined the team, things were already in amazing shape. And when I was learning about our services and how we assu-ensure availability and resiliency, I was really impressed with what was going on. So, based on that, my approach for continuous improvement has been to look at the systems that impact us, but are outside our direct control. First identifying which ones contribute to the most impacts for us. And our customers and then working with their product and engineering leaders to get them prioritized. And usually that's the hardest part so I try to sweeten the deal by offering, to have some of our team support the change and spare them a little extra capacity.
Dan: [27:20-27:32] Yeah. You're-are you utilizing SRE practices? Like you have-you have an SRE team? Are you doing like the standard Google SRE style stuff or, yeah?
Sarvenaz: [27:33-27:43] Well, we-we actually implement a lot of those practices, but I wouldn't say it's identical to any other SRE style. It's probably an Amex SRE style.
Dan: [27:43-27:56] Amex SRE. Okay, cool. When something does go-go wrong and that's, you know, I have SRE on my mind, when some something goes wrong, how do you approach recovery?
Sarvenaz: [27:58-28:51] Well luckily, we have a lot of observability tools built into our systems, plus an enterprise logging framework that makes diagnosing issues a lot more straightforward than some of the older systems I've owned in my career. And we're also really strict about disaster recovery exercises. So, at any point in time, we'll have done a good dry run within the past couple of months. And then tooling and preparations aside, we always try to take the blame out of the issue management process and keep an enterprise mindset when it comes to recovery. And my team makes me really proud in this respect because I've seen countless examples where they will stay on an issue resolution call even after they've confirmed that the issue is not with us, because they don't see it as, “Okay. We're done with our job.” They want to make sure that they can support the overall resolution for our customers.
Dan: [28:52-28:59] Yeah. That's a, that's interesting. How do you think you got to that type of culture? Cause that's a-that's not a culture that every team has, I don't, I don't think.
Sarvenaz: [28:59-29:30] Yeah. Oh, it's true. It's-it's absolutely true. And this is-this kind of goes back to, I got to give credit to the leader that was there. You know, the-the leader of our SRE teams. It's incredible the way that he will take responsibility for overseeing the completion of an issue. When in the past, I've-I've seen the complete opposite, you know, you-you join the call, you're like “Here's proof it's not us. Okay. Bye.” And we-we don't do that, which is really nice.
Dan: [29:31-29:50] Okay. Yeah. Awesome. You mentioned earlier around, like when the pandemic hit, I think you expediated the delivery of credit programs to support customers that were impacted by COVID 19. Can you dive into that a little bit? What was that experience like?
Sarvenaz: [29:51-31:17] Oh, yes. Okay. So, prior to the pandemic, we had protocols in place to provide emergency relief to customers for things like hurricanes and other natural disasters. But that was not enough for the now millions who were experiencing short-term and long-term financial impact due to COVID 19. And we knew we had to act fast. We realistically had a couple weeks before the demand for this type of financial relief would become overwhelming, to our systems, to our operations. But the full extent of what we had to build or what we wanted to build was gonna take maybe six plus months. So how my team approached this really is one of the highlights of my career. They quickly self-organized into a highly specialized temporary team from members across our end-to-end team. And then in true agile fashion, they narrowed down the scope to an actual minimum viable product. And that MVP was launched in just one week. And it was-it was really unheard of across the company for one of our more legacy systems, including a mainframe component to go to launch that fast. Then we continued to, you know, add value incrementally to that program until we were deemed best in class. And then that year, the initiative overall even won company wide recognition from our CEO, it was really an awesome journey.
Dan: [31:18-31:53] Yeah. That's a-that's really cool. I mean, to do anything substantial in a week or get going in the right direction is impressive. What do you think like, because you know, you can, we-we have the pandemic that happened and it was a very severe situation, but if you think of just like engineering teams in general, things happen like that on a smaller level, and you want to make a change or make an impact in a week or do something like that? Do you have any tips to get everyone like going in the right direction or to get very agile fast?
Sarvenaz: [31:54-32:32] Well, there's a lot that could be done. I think that whole notion of “Is it actually the MVP?” is really important because sometimes we bundle together features because maybe they're being marketed that way to the clients. And if we just change the way our marketing team works or the way our custom-or like, you know, our-our client facing teams sell, we can change the way we build. And that's something engineering teams and leaders don't always take into account is it's not just your little bubble. If you-if you see how the rest of the company is operating, you might find ways for them to be more agile. And then for you to be more agile as a result.
Dan: [32:33-33:18] Yeah. Yeah, I like that because on the-on the engineering side, you can kinda say, “Hey, here's by, scoping like, that's our very, very important thing. If we scope the right way, usually into smallest, like MVP possible. We can work faster. Now, if we work like this, how can the rest of the business adapt to that? And that's, it's cool because it's something that an engineering team can kind of-a way to impact everyone else right, everyone else in the business. I have a note here, your top three values are family, passion, and impact. How have you instilled these values into your teams at Amex?
Sarvenaz: [33:20-34:39] Alright so, a couple years ago I read a book called Bury My Heart at Conference Room B by Stan Slap. And I loved it just for the focus on values-based leadership and bringing more of your actual self to work. And since then, whenever I lead a new team, I like to share my values and what they mean to me in the context of work. For example, what the value of family means in the context of work is that we communicate openly about how we feel, because even if we need to share tough love, we know it's with the best intentions, right? When you-when you criticize your siblings, you still love them, but you want them to be better. And-and similarly we're happy for each other's successes. Now for the value passion, what that means at work is feeling excited about what you do, being proud of your work and really fighting for what you believe is right. And finally, the value of impact means that my work matters, that I'm valuing my time and my team's time. And that I'm improving conditions for others, whether it be our engineers’ day-to-day and or our customers. And I-I don't think everyone needs to instill these exact values, but I definitely encourage everyone to learn a about their values and then see how they can live by them.
Dan: [34:40-34:56] Yeah. Do you do-like with-with the values that you speak of, did you say this publicly to your team? Are you telling people what they are one on one? Like how is it actually like expressed and distilled for you?
Sarvenaz: [34:57-35:39] Yeah, I do a couple things. So, I have an internal about-me page that I recommend all of my leaders to do the same. So, it just talks about me; work and, and life kind of preferences. And it talks about my leadership style because when you get a new leader, you're always like, “Okay, what do I have to expect? What are they gonna be like?” and I want people to be able to figure that out quickly. So, I have that page, anyone can access it. And then I always have that kickoff where I'm like, here's my values. Here's why they became my values. That's actually what was recommended in the book I referenced. So, it really is a nice moment of sharing more about yourself, but also letting everyone know what they can expect from you.
Dan: [35:39-35:45] Amazing title. What was that title of that book-of the book? I buried my heart in conference room?
Sarvenaz: [35:45-35:51] Bury-yeah. It's-it's funny. It was a Bury My Heart at Conference Room B.
Dan: [35:51-36:09] Okay. That-it sounds like a good one for everyone to check out. The last topic that I want to, or the last question that I want to hit in this area. I saw that you led an agile transformation of a fifty-person team. What were the keys to success in that transformation?
Sarvenaz: [36:10-37:05] Ooh, yes. So, something I like to do in general is bring levity and fun into work. I think that has a huge difference, especially in moments of change. For example, after we completed our agile training and we had a plan in place, we had just a big party to signify the end of our waterfall project-oriented ways of working, and we invited all our non-tech partners, so they could better understand the significance of the change. Also, so aside from the fun, I'm not a fan of dragging out change. So, one thing that also helped was clear expectations, short deadlines, and a “no person left behind” mentality. This really forced the team to prioritize the same tasks at the same time, and there was a sense of comradery in learning and changing together.
Dan: [37:06-37:20] Actually the-what I really loved about what you said there is, don't drag out the change, because I have seen on the other side where you're trying to do a change, but it, I don't know, it's taking so long that you don't even know if you're changing or not.
Sarvenaz: [37:21-37:31] Yeah. If you have too much time, then there's too many people who are either in the old process or the new process or in between, and it makes it way more complicated.
Dan: [37:32-38:07] Yeah, very awesome tip there. I want to move us into our area of developer productivity. I think all of us, especially when we're just starting out in a role, we want to feel productive, want to feel like we're contributing. I know you even wrote a book on the topic of getting started at a new role, so definitely need to get your thoughts on that, but let's start out with, what would you tell an engineer who is just starting out and wants to, you know, get contributing fast?
Sarvenaz: [38:08-39:00] Oh yeah, it's possible. So, I always tell our new hires that they can make an impact within their first week simply by documenting what they learn as they go and then making it a resource for future new hires. It's always the same cycle, a new hire doesn't know where to start and they need hands on help from another engineer on the team, but everything they need to do and learn can and should be documented. I've found that sometimes engineers like to feel like their expertise is needed, like they're needed, but being the only person who knows something only makes it harder for them to leave the team and pursue new opportunities. So, I always say, instead of being the expert who trains everyone, be the person who put together the training guide that every future engineer uses, and so it's all about scaling your impact in that way.
Dan: [39:01-39:11] Yeah, that that's awesome. In your mind, what role does onboarding play in contributing to the productivity of an engineering team?
Sarvenaz: [39:13-39:54] To me, the most important part of onboarding is developing a sense of trust and belonging within the team, and this is where I see a lot of teams struggle. Especially as companies continue working remotely and we continue to see higher levels of turnover, new hires can start and not have a good sense of their team, their purpose, or how they fit into their broader organization. So, if hiring leaders can set aside dedicated time for their new hires, introduce them to partners and stakeholders and assign them buddies and ensure that high quality onboarding documentation exists, they'll find that their new hires quickly develop the confidence they need to be a contributing member of the team.
Dan: [39:55-40:30] Yeah. I mean, it just seems so important. A lot of our listeners, they're working at these amazing companies, some of them are kind of startups or scale ups, like we just raised a hundred million in funding, and now I can double the size of my engineering team. Do you have any thoughts, or tips, or even ways that you're doing it at AMEX to understand if your development team or your developers are actually staying productive? Especially when you get lots of developers or you're scaling rapidly.
Sarvenaz: [40:31-40:40] Yeah. Well, it's always hard to put metrics around productivity without having some kind of consequence in the process.
Dan: [40:40-40:41] Yeah, absolutely.
Sarvenaz: [40:41-41:13] So there's some things that are important to look at like, how soon does somebody, you know, what's the time from someone joining your team and putting something into production? That whole process can tell you a lot. It's not just how easy is it to learn, but how much support are you getting in your first ever release? How fast can you be releasing? So it sometimes has to be customized to the team, but figuring out what part of the process takes a while. Like I said, baseline first, and then pick your goals.
Dan: [41:14-41:52] Yeah. One mindset that I've been having more and more when it comes to developers, because a developer in modern times, there's so many different systems that they're working with, there's interrupts that are coming to them. Like we said, it's very like async now, remote world. I'm asking myself, how much time as a leader can I save a developer every week? If I can give them time back in some way, shape or form, then good things are going to happen for them. Have you ever thought of it like that? Or what do you-what comes to mind when I talk about saving a developer time?
Sarvenaz: [41:53-42:50] Oh my gosh, that is so spot on to what I think about because-and this kind of goes back to, my time's not the most important. Sometimes, I even tell the team, your time is more important than my time, because you're the one putting together a product, and so we do have a lot of focus on not wasting the time of engineers. This goes from everything like, don't attend bad meetings. Don't attend a meeting that has not a clearly defined purpose or agenda or anything like that. We give a lot of recognition when it comes to automating tasks, when it comes to eliminating. I even have a little like superlative that I give to people who proved that we don't need to build something. So a feature came in, everyone thought it was important, the engineer did some research and figured out either a better way to do it, or a good reason not to do it.
Dan: [42:51-43:42] One of the things we're kind of focused on now is, how can we save time in the pull request review process, which we see as like a bottleneck for a lot of organizations, and one of the things that we're finding, and it's not even just related to PRs, but you cannot automate a lot of information. Like, “Hey developer, someone's requested changes of you and your PR,” or, “Hey, this has been assigned to you,” and that's great. You know, that's just kind of basic notifications. But when you also add in context, so saying like, hey, this is the issue that it's related to, and here's the priority of this issue, and let me try to catch you up with all the contextual information so that when you need to go and do whatever you need to do the next step in the process, you have it there immediately.
Sarvenaz: [43:43] Love it.
Dan: [43:44-43:55] Yeah. Do you have any-how does that resonate for you of like, I think there's a side of automation and information, but really having the context for every single developer. What do you think about that?
Sarvenaz: [43:56-44:18] It's so spot on, and a lot of the times it won't be naturally or automatically provided. It would be really awesome if it were. And so you have to get the engineers into the habit of asking for it. Not just context, but impact. You know, if that's one of my values, I always tell them, if you don't know how this benefits a customer, then don't build it.
Dan: [44:19-44:29] Right. Yeah, absolutely. I do want to give you a chance, so I mentioned you have a book. What is up with this book? Tell, tell me about the book.
Sarvenaz: [44:30-44:48] So the book is called, Starting From The Bottom: A Guide To The First 90 Days At Work, and it's really catered toward, I'm straight out of college, I want to have a structured way with really good tips and suggestions to go through this next couple of months of my first job.
Dan: [44:49-44:51] Oh, that's awesome. Love the title.
Sarvenaz: [44:52] Thank you!
Dan: [44:52-45:25] Perfect. Cool, alright. So, I guess actually this leads in really well, because probably, you know, reading that book, anyone that's coming out of school and, you know, wanting to make an impact in the first 90 days, you're kind of being a little scalable mentor, let's say, with the book. You also have a TikTok following. You're doing stuff on TikTok. What's going on there? Tell me about how you're mentoring over TikTok.
Sarvenaz: [45:26-46:17] Oh yeah, I actually started on TikTok after a conversation with my little brother. This was back in 2020, and he was one of the unfortunate students who had his internship canceled because of all that was happening with the pandemic, and I was giving him advice on how to find another opportunity and what to do during his summer, and that's when he said, “All my friends need this advice. You should just start saying the same things you tell me, but on TikTok, because that's all they do all day.” So TikTok’s short video format, really such an engaging way to digest small bits of information, and it taught me a lot about what garner's attention. I also learned, unfortunately, that a lot of what students are learning from a career prep perspective, is either incomplete, outdated, or completely missing.
Dan: [46:18-46:36] It seems like, you know, having mentorship is very, very important probably for anyone. How do you think it's changed, I don't know, over the past, whatever years, 10 years, five years, in terms of what finding a mentor looks like now?
Sarvenaz: [46:38-47:17] Yeah, well, what's been interesting is, it's gone from only the circle of people you know can be your mentors, to you could have digital mentors all across the world. That's kind of what happened to me throughout the past couple years, and it's really incredible. And at the same time, there's just something about meeting someone over coffee or lunch, and just, I feel like you get a lot deeper, a lot more personal with whatever topic of help they need. So I feel like both forms are probably here to stay, you know, digital scale, but also personal and in person.
Dan: [47:18-47:31] Okay so yeah, we definitely have to check out all of your… So totally agree with that, but need to check out your TikTok videos as well. Who do you look up to as a mentor?
Sarvenaz: [47:32-48:05] Tons, tons of people, and what's wonderful is that my pool of mentors and people I just look up to in general, just continues to grow. On top of that, I found that someone can be a mentor without knowing that you exist. For example, I recently started following a blog by Deb Liu, who's the CEO of Ancestry. Her posts are so personally written and they cover such relevant challenges to what I'm experiencing. I sometimes feel like she wrote them just for me, and it's a really cool dynamic.
Dan: [48:06-48:34] Okay, that's very, very awesome. I want to move us to kind of our final area here. We have some questions that are coming in from the community for you. So I'll read a few of them here. So let's take the, the first one. Do you have any tips for avoiding burnout in your first engineering job?
Sarvenaz: [48:35-49:56] Mmhmm. Okay. So, the first tip goes back to that concept of energy management over time management and, and really knowing yourself. So, reflect on your work week and find out which people, which tasks give you more energy and which ones drain you, and then do something about it, right? Do more of the type of work that gave you energy that week. See if you can find a way to maybe divert the other ones that take away your energy. Then the second one is to banish this notion of being busy and truly value your time. This not only takes prioritization and focusing on impact, but it takes courage, because what people don't realize is your time is not only taken by tasks, but also by people, and if you're not yet comfortable saying no to people, or you're not yet good at doing it in a nice way, this is a really good topic to bring up with a mentor, do some role playing, but really, really is important. So third, once you start to get good at something, and I attribute a lot of my success to this tip, do not take more of the same work. If you're going to take more work, make sure it's something that will teach you a new skill, and don't repeat something you already know how to do well.
Dan Lines: [49:57-50:10] Great advice. I like this next one here. How do you maintain the level of success you have while not ruffling too many feathers or making enemies?
Sarvenaz: [50:11-51:05] Ooh, that's a good one. I would say humility is key. I always recommend that people only talk about their successes with the intent to educate, instead of the intent to impress. For example, I was mentoring a university student who had just won first place in his very first hackathon and he wanted to do a post about it on LinkedIn, so I told him, “Don't do that typical like, ‘I'm humbled to announce that I've won first place,’ you know, type of post.” I suggested instead, write a post about the top three tips or lessons that you learned in this hackathon that would really cater toward a first-time participant. He still got to mention that he won, right? He still kind of gets those kudos, but he was in the context of showing others that it's possible for them to do it too.
Dan: [51:06-51:22] Great tip. I like this question here. Let's say, because it probably applies to a lot of us engineers, let's say I'm shy by nature and I feel like I have good ideas that I'm not contributing. How can I improve?
Sarvenaz: [51:23-52:42] Yes, this is me! Not just the shyness, but I could not for the life of me get the timing right to interject my ideas into ongoing discussions, especially not like virtual discussions, and before I had a say in how these type of sessions were planned, which is probably most of the audience, I would take a good idea that I didn't get to share, during the meeting itself, and then continue to vet it out. So maybe go two or three levels deeper. Then I would share that really well thought out plan and idea with the same audience, either over email or I just reach out to them one on one for input. So now that I do have a bigger say, I actually, and anyone who has a say in how they run brainstorming sessions or idea gathering sessions, embrace the fact that everyone has different styles and try to accommodate them. So instead of getting everyone together for a one-hour brainstorm where they're constantly talking over each other, like maybe do an offline document where people contribute all their ideas, not just their best one that they can get in during the time allotted. It's all about inclusivity, you know, and inclusion in that way.
Dan: [52:43-52:50] Great. Here's one that's a little different. What's your go-to breakfast? How do you start your day?
[Laughing]
Sarvenaz: [52:51-53:20] You're right, that is different! So, I'm a night owl, and definitely not mega productive in the morning. So, like, I'll never be that “5:00 AM workout followed by fitness smoothie,” type of person. I'll probably just start with some tea and I know I'm not supposed to, but I skip breakfast most of the time. Then when I get hungry around ten, eleven, I'll just do eggs or avocado toast, you know, as my generation does.
Dan: [53:20-53:38] Yeah, I guess you have to, everybody's different. So, yeah, I'm actually happy you didn't say like, I wake up at 5:00 AM, I exercise, and then I do this and do that. That seems too good to be true. Alright, so last question. What's been your biggest challenge as an engineering leader.
Sarvenaz: [53:40-54:28] Well, this one, as expected, continues to evolve. So, at first, when I was managing engineers directly, there were plenty of challenges, but they had well defined boundaries. Then when I was managing directors, the boundary expanded a little, got a little fuzzy, but there was-there's still a clear sign of where I should be focusing and driving change. But now in my role, leading vice presidents who span so many different functions, it honestly feels like everything is fair game there. There's always another stakeholder I could be meeting or another initiative I could be getting more involved with. So, it really took the need for ruthless prioritization to the next level. But on the bright side, no two weeks or even two days are exactly the same, and that's something I really love about work.
Dan: [54:29-54:46] Thank you so much for answering all of those questions. [Music fades in] We always like to give our guests an opportunity to kind of plug something that is either important to you or something that, you know, other people can get an opportunity from you. So, what do you have for us?
Sarvenaz: [54:47-55:04] Ooh okay. Well, my team and many others at American Express are hiring, so if you liked some of what you heard today, you want to be a part of it, you should definitely consider applying. You can find our open roles at americanexpress.com/techcareers.
Dan: [55:05-55:10] Perfect. Alright, Sarvenaz thanks for coming on the pod today and being a part of INTERACT.
Sarvenaz: [55:11-55:13] I loved it. Thank you so much.
Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!
gitStream is the free dev tool from LinearB that eliminates the No. 1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.
The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!
Learn more about how gitStream is making coding better HERE.
