Sonali Varde, Senior Software Engineering Manager at LinkedIn, joins host Kanchan Shringi to discuss how AI is changing the role of the engineering manager. They explore how AI is showing up in day-to-day management work, including operational reviews, planning, communication, workflow automation, and preparation for leadership discussions.
The conversation looks at how engineering teams are adopting AI tools and agents, what kinds of skills and practices are becoming more important, and how managers can think about context, review, testing, and operational rigor as AI-assisted development becomes more common. They also discuss how AI affects coaching, performance conversations, hiring, onboarding, team composition, and collaboration with peers and leadership. The episode considers both the opportunities and limits of AI for engineering management, with attention to human judgment, curiosity, ownership, and the continuing importance of technical and organizational understanding.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
Other References
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Kanchan Shringi 00:00:18 Everyone, welcome to today’s episode of Software Engineering Radio. Our guest is Sonali Varde. Sonali is Senior Software Engineering Manager at LinkedIn. She has more than two decades of experience leading engineering teams across architecture, product dev and platform deliveries. Today we are going to chat with Sonali about how AI is changing the engineering manager role. Sonali, before we begin, I should note that I know you through my network and have followed your career for some time. I think you’re particularly well qualified for this conversation given your experience as well as LinkedIn early adoption of AI. That said, is there anything you’d to add to your bio before we start?
Sonali Varde 00:01:01 Hi Kanchan. Happy to be here on this podcast with you. The only other thing I would add is that I also love to mentor and coach early career managers and walk them through some of my journeys and lessons.
Kanchan Shringi 00:01:15 Okay. Let’s start with your own job. If I followed you around for a week, where would I actually say AI showing up in your work?
Sonali Varde 00:01:25 All right. I think if you followed me through the week, I think my first meeting of the week starts with an operational review. We have a lot of systems legacy and new that we own and a lot of time goes in making sure that we have the right level of operational rigor. And so, the first early signs of where I needed to have automation was actually having lot of my operational dashboards automated in a way that I could synthesize that information for my leadership as well as my VP level org. And so, if you followed me, you will see that every week there is what are the new signals, what are the new insights, what are the new experiments that the team launched or did? And so, a lot of time goes into understanding some of those operational nuances and that’s where you would see me using a lot of AI skills or trying to automate things in a way that’s easier for my team to understand and digest what signals we should be debugging more. And two is for me to uplevel how do I communicate some of the things that I am seeing in a way that can be summarized and synthesized better for my leadership.
Kanchan Shringi 00:02:49 Can you just talk about what specifically changed here because of AI? I’m assuming a lot of the automation was in place. You talked about summarization, perhaps that’s an example, but what else changed due to AI?
Sonali Varde 00:03:02 So you have lots of dashboards, right? And so those dashboards do have multiple systems that have different kinds of dashboards and tooling, right? If you are on a legacy system, the legacy system has a different kind of automation and a tool output that is available for you. Then you are on newer systems, and newer systems have probably been onboarded to a newer tool and things that. And so, there was a lot of switching and making sure that we were taking data from multiple tools, multiple places and then trying to create our own visual or a spreadsheet of how we understand the metrics that matter. So, the first thing that I was able to do is actually build Claude skills, right? That can now go through these different systems, understands what exactly from that output I’m looking for and creating this daily summary if you will, for me in a way that I don’t have to run this one-hour review meetings with multiple managers coming and talking about their systems. And so, it reduced the meeting time, it reduced a lot of conversations about was there data available or not? All those things happened in the background and when we came into the meeting, we were actually able to focus on the real insights that were the problem for that particular operational review. And so, it just upleveled a little bit in terms of where we used to start the operational review to where we are now.
Kanchan Shringi 00:04:41 Thanks Ally, that’s helpful. For people that may be not too familiar yet with Claude skills, can you explain what that is and then maybe get into a little bit of a detail on how exactly you use that here and why that was not possible before AI?
Sonali Varde 00:04:59 I would say that it’s not that it wasn’t possible, it needed to have that level of rigor of figuring out what the ran job should be and there was a little bit of the grind that was never prioritized and once we got access to Claude, Claude actually had an easier way to onboard all of these things in a way that you could speak to it as a natural language, right? You can talk about it as if, hey, these are the things that I do. Here are the links that I go to and here’s what I look for as an output. And it’s almost like a Chief of Staff kind of skill. If there was somebody who could help me with a task, its literally Claude skill is almost like you’re telling someone the actual task in a way that you would explain it to another human and then it says, okay, here’s how I understand you. Here’s what I think is the output that you’re looking for and here’s what I can do. And then build a skill that you can then say, okay, run this everyday morning or run this before my ops meeting and then send out an email on the data that is missing to my leaders or whatever, right? It has a way that once you have the basic skill, you are able to talk to it and make it even better.
Kanchan Shringi 00:06:24 How does this compare with prompts that were all the rage a year ago?
Sonali Varde 00:06:29 I think when we were thinking about prompts, we were talking a little bit more of using them for solving customer kind of a problem. We were thinking about prompts and AI of like, hey, how can this help in solving something that is more economics or a business problem, right? We weren’t as focused on what we would do with it from an internal developer productivity or coding kinds of tasks. We were thinking about coding kinds of tasks, but they were a lot more of as if a step up of an IntelliJ or an Eclipse automation. We were not thinking about it from the power that it could have of just automating end-to-end workflows. We were thinking of them in a lot more compartmentalized way is what I would say. Even with IntelliJ or Eclipse, you had an automation of boilerplate code, and we just thought, hey, with the prompts we could go one step further and have something that’s a little bit more built out, right? Or template-based kind of things. So, we were thinking a lot smaller, I would say than how we are thinking about it now.
Kanchan Shringi 00:07:45 Sounds it’s positive, but do you have any example where the AI told you in this case you’re using Claude, so AI told you that something looked useful and convincing but was actually wrong?
Sonali Varde 00:07:59 Yeah, it tells you what you should be doing. At the same time, you still have to use human judgment and look yourself for some of the depth. I definitely, as I was trying to adopt some of these tools and see where and how I could coach my team members to use it, I used it in writing or bug fixing some of UX bugs and a lot of times I do come from a backend engineering background and so there are things like accessibility, there are things related to resizing reflows kinds of architecture where I just took some of the inputs that the AI agent gave me and I implemented it only to find out during the code review from my tech leads that this is not the right implementation. There was really no bug in the regular flow. The bug actually happened in a reflow kind of an architecture of the COX. And so I actually learned that even though you could use some of the AI tooling, you have to still have humans in the loop. You need to understand the context, you need to understand the depth, the skills of hard debugging, the skill of actually having the context in which you are looking at the problem is supremely important. And that’s my biggest learning by using some of these agents in my day-to-day, how I make decisions about when should I trust it completely versus when should I trust but go with a caution.
Kanchan Shringi 00:09:36 So understanding is key even though you are getting the AI’s help in synthesizing and perhaps thinking to a large extent.
Sonali Varde 00:09:45 Yes, absolutely.
Kanchan Shringi 00:09:47 So you did give examples where you’re using Claude in this case to help you work through what metrics should be used in this case also to do a bug fix, which you felt was a good start but couldn’t replace human judgment and understanding. Are you also a manager using AI to actually as an agent to do things beyond suggesting code changes for example?
Sonali Varde 00:10:15 So the places where my team is actually using is creating agents for automation of some of our workflows. One of the examples that we recently had is we do have when some feature is ready for bug bashing, we go through a bug bashing sheet. We come up with which platforms are people testing, and then we log all of these bugs in a spreadsheet first and then we import that spreadsheet into our Jira workflows. One of the things we did was we just created a bug bash agent, right? So as the cross-functional team comes together for an end-to-end bug bash, they still use the same sheet for logging off the bugs, but then how do we triage those bugs? How do we then import them into actual Jira? How do we prioritize these things for what’s really a blocker, non-blocker? So, some of these tasks, my team has started to actually build agents that will help us with this kind of efficiency. This helps us a lot with multiple teams having multiple bug bashes and so this has reduced a lot of our manager and tech lead times in some of the process automation.
Kanchan Shringi 00:11:31 What is the difference between a skill and an agent?
Sonali Varde 00:11:33 Yeah, skill is something that you can share with people who have similar problems. So, let’s say if I look at certain dashboards, most of the senior EMS within the team have a similar kind of an ask, right? To look at their own systems and their own dashboards. And if I write a skill, it’s something that is easily shareable. It’s the same thing with agent, but an agent is actually performing a task on your behalf. Skill is you actually invoke it whenever you want and it’s just doing summary and synthesizing and letting you know you could build skills that are actually then become composite skills could become an agent, right? And so, skills a little bit more of an atomic unit for your own kind of a task if you’ll so
Kanchan Shringi 00:12:26 Easier to get started with skills over time you can compose multiple skills into agents.
Sonali Varde 00:12:32 Yes.
Kanchan Shringi 00:12:33 Do you also get AI’s help maybe to suggest the skills based on what you do on a day-to-day basis?
Sonali Varde 00:12:40 I actually have not used it to suggest skills because the way I was looking initially was, I know a bunch of things that I don’t do, right? it’s just too much of a grind. I try to have an Eisenhower metric in my head when I go in on a Monday, right? What’s urgent and important? What is non-urgent and important, but I just don’t have time to get to it, right? And so that’s kind of how I went into it. Okay, here’s where I would love to have skills so that they’re all-important tasks, but I don’t want them to become this urgent thing. I am sure that now that I have used so much of Claude that Claude knows a lot about how I think or how I do things and over time I’m sure I could just ask it for suggesting a skill and it would start recommending some of these, but I haven’t yet started to use it in that mode.
Kanchan Shringi 00:13:38 But it certainly seems AI has changed the balance of time. As a manager you do some things less and you do some things more. What is it that you are able to do more now?
Sonali Varde 00:13:50 One particular thing that I definitely feel I can do more is I have lots of ideas about where my team should be investing in, what should we be working on. Sometimes it’s product ideas, sometimes it’s platform ideas. Sometimes it’s just ideas that I love to just explore, right? And what could be possible? What should we be doing and things that. I feel now I have lots of ideas into these mini prototypes if you will, and I feel I don’t have to spend a whole amount of time preparing presentations or decks and convincing my cross-functional partners or my peers or my direct reports onto something because I’m actually able to have a lot more solid prototype if you will, to get them on the same page.
Kanchan Shringi 00:14:47 Now that we have talked a little bit about how your day-to-day has changed, let’s talk about the team. As AI has become part of everyday engineering work, what did you have to change first? Did you have to make sure that there was certain context in place, certain frameworks in place to make the team effective with AI? Can we start with that?
Sonali Varde 00:15:12 So I will say that we started this AI adoption around nine, 10 months ago. It started with should we use Cursor or Windsurf or GitHub co-pilot to start augmenting to the tasks that we were doing and we started to see with just adoption, right, how many people were actually adopting any of these AI tools that were becoming available say last August or September. And that’s the only thing in my mind or I guess even in our leader’s mind is let’s have people starting to adopt these things and then we will see if there is anything in there. I think the true adoption started happening with Claude code coming out in early January and a lot of us using these tools during our hackathon week and that was actually a truly transformational moment. I think personally for myself, as well as for a bunch of people on my team, we used pretty much all the AI tools that were available out there.
Sonali Varde 00:16:20 We used REPT for some app mockups, we used Claude code for coding, we used Gemini for presentations. And I think that’s where all of us started to feel a little bit there was something here that’s truly going to help us understand. And then I think in February and then after February, I would say our goal initially was let’s have adoption metric, right? Let’s have everybody use it, including us as managers. And once all of us started using it, we started sharing our learnings. There were some people who were early adopters and those early adopters actually showed us what all can be done. I talked about the bug bash agent or somebody else wrote some other agent. And that’s kind of how we started sharing our team share outs or our company share outs. And we actually created an environment of learning through these share outs and plugins and sharing skills and it became a little bit more infectious I guess that oh, you are seeing something that’s really valuable to your team, why don’t I use it in my team kind of a thing. And that’s when more team members starting to use it. And now it’s almost everybody on the team is using AI tools for the code that they write or the tasks that they do.
Kanchan Shringi 00:17:52 What do you see separating people that use the tools well versus others? what are the specific new skills that matter more?
Sonali Varde 00:18:02 I think what matters is sometimes when we have a lot of experience, I think our first way of doing a task is very much hard set in our minds because it feels, oh, I know how to do this myself, right? And I’ll take an example of my own self, when I get called into an on-call incident, I know what my steps are, it’s almost a muscle memory that’s there. I know which dashboards to go, I know which logs to check, I know which regex to actually look for a certain kind of an error or a pattern and it’s very easy for me to do it myself then actually saying, oh, looks there is a new operational agent that’s out there. Let me talk to that agent and let me try to explain to that agent what I’m looking for in the logs.
Sonali Varde 00:18:58 And I think for somebody who has a lot more experience, it’s harder because your muscle memory, your things with your code base, the things that you know, it’s easier almost to do it than to ask for how to do it. But it’s easier for people who have not implemented something new on the on-call roster if you will, for them to be able to know these things. And if they are alone without a tech lead, let’s say at midnight, they get a phone call for them, it’s so much easier to be actually saying, hey, I my team owns this particular code base. What are the kinds of errors that I should be looking for? Or what are you seeing as the errors that have exceeded P 90 nines or P 90 fives or whatever, right? And so, I feel there is that little bit of asymmetry of knowledge that’s there.
Sonali Varde 00:19:54 So it’s again up to people for how they want to use it and how they can use it to uplevel themselves. I have realized that now some of the tasks that are muscle memory for me, they’re only within my repos and what I own, but I don’t have that muscle memory for something that’s across the boundary or across the org. And I feel the agent is really helping me cross that boundary, right? Instead of calling that other team’s on-call engineer, I can do some more debugging before I decide, okay, let me page somebody else. So, I feel there is still a lot of learning I will say, but at the same time I feel it’s helping cross boundaries a little bit better.
Kanchan Shringi 00:20:38 It’s very interesting insight that you really have to unlearn certain things before you can use AI effectively. Yeah. This leads me to my next question. Let me explain that a little bit. Just taking your example of the on-call and somebody that’s new at this, there may be firing of multiple threads with the AI to understand what might be going wrong, potentially multiple agents. So, is there a perspective you have with respect to the fact that the engineers themselves now have to gain some managerial capabilities in managing multiple threads or multiple agents as they do their day-to-day work? This is something I’ve heard that software engineers now are becoming managers of a team of agents. Do you see any truth to that in practice from your experience?
Sonali Varde 00:21:36 I think that, and maybe this is my whole brain is into these whole systems thinking, right? I think as engineers we always had this multitasking multithreading kind of a mindset. So, there is a chance as you are junior in your career, you don’t know where to start and you have 3, 4, 5 agents, let’s just take an on call that they just fire out to see what will come back, right? But I’m a big believer in learning by doing, it’s okay if somebody puts four or five agents as long as they’re in their token count, I guess I’m okay with whatever they’re doing, but I think you learn over time, right? You learn that okay, all these multi-threaded architectures, they could all lead to too many garbage collections or dumps and things that. And so, I think what’s going to happen, or this is maybe my speculation a little bit here, but I do think that it’s going to help us up level ourselves faster, right?
Sonali Varde 00:22:38 We will actually onboard a little bit faster. We will actually get to the depth a little bit faster if we just are not afraid of failing through having multiple agents and learning. I think the most important thing is you are curious and are you learning, are you actually reading the output of these agents? Do you understand why two, three agents conflicted with each other and actually produce something that wasn’t the right outcome? Right? And as long as people are willing to learn, I think it’s okay to learn by failing. I do think that people are learning and adapting faster given the fact that they are understanding that okay, maybe this was a direction that didn’t lead to an outcome, right? So okay, this is not how I should think the next tasks are okay, I just need one or two things that I need agents for. So, I think that learning I’m seeing happening within my team and I think it’s going to happen even in the broader industry.
Kanchan Shringi 00:23:45 Maybe I can re-ask the question with a potentially better example now that a lot of the work is done by the AI agents, the coding agent for example, or testing agent, if somebody’s created it, are the more effective engineers able to take on more projects at the same time because they’re able to manage these multiple threads or agents?
Sonali Varde 00:24:07 I think the answer is definitely yes. From a building perspective they are able to take on multiple tasks or multiple projects. I think the places where I still am yet to see the outcome are all these things in the right direction and are we going to have 3X more throughput and things that? I think that is still something depending on how complex is your architecture, how complex is some of the things that you depend on other teams and how distributed, how much of legacy, how much of new build that you have. And so I think the answer is there is somewhere in the middle, but you definitely see that lot of engineers are able to take on more building tasks and a lot of time is spent on code reviews, deployments, operational excellence, hard debugging testing of some of these projects. So, the time to build is shrinking. The other parts are you have to now figure out how do you optimize the deployment cycles, the test cycles and other things on the operation side.
Kanchan Shringi 00:25:22 Let’s now spend some time in how you talk to the team. How do you coach the team? What are you hearing from the team as everybody is using more of AI Perhaps could you share an example of a specific one-on-one where AI changed the conversation in some way?
Sonali Varde 00:25:39 Yeah, I had a skip level one-on-one with somebody who had just joined the team very young early in career, and we were just having a conversation of how these new AI tools are helping. And one of the questions very organically came up was, hey, how do you get evaluated? And I talked about you know the metrics that I get evaluated on because this is a new engineer, he wants to know how his skip or whatever gets evaluated and their performance reviews and stuff, which I thought was a very nice question to ask. And I talked about the fact that from a quality perspective I get rated on triage rate of our team and this person asked me what is that metric now? And I said, looks like at our triage rate across all the teams that report to me seems to be five days. And he was, why is it five days?
Sonali Varde 00:26:35 And I’m, because we have this process and this process and then it goes through all of these steps and this person went back, looked at all the flows and actually built a triage agent that reduced our triage time across all the tickets that we had to nine hours, right? And just the realization that I had was having just a conversation on something that I got evaluated on and what the published metric was, someone was able to think about how can we make that better, right? And it’s not that we didn’t have triage tools before. We did have triage tools. They were very text-based triage tools. This person was able to figure out how do we add visualizer to this triage tool? What kinds of other things could we add to make this much better? And so, I feel some of these conversations and one-on-ones have changed. It’s also upleveling and inspiring other people on the team to think bigger and the things that they didn’t think about were possible before everybody feels now that things are possible or at least making an attempt to make them possible.
Kanchan Shringi 00:27:51 So this is certainly a very positive example. Have you had any negative interaction on the use of AI? I mean there’s certainly a lot of negative emotions associated with it as well.
Sonali Varde 00:28:03 Yeah, of course there are negative, right? This is at the end we are actually building software. There are a lot of things we also go through where we have made mistakes as humans, right? I have written code in production that caused a production issue when I was a junior engineer and had those things definitely happen. One example that I had was we tried to integrate an agent within our on-call alerts and I got paged at 3:00 AM for this particular alert and I tried to use the agent to debug it and the results were so all over the place that for almost an hour I felt I was misguided by its investigation because of the hallucinations that the agent had and not understanding the system. And I literally had to say, okay, I’m not going to look at this output. I’m going to use my first principles thinking and I’m going to go through the stack one by one to figure out where the problem is. And I think my engineers are also facing some of these things. There is a chance that there will be things that are not good and you have to constantly challenge things from a first principal basis. Don’t just take the output of the agents and assume that it’s all the greatest output. Use your first principle’s thinking, your systems thinking, especially if you’re working on critical systems, critical problems, they have to have a certain level of rigor, and we cannot lose this first principal system design way of thinking about some of these outputs.
Kanchan Shringi 00:29:47 So with that, with coding becoming faster, with designs, outputs becoming potentially faster and you mentioned review is critical noise review the new bottleneck, do you have to really treat that as a very first class work instead of something I believe, you know, we’ve thought of engineers do reviews also.
Sonali Varde 00:30:11 Yeah, actually we’ll talk about a funny situation where I mentioned to one of my senior most ICs how the joy of coding has come back in manager’s life and this person says, and the joy of code reviews is taken away from my life. And so, it was a very funny banter, but you are spot on. Reviews are the big bottleneck right now. There is a lot and lot of pressure on senior most ICs to make sure that they are holding that gate and the bar and the guardrail and figuring out what level of automation is needed so that reviews don’t become a bottleneck because the expectation is that we will have meaningful impact with lot more experimentation, lot more throughput. And so right now one of the biggest challenges is figuring out the reviews, the deployments, the testing cycles, how do we do meaningful innovation on those aspects of software development and test life cycles so that we are shipping scalable products.
Kanchan Shringi 00:31:21 So at this point in time, do you see real evidence that the same team can do more or has the work really shifted into figuring out how to do better reviews and provide oversight and validations?
Sonali Varde 00:31:37 I’ll tell you the things that I feel have become easier to build. I think operations, when you are building APIs, you always have this create, read, update, delete kinds of Crud APIs, right? Building those things has become really easy. There are things within the system design of something like oh this needs an offline compute, this needs some kind of a nearline thing. This needs like a Pub/Sub architecture. All of those parts of the build, that design thinking, that upfront thinking about how do you want to think, how do you want to break out certain architectures? I do think that that, has given us more time to think about some of the things up front and it has helped with reducing this Crud kind of work that we used to do. I think even in the review side of things, I will say that we do have automation review stuff, which does a great job on like the Crud APIs and those reviews, right?
Sonali Varde 00:32:41 The reviews where things are a little bit complicated are just the context of the whole architecture and stuff. So, I do see the build velocity has gone up. I think the testing deployment infrastructural side of things are the ones where we are still not seeing as much gain. It’s helping with debugging I would say, right? When you are doing some offline compute, if your data jobs or whatever are failing, we definitely have AI helping us debug something faster than we would’ve done before. But that’s an area where it’s not like it understands our own data, data lineage, data policies and things like that. So, we definitely have not seen gains in that area. But Crud side of things we definitely have seen a lot of gain.
Kanchan Shringi 00:33:30 Are you measuring productivity? I have heard of token usage discussed as a metric. Is that useful or is that really, really measuring effort and activity? What are the metrics are you using?
Sonali Varde 00:33:45 We’re going through a lot of different ways of thinking about developer productivity. I think for adoption and usage we definitely look at token. Again, token usage tells you that everyone who is adopting is figuring out whether to use it in a plan mode, whether to use it in an execution or an agent mode. And so, it tells you a little bit of the adoption. I will say the other parts of the metrics are how often is your trunk getting blocked? You know, how often are PIs getting reverted and things that. So, all of those metrics are something that I am actually pushing the team to start measuring, right? And not just have the token usage. Token usage kind of tells you a little bit more horizontal adoption metric if you will, but not really a throughput metric. And so, the throughput metric comes with the number of experiments that the team is able to do, the number of initiatives the team is now able to shift, the number of times that has reduced self-inflicted incidents if you will. So those are some of the metrics that I am pushing for because that actually give you a little bit more about the system health.
Kanchan Shringi 00:35:06 You also measuring just how much of the code is written by AI at this time?
Sonali Varde 00:35:13 We do have all the adoption metrics, have the lines, AI produced lines of code token usage, like you said, all of those things are definitely part of the adoption metric of the team. The system metrics and stuff are also something that I’m keeping an eye on, right? Which is making sure that with this AI metrics going up, the system metrics can’t go down. They have to stay complimenting each other.
Kanchan Shringi 00:35:41 So I’ve also heard about people saying we are now shipping more story points in which category does of metrics for you Does this fall under?
Sonali Varde 00:35:50 It falls under the number of initiatives the team is able to ship, right? When you talk about the number of story points, what were story points? Story points was our estimates, right? As developers we were always optimistic. We would give some estimates and say that oh we will be able to deliver 10 story points a week if you were a four-person team or something like that. And now you know with AI tools people get just come up with another estimate, right? I feel that guesstimate was also something that we never really understood very well. But I think right now I feel it’s a lot more concrete in terms of how much kind of actually gets shipped and rolled out to a hundred percent right? And that is really the meaningful impact rather than uh, just looking at kanban boards and looking at story points and velocity and story points. I think those were all measures for us to be able to flag risks early on. But I feel the number, the OKRs that you take on as a manager to whether it’s product OKRs or engineering OKRs and how many do you ship and roll? 200% production is the new way of measuring the throughput.
Kanchan Shringi 00:37:13 So while we’re on the topic on the craft, I want to ask you about the methodology. You did talk about the fact that you do have story points measured today and combined for certain use cases. Is the methodology of Agile Scrum that we have followed for the last several years still relevant in the age of AI. What do you see as of now? What do you think?
Sonali Varde 00:37:37 I think it’s changing even with Agile, right? Every team used it in their own different ways, right? Some teams still did a lot more waterfall up front thinking and then only when it went into the build cycle did they follow some Agile practices. In some cases, I come from startups and I remember we did everything from Agile, right? Your product design engineers, everybody was thinking about story points. We didn’t even know what MVP was going to look. And so, I feel all of these Agile practices that are there before they are still going to be valid in terms of how teams curate them for their own use cases or outcomes that they want. I would say one thing that will change is everybody will be a builder now, right? So before in your Agile teams you had PMs and designs who were doing certain aspects of the tasks, but they were not building with you together. But now those boundaries are gone. They could be building with you; they could be writing let’s say product policies and things within the code themselves. And it’s not you have to translate it in some ways. And so, I feel now the story points are even going to be a bigger set because it’s going to be augmented with all the different job functions together than some of the ways we are only engineers. Were part of that story point calculations.
Kanchan Shringi 00:39:16 Interesting. So does that you believe change the composition of the team itself?
Sonali Varde 00:39:22 I think it’ll change. It’s not changing yet, but if I look at what I am seeing now, I do believe that you know in a year or two the boundaries of who builds what is definitely going to be changing. And so, the composition of the Agile teams will change. The compositions of how we build and ship things will change and how we actually use things will also probably change.
Kanchan Shringi 00:39:52 So perhaps that’s a good segue into hiring and onboarding with AI, you are looking for different things when you are hiring.
Sonali Varde 00:40:02 I think in terms of our modules that we use for hiring, the only one that we have added is AI native module, which is what somebody’s ways of using an AI tool while they are thinking of solving a problem. So that’s the one change that we have done. Again, the way to kind of grade this module, we are learning and calibrating amongst ourselves as we kind of understand different people and different people’s ways of using that AI tool. But that’s one change that we have started to take into consideration. I think the other part is I do spend a lot of time in my interviews, which are a lot more communication wise on somebody’s curiosity and adaptability and willingness to learn any new skill. And it doesn’t matter whether it’s related to coding, debugging, just being a team player, right? I think those are some of the things that I have started to ask a lot more questions on than I would before. So those are the changes that I’m doing in hiring side of things. In terms of onboarding, again, we used to initially have these onboarding tasks were very simple tasks, right? Hey, after your dev bootcamp just pick up one or two backlog bugs. But now those bugs have become smaller automation tasks, right? So, in terms of how we are onboarding, we are actually onboarding by doing a lot more than what we used to have as onboarding tasks before.
Kanchan Shringi 00:41:47 Do you have expectations around new hire? Do you set expectations around what is acceptable AI use and how should they consider security and even ownership of the output?
Sonali Varde 00:42:01 In terms of onboarding, we still use the same 30, 60, 90-day template of what is expected out of your performance at the end of 30 days, 60 days, 90 days. In terms of AI adoption, again, I said, in the first 30 days, I’m not looking at them as power user, but at end of 60 days I’m looking at them to be wide and using all of the AI tools that the team is using, right? For doing whatever task at the end of 90 days, you definitely want them to take ownership of the outcome that they are producing, right? And so that’s something that I don’t think has changed because of AI. I think it’s just the fact that you want them that maybe the complexity of the task has become a little bit bigger of what they own. But I think my expectation is that at the end of 90 days, you should feel you’re part of the team and you, whatever you build, you own it. And it’s something that you will continue to take the ownership for.
Kanchan Shringi 00:43:08 When hiring, and you did talk about everybody on the team becomes a builder, we’ll continue to look for specialists perhaps in, you know, in their different areas, perhaps specialists in architecture, specialists in platform support or UX.
Sonali Varde 00:43:22 I think I will. I think each of the job functions brings a different creativity to the table. And so, it’s very important that you have a team that has those creative thought processes. I said, I come from backend engineering and there are a lot of times when I actually don’t difference between square corners and rounded corners, right? But I have engineers on my team who have that UX specialty who are able to see these things and can actually say, here’s what a world class UX looks. And so, I do think that there is, the specials part of it is still very, very important because our human judgment, our human way of evaluating what good looks, what fair looks, what great looks cannot be taken over by an agent, right? And so, I think even when I’m looking at architects, I mean there are still so many times where I get called into the architecture reviews and I’m blown away by some paper that they will talk about or they’ll talk about here’s how we should be scaling or here’s kind of what the new GPU map looks.
Sonali Varde 00:44:33 And so I do think that there is that specialty of architects and the experience and things that come with experience that is important in a team and in building a successful team. So, I would say that you know, all of those specialties exist
Kanchan Shringi 00:44:54 In my mind that does match with your earlier comment that while AI can help you with a lot, you still have to have that understanding and the specialized experience does help you with understanding is probably your point.
Sonali Varde 00:45:07 Yes, absolutely.
Kanchan Shringi 00:45:09 Let’s start to wrap up now. And my first question as we are trying to wind down would be, you’ve talked about how AI has changed your day-to-day, some of your discussions with your team, the work done on your team. What about your peers and your manager? How has AI changed that interaction?
Sonali Varde 00:45:30 I think one good thing is all of my peers and managers, we all participated in that hackathon and went for a manager coding camp. And I think that set the level of, hey, here’s kind of what we can do together. Oh, here’s something that I can do now more. Or the whole exchange of thoughts and what we could do really, really helped. I think I mentioned this to somebody recently. What makes us managers in technology is because we were technical leads and technologists before, right? And so right now we need to go and explore that part of the technologist or the tech lead that we used to be by actually using these tools, by actually doing some of the tasks that are on your team’s plate and getting that level of understanding so that you actually can have good conversations with your leaders.
Sonali Varde 00:46:30 You can have good conversations with your peers. You can figure out what is possible and what is not possible. Are we all having the same problems of code reviews or deployments or whatever else, right? we can share and gain from each other. And so, if there is one call to action for any of the engineering managers out there is don’t have this anxiety because of AI about your job, just learn by doing it. You don’t need to have the same throughput as your top-class IC on the team, but you should learn so that you can walk in their shoes, you can have empathy to their problems, and you are the spokesperson for them.
Kanchan Shringi 00:47:14 Is there anything you’d to share about any postings you follow, any people you follow or any podcasts that you follow? How do you keep up with what’s changing every day?
Sonali Varde 00:47:26 I actually just listen to, I think the Anthropic’s engineering blogs and stuff. I will be honest, I don’t listen to a lot of podcasts, but I’m always looking at what Anthropic is doing in terms of their technical evolution and stuff. So that’s one thing that I definitely keep up with to understand. I do attend a lot of, I don’t learn by watching training if you will. I like to do, like dabbling and get stuck and figure things out rather than somebody shows me how to do it. I don’t think I learn through watching YouTube videos or just taking a learning course or whatever. I do a lot of things blogs and tech blogs, reading,
Kanchan Shringi 00:48:16 Anything we missed that you’d to cover. You had a very specific call out to all managers as you know, actually try the tools that your team’s using. Anything else you’d to talk about?
Sonali Varde 00:48:26 I think outside of that, I know that there is a lot of anxiety, lot of fear going on. I think one thing which truly comes from my experience is to keep the human aspect up and running. Make sure that your human judgment is going to be supremely important in the products that you build. And so, it’s important that you don’t get carried into this thing, that you lose that human judgment, human intuition, ask a lot of questions, build the muscle to examine things deeply so that you are also growing in your own understanding of how you should be building, how should you think about the business, how you should think about adoption of the products and platforms or scaling. But that’s the only other thing that I would say be human, be empathetic. Use these tools. Don’t get carried away with this anxiety and what you hear outside.
Kanchan Shringi 00:49:30 That’s nice to hear, Sonali. Not said enough, I think. How can people follow your work or get in touch?
Sonali Varde 00:49:36 Yeah, they can add me on LinkedIn. LinkedIn is a platform that I use a lot to connect to all professionals, so we’ll be very happy to connect with people who want to get connected.
Kanchan Shringi 00:49:48 Thank you so much for coming on the show and sharing where you are in the journey. I know it’s early, but sounds like there’s a lot of learning that you have shared here. And good luck as well.
Sonali Varde 00:50:02 Thank you.
[End of Audio]