ShipTalk Podcast - Scaling Your Career and DevOps Organization - Nidhi from Nationwide
In this episode of ShipTalk, Nidhi Allipuram who is the AVP of DevOps Platforms at Nationwide Insurance talks about a career journey to DevOps and how the genesis of the DevOps transformation at Nationwide started.
In this episode of ShipTalk, Nidhi Allipuram who is the AVP of DevOps Platforms at Nationwide Insurance talks about a career journey to DevOps and how the genesis of the DevOps transformation at Nationwide started. In this excellent episode, we chat about empathy and how leaders can empathize. Nidhi has an interesting approach where she mob programs with her teams to keep her skills sharp. As her team's reach expands, calculating ROI for DevOps Teams which can be useful for a team of one or hundreds.
Ravi Lachhman 0:06
Hey, Ravi Lachhman here with ShipTalk, the Unscripted podcast, very excited to be talking to Nidhi Allipuram, who works for Nationwide Insurance. Nidhi runs the DevOps Enterprise Platforms team at Nationwide, and I’m super excited to learn from her experiences. But Nidhi for those of our listeners who don't know who you are, why don't you tell us a little about yourself?
Nidhi Allipuram 0:24
Hello Ravi, and hello everyone. Again, I'm Nidhi Allipuram. I lead the enterprise DevOps platform team at Nationwide, have been with Nationwide for a very long time. I don't want to tell the number and reveal my age. [chuckles]
But what I do in my current role, we own all the tools across the code pipeline— tools like GitHub, Jenkins, Concourse. We have Harness, we have all the monitoring and observability products like Splunk, and New Relic and all of that. So when we see an enterprise DevOps platform team, we not just own the product but we also are more the evangelizer of these products so that the teams are adopting best practices. They are— if they're having any issues integrating with the tools across the code pipeline, we are there help by creating templates and patterns. So it's been really good having this small team that manages all these products, and we are able to provide that go-forward direction on how they should have their pipelines. And we are able to give that direction again, definitely in partnership with architects and all of those resources, but it's been good.
Ravi Lachhman 1:49
Awesome. Yeah, that's awesome that your team handles that. I think where we're going to start is you have a treasure trove of skills— that leading engineering efficiency is actually a very complicated job. It takes a lot of skill, a lot of grit, a lot of perseverance to get there. For those of you who don't know Nidhi— I have the benefit of having these LinkedIn in front of me, so I'm cheating right now [chuckles]. But Nidhi's background is very aspirational for many folks, including for myself. You started as an engineer, kind of went through the engineering… becoming more senior of an engineer and then made a transition into maybe application ownership and owning functions, and now as an executive position.
Let's look at that journey that you took in, you know, X number of years— not to reveal your age! It's definitely a climb that you made and the amount of time you did it in, it's pretty impressive, right? Starting with, let's say, as an engineer… what were some key markers for you, as you decide to become more senior? How has your learning changed, like as an engineer, you learned like “x”, as a leader, maybe same approach… but maybe you take a little bit different approach to learning? Can you maybe talk a little about that?
Nidhi Allipuram 3:15
Again, my journey was not that fast. I think I took my sweet time. And I am happy that I took my time and I didn't rush into things. So a little background about me— I have a bachelor's in computer science and I did my masters also during my early career. And when I started my journey, I started as a developer more in the data warehousing space, heavily focused on Oracle; then we transitioned to Teradata, super excited when we transitioned, and then moved to Teradata, and then got into from PL SQL to Informatica for the ETL stuff. So throughout that development, that journey, I loved to be hands-on and never thought I would get into leadership roles. I always thought that that was way out of my league. And “this is what I love, this is what I would do for the rest of my life.”
But I think it always happens for most of them that you might not see the talent that you have, or the skills that you have, until somebody pat you on your back and says “Hey, have you considered this, though? Have you thought about that kind of thing?” So I was leading as a tech lead, kind of architect, as I was moving. I think then I had almost a team of 15 indirectly reporting to me. I had one of the leaders saying that “Hey, you do such a good job in leading. You set the direction, you're very good at influencing, and, of course deliveries are one of your strengths. Have you thought of being getting into leadership roles?”
At that point, my first reaction was “no, not really I want to get into architecture and go that that direction.” But things happened, and there was an opportunity. And I was like, “You know what, I'll give it a shot”. I went through the process and got the job. And my first three months, because this was early 2010-ish, right, it was very traditional people leadership role kind of thing. It was very different than what it was today, right? The first three months when I took the role, and I was trying to mimic my peers or mimic what the role is expected—to be a people leader— I actually got bored. I mean, I loved the people part of it, I loved spending time with them, coaching them and helping. But I missed the hands-on [parts] because before that when things broke, I would know exactly which job is dependent on which job. And I would be able to tell how to run a job and all that, right. So from getting out of that, and just being into… just the high level numbers and all of that, I felt kind of like maybe this is not what I want. And I was ready to step back.
But luckily, I had a great mentor, a great coach. And he said, “No, no, no, you can mold this role however you want. When it is a leadership role, it is ‘Yes, you have to set the vision, you have to lead the path, and of course coaching and all that’… but at the same time, you can still be technical, you still can do what you're doing today. But again, pull yourself out and let the team make those decisions, but you can kind of oversee it.” So around that time, we had a role called IT Delivery Executive, where the leader oversees the program. And again, you're involved in the technical decisions, but it should be at a very high level. But I kind of cheated the system a little bit and got into the weeds a little bit— not too much. I was able to feed my technical craving that I was missing getting into the people leader role— but actually that worked out great because after that, I think many of those within my space started leveraging that role and getting more technical, being that technical manager [rather] than just being a people leader.
So if you go back and ask me what I've enjoyed being an individual contributor hands-on, and what I've done this, I feel like I think after a certain time— again, coding is great, if you love it, you definitely want to keep learning new technologies and keeping up. In the people leader role what I've enjoyed more is, as an individual contributor, if I was able to accomplish X amount of work, or I was able to deliver X amount of work… as a leader, I could do 10 times that x. 10x, right. So I could influence 10 individual contributors and get what I wanted to deliver, whether it's a business feature… some kind of value that you want to deliver, as an individual contributor can only do so much. But if you have that vision on what you want to deliver, you can get 10 people do that, right. So I felt like “oh my god, I'm doing a lot more than I was able to do.” And I felt more that sense of accomplishment was much higher.
Ravi Lachhman 8:24
Perfect, yeah. For some of the listeners— we were having a side conversation before this started— I want to pick up on one of those nuances that you just brought up. And at the benefit, this is a greedy question, this is something that I struggle with and I'm privileged to have Nidhi here to help me answer this question. When I made the transition from individual contributor to manager, or leader now, one of the hardest things for me to do— we were talking about scoping right? I’ll take the budget part out of it, but scoping something— is how do you pull yourself out of like, let's say you and I have certain level of skills. And so we might estimate work like, “Hey, you know what, this will take us X number of story points to complete” versus one thing I vowed to never do but found myself in the trap doing is that when I start to scope work, I'm actually scoping it for myself, like “oh, yeah, I can accomplish this in X number time. But really I'm getting better at taking the team skills into account.”
Do you have any tips or tricks around that, or personal anecdotes? Like, right when you made that transition? I think that’s always the most unknown part and you kind of lived through it. Like how can you tell the telltale signs with that is going on?
Nidhi Allipuram 9:38
Yeah, it's been a while but definitely when I just moved into the role there was quite a few times— or even before I became the people leader, I think when I was a technical lead— if I could do something in five hours, I would be like, “Oh my god, it's five hours”… but as I was leading and as I’ve experienced other developers on the team, there are some people who do [it] really fast, some people who do [it] really slow. Some people write a code in 200 lines, some people write the same code in 20 lines, right? So there's a vast difference. It doesn't mean that the person who wrote 200 lines is the best— I would rather want something more crisp, right? But when you come to that scoping and estimation and everything, you have to look at both the ends and go with the middle end. Because, again, some people are very good at documenting, and they're crisp at the testing and all of that. So you want to make sure that you're thinking through all of those, and definitely give that learning time, give that uplifting time, whether it’s business knowledge or technical knowledge. So I would generally say if I if I would do this in five hours, but if a new developer takes 20 hours, I would probably go between 12 hours or something around that.
Ravi Lachhman 11:02
Yeah, that's perfect. That’s I would say, at least for myself, is the greatest part of the unknown, right? Because like when you when you start stepping into management, you're not only responsible for what you do, but you're also responsible for what others have done and not done. And so with the scoping, it's been a challenge. If you ever talk to my boss Steve, he'll say, “Ravi is still learning how to do this” [chuckles]
Nidhi Allipuram 11:28
Yeah, it is hard to have that many hours when you know you can do it much faster. But you have to again, consider all the different things. And definitely, if you keep measuring your estimators, guesstimators, I would say, you would improve it, like “Okay, I'm overestimating” or “I'm adding too much back”, that kind of thing.
Ravi Lachhman 11:52
A very pragmatic answer. I’ll kind of skip one part and kind of get more into executive management now. I think this question would apply to, let's say, for folks who were, let's say, working at smaller organizations and they're just building out a DevOps practice. It's all about calculating ROI. So at the very start of my career, I worked at Deloitte, right, so I was a consultant. And so I was on the partner track— I definitely wasn't going to make partner like there was no question about that— but the thing with the Deloitte and a lot of businesses is that to get promoted or kind of oversee a certain group, is there has to be a business need for it. Like, it's not automatic, like, “Oh, yes. You’re clearly extremely skilled…” But if there wasn't some sort of internal business need to justify it… you know, we can talk about that.
So no matter if it's, you know, a one-person DevOps organization or multiple teams… Can you talk about that journey? Because DevOps is a relatively new business function, right? Like, you know, 10 years ago, if you and I were sitting down, we might call it something else, like, “Oh, this is release management, or this is system engineering.” But today, there's a lot of, let's say, investment to DevOps… Can you walk through that journey? Like, at what point did it make sense to make a department? Nothing internally that you have to say, but how did that come about?
Nidhi Allipuram 13:23
Yeah, I can give the same DevOps journey because when we were creating this organization, I was not part of this conversation, but I had some of my close friends, mentors who were making those decisions. So I was indirectly involved into those decisions. Again, as you said, DevOps is totally new concepts and new practices. And creating an organization, you have to be able to show that “yes, it's going to give you the ROI” if you're investing so many people, so much of money into this right.
So I'll give you why they did it; within Nationwide, again, being almost a 100 year-old company, you name a technology we have it. Our IT staff is almost 5500 Associates. So what was happening was we had different tools and technologies spread across the organization, across that 5000 IT staff. And when we had them, first thing— everybody was managing tools in their own ways. There was no self-service enabled for those tools. There was not much integration between tools, there was a lot of manual processes. And definitely, there was a duplication of tools sitting everywhere because whoever wanted a monitoring tool, they would bring a monitoring— CD or CI, whatever it is. So… everybody was making their own decision, the process to deliver business value [was] slow, because there's a lot of manual steps, there is no that end-to-end pipeline.
So the business case is a very straightforward thing, that we have to centralize all these tools into one organization, and that team should adopt the DevOps practices and automation and self-service and all of that. And doing that— definitely. consolidation of tools will bring you efficiency. Before that, many of these tools were managed as a central theme, where—because there's no self-service, they will not give admin access or any kind of access to other organizations— there was a large team to support one tool. Like eight to nine people were supporting one monitoring tool; they would write synthetic scripts, they would write alerting on behalf of all these applications. When we brought all of these into one central organization and started adopting DevOps practices, nine people supporting one tool became two people supporting one tool. So that's it, you’ve got big efficiency right there. And then, as we are doing more and more, we are trying to consolidate. Do we really need four tools for this capability? Can we go with two— make one as a standard and one as an exception? So there are quite a few decisions that were made when we got this. Definitely there is “because it's all part of this organization, if tools are not talking to each other, now it's my team's accountability to make sure that they integrate well.”
Again, because we are a small size, but at the same time because we have that mindset of automation [for] everything. Like even for Harness, you would see how, I think the Harness team itself said, “We are doing a really good job of managing Harness by a small group for that entire organization. Because we have onboarding bots, if somebody wants to get into Harness, they just have to run that onboarding bot and within few seconds they have it,” right. So we try to adopt all the practices that we preach. And by that, we are able to gain that efficiency. So it is clearly showing that having this organization has given that ROI.
Ravi Lachhman 17:25
Yeah, that's awesome. I think, just recapping what you said, all the proof is in the pudding, right? Like, just, reduction in toil or hours to accomplish the task, and tool consolidation. It's actually a really good approach, right. Plus Nationwide being so big— you mentioned the 5500 Associates, right— you can really start doing some math. And that's really good. I mean, that that calculation even works for like a single-person shop, right? If this one person is leading DevOps, for some small company, they can still say that, hey, if this wasn't here, this is what it would cost you. Kind of like reversing some of the math. And so, for Nidhi, Nidhi is a culmination of years of experience and years of learning.
The DevOps space moves really fast, the space that we deal in, plus there's a lot of different competing priorities. How do you go about learning or keeping up with the trends? I'm always curious to hear how executives that do it, like how do you keep up with some of the market trends that occur?
Nidhi Allipuram 18:42
So two things. When we say learning, there's two— one is definitely market trends, and the other one is personal growth. So for market trends, again, very usual things: podcasts, I love to spend time with my peer group (outside industry peer group, not people from Nationwide) just to see what they are doing differently, how they are leveraging some of these tools. And then definitely within Nationwide, I try to spend a lot of time that people who are always on top of trends like architects or tech consultants who are constantly doing research or attending conferences, those kinds of things. So that's just to understand industry trends.
Personally, recently, I dedicate two and a half hours of my calendar time, once a month, and I do mob programming. So I sit with one or two developers and I'll be on the keyboard and they help me wherever I'm struggling with anything. So every time I take a tool or a concept and I start working on it and say “how do you do it? What do you with do this? What am I doing wrong here?” And then I would love to spend more time [here], but just started this one, and I'm actually enjoying it. I feel like because my team supports almost 35 tools— we were at leverage 50, and now we dropped to 35 so we are slowly consolidating and decommissioning a few things— learning the tools that they support, and understanding and being able to empathize what the developers are going through is definitely helping me with this dedicated mob programming time.
Ravi Lachhman 20:31
That's awesome. I actually never thought about that. I’m going to steal that term from you, “mob programming”, just because it really helps with empathy, right? Like, [what] the users are going through, we can have an idea or use our best guess like, “it used to be like that, I'm sure this is the same thing.” A lot of times, in engineering efficiency, [from] what I’ve come across, it's actually fairly difficult. I remember the previous firm I worked at… as an individual contributor, I was part of an Engineering Leadership improvement study for their DevSecOps practices. And so we kind of came up with this golden pipeline, which will go through several types of security checks. I was the one writing sample code, so like “you know, Java, right?” “Well, yeah, yeah”… So I wrote a whole bunch of Spring Boot code that was purposely fake, to be infringing. And when we had to go about integrating that with the build process, it was super painful. I was like, “Whoa, this is what the team goes through. I could build up my machine and now they have to put it in another third-party build tool.” That’s important, like I didn't realize it was so much strife. I was like, “I use these things all the time at work” and then years go by [chuckles]. So I really like that idea.
So another question. I think for some of the folks who are kind of green in the DevOps space, working on an engineering efficiency team would be a goal for a lot of people, right? If you were hiring somebody—like, let’s say you're hiring me— what would be some qualities that you look out for when you're hiring a person, especially for your team?
Nidhi Allipuram 22:16
Yeah, for me, first thing, I feel like my team is definitely a high-performing team. For me, the most important thing is the fit, aptitude, will you be working well with the rest of the team. Coming to the technical aspects, even if you don't know some of the technologies that we support, you can pick it up, you can learn and we can help you learn. But attitude is a big thing because if you don't have the right personality, and if you don't gel with the team, it's going to bring the entire team's engagement down. So it’s not that I'm not going to look at the technical skills—these are more important for me, and we are looking for people more poly-skilled. Again, the comb shaped, is what we call it— to have depth of knowledge in multiple things. At the same time, you're more generalist, you'll have a high-level understanding of all the tools across the stack. So again, my big thing is the aptitude-attitude, all of those things.
Ravi Lachhman 23:40
Yeah, that's great. And… I heard a couple leaders always say that, that the team dynamic is really important. I think, from an interview candidate standpoint, you’re not only getting interviewed but you’re also interviewing the team. Will you be a fit, like, there's a two way street. And that's really important; if you get along with the team, it's beneficial to the team and beneficial to the person's career, or vice versa. If the person's not a good fit for the team, it can really drag the team down, right?
Nidhi Allipuram 24:16
Right, generally, people are fast learners. And generally, as long as you can tell in the interview that they’ve learned, they’ve tried different things [then] they can easily learn, right? Once you get that, you can teach them. But if they're technically strong but they don't get along, you'll hurt more because you might lose some really good people from your team.
Ravi Lachhman 24:39
Oh, yeah, there's like this XKCD that has a x-y axis like “you're a jerk if you're smart and not nice.” Like, there’s a scale if you are a jerk or not. [chuckles] Pretty funny. I'll turn the tables a little bit to Nidhi now. Let's see. Last two questions. I’ll see if I can answer a question for Nidhi, Nidhi, do you have any like difficult interview questions you ask somebody, or just really abstract questions? So when I interview people as a technical interviewer, I usually look for like a couple of things. If they have at least 50% of the skills, I kind of discount everything else like, fine, they want to take the job because they want to learn new skills. But then I kind of ask them some very abstract questions like, “hey, the website slow.” That's all I would tell them. Or “the web application’s slow?” Do you have any like that? [I’m] giving away the secrets here… But like, could you ask me a difficult interview question? Like one question you would ask?
Nidhi Allipuram 25:40
Huh, I can’t think of any right now. But again, there’s a couple of things that I ask, depending on if they're working with Nationwide or not. I can see how a large IT group, we tend to move resources around. One of the questions that I ask is, what is one [pieces] of the feedback that you have received, that you disagreed with? That gives me a lot of information on what the feedback is (first thing), and then how they take feedback and why they disagree? It just kind of helps me understand their personality. The feedback tells me a little bit, how they reacted to it tells me a little bit, and how they acted afterwards, like “you took that, and what did you do about it. If you disagree, what did you do about it?”
Ravi Lachhman 26:38
[jokingly] That’s why I’m interviewing for this job, Nidhi! I like that. I have two things I'm stealing from you— mob programming, and when you have a disagreement.
Nidhi Allipuram 26:44
[chuckling] That counts. And then other things. Within Nationwide, I'd always love to hear what they think we could have done better. When I say we— the organization. So if you are in my space, or if you're in our CIO space, what would you do differently? What did you disagree [on] or did you not like about the things that we have done? That gives me feedback about my organization or my leadership, and then also helps [in] saying that, oh, there must be some creative part that they have and we never thought about, and we want to implement it. So it kind of gives me [an idea of] “are they are brave enough to tell me on my face what we're doing wrong?” Again, I want them to be right. I want them to be able to challenge— healthily challenge— the leadership also, saying that, “hey, where we are going is not the right direction. These are the things that I see.” I want them to be feel empowered to say those things. So again, that gives me a different perspective about the candidate.
Ravi Lachhman 27:50
Perfect. Yeah, that's actually a really interesting question. Yeah, feedback is actually something difficult, like as an engineer, no one likes negative feedback. And then as you kind of transverse senior engineering and then into leadership, it’s something that I had to get used to. Like I get feedback every day now. Kind of constant feedback, right? Like, usually, l would try to hide behind my like, code like, “Oh, no, no, I only get feedback when we do a code review, or a problem happened.” But then you kind of become more senior, a principal, you're just making a lot more decisions. Feedback is kind of a natural loop.
One last question—and this is an intrinsic question for Nidhi. Let's say you've met, in all of your experience, you ran into your younger self. So maybe you just graduated university, you ran into her on the street as this Nidhi with all the experience— what would be something you would tell your younger self? This is how I like the end all the podcasts.
Nidhi Allipuram 28:50
What would I tell my younger self? Firstly, I would say be confident and try different things. I think my younger self— again, being a mom at that time [with] two young kids and everything, I think it was more like, :Oh, I need to take care of the babies. I need to focus on them first” and all of that. I think you can do both. I feel like if I had to go back, I would be like, “Yep, I can do that, and I can still focus on my career…” I did I think I did, fairly, but I think there was around four or five years where I took a backseat. But again, be confident and try different things and explore early. I think just for four or five years, I took a backseat, which again, I don't have any regrets. But if I had to, I think that that's the only thing that I would go back and do it— do both.
Ravi Lachhman 30:00
Awesome. Always solid pieces of advice. It's just that “don't be afraid of the unknown”, and it's always very human to do that, try certain things. Nidhi, thank you so much for your time today. We really enjoyed having you on Unscripted, and stay tuned for our next episode. Thanks.
Nidhi Allipuram 30:17
Okay, thank you, Ravi.