This is simple leadership. Welcome.

We’re here to learn from new and seasoned technology leaders who all share a passion for improving the craft of technology management. Let’s take a deep dive into management, leadership challenges, and best practices specific to software engineering and technology teams. Do you want more engineering management, leadership, tactics and information.

subscribe@simpleleadership.io to receive the latest updates from this podcast. Hi, I’m your host Christian McCarrick. This is the simple leadership podcast. Welcome back.

Christian McCarrick: [00:00:31] Good afternoon, Ashish. Welcome to the show.

Ashish Aggarwal: [00:00:33] Thank you.

Christian McCarrick: [00:00:34] Yeah, absolutely. And I’m glad that we have not met before, and I’m super happy to have this conversation with you today.

I’ve been looking forward   to it for a few days after kind of researching and prepping and looking at your background. I think we’re going to have a great show and lots to talk about today.

Ashish Aggarwal: [00:00:46] I am glad you feel that way looking forward to it. Okay, excellent.

Christian McCarrick: [00:00:50] And where are you connecting from today Ashish?

I am in Palo

Alto.

Okay, good. Yeah. I’m in the East Bay area. So fairly clear skies today and we’ve been having some smoke and issues. So it’s a nice warm sort of fall day here in the San Francisco Bay area.So great.

Absolutely.

Ashish Aggarwal: [00:01:04] And we are all very glad to see clear skies now.

Christian McCarrick: [00:01:06] Yes. Yes. You can get very meta about that statement, but physically, at least right now. Yes. Clear skies. As I ask a lot of my guests. If you could just give my listeners a little bit of context and background, basically how you got to be where you are today.

Ashish Aggarwal: [00:01:20] Sure. I am currently the co-founder and CTO at productive. We started this company two and a half years ago, currently about 50 people total in Palo Alto headquarters in Palo Alto.

Before this I’ll just go in reverse sequence here. I was the head of engineering or VP of engineering for Postmates. Postmates is on demand food delivery company. I hope you, and many of your listeners customers recently, it was acquired by Uber, but I was there for approximately two years. In San Francisco.

I had a great time there. We can talk more about it later. Yeah. Before that I was the director of engineering for Amazon in Seattle. My teams were spread across three countries, you know, us, Canada, and India, but I was personally based in Seattle building a logistics software technology for Amazon to move their freight.

The big trucks that you see on the highway with Amazon prime on the side. My team is partially to blame for those, or at least that technology part of those. And a couple more things before that, my brother, my first gig in e-commerce was at eBay. I was a director of engineering. They’re building a again, technology for their shopping cart, checkout, data analytics, those kinds of things.

It was an amazing experience with what hundreds of more than a hundred million customers. That Eva was handling at that time. And I spent a lot of time at Microsoft before that I spent about 13 years actually at Microsoft building enterprise products for them, the latest, I guess, reincarnation of what I worked on is called Microsoft teams or Skype for business before this, that you might’ve heard in audio video conference and chatting product. I was in some sense, the first engineer on that whole area, back in 99, when I joined they kind of said, Hey, we don’t know what exactly we’ll build, but here start exploring something. And I was feeling obviously junior back then, and still are a lot of stories to tell from Microsoft.

And a lot of my career learning and in sometimes growth as we call it happened there from a engineer to a senior engineer, to a lead and to manage it and indirect and so forth. Well, that’s kind of me. I am an engineer from education and throughout my career, I haven’t switched. But that’s my journey from Microsoft to eBay, to Amazon, to Postmates, to productive now.

Christian McCarrick: [00:03:42] Great. And a great kind of journey. I think it is taking into where you are today. So thank you for sharing that you did touch upon one thing, which I always ask a lot of my guests is. And you said it’s sort of happened at Microsoft. What was that transition from that lead or the IC role into manager like for you? Was it sudden, was it planned? How did that go for you?

Ashish Aggarwal: [00:03:59] It was actually, I don’t want to say natural, but it was almost smooth in some sense, right. There was not like a step function and the way it happened really was, and I thanked my leaders and Microsoft for doing this in this fashion. Is, I was an engineer, turned out I was a good engineer.

And so eventually when more junior engineers joined the team, I started looking over their work and guiding their work to make sure it’s to my standards or just watching them. And so I became the senior engineer for a few people. Yup. And then soon enough, they said, well, why don’t you formally kind of become a tech lead for this was like, in the sense that we will hold you accountable for the quality and the completion of the work in a given time.

And because I was working so much with these engineers, When the time came to kind of write the performance reviews and when the time came for them to kind of say, “Hey, how do we grow into our career to become a better engineer in both sides?” They were talking to me, but the engineers were talking to me as well as their managers are talking to me to get performance feedback.

And then one fine day, somebody said, “Well, it looks like you are going to be their people manager. You might as well take the title”. Oh, can you do this assertion? There was no scare factor in sometimes I was already doing the job. Yeah. And that’s when one of my senior leaders kind of said, “Hey, this is really the best way that I don’t have to anoint you” kind of, as the cliche goes, leaders are not anointed.

Leaders are formed when they are around people that are following them. Since I had followers, I was a leader and leader and people manager are two different things. I understand that. But in that people management, I already had direct reports. They were just not on paper. And so the formalization was smooth in that sense.

Yeah, no,

Christian McCarrick: [00:05:47] that’s good. Yeah. And it’s always interesting to hear the origination stories of how people and they went from that IC role and how they got into the manager role. And it’s kind of part of why I do this podcast to show a little bit too, that there’s lots of different paths to get there. Lots of different paths to starting a company, to be co-founders, to be leaders, to be VP of engineering’s and it’s however you get there.

I think it’s interesting for people to understand that what it looks like for one person, it might not be the same for another, and we all can get there through varied paths. Right. So thank you for that. Yep. Um, one of the things also is, and it doesn’t have to be at your first job, but over the many years now that you’ve been managing and leading teams, any mistakes, you make that point out that might’ve been sort of a learning lesson for you or for that other managers also might learn from.

Ashish Aggarwal: [00:06:30] Oh, boy, this is an interesting question because I’ve made a lot of mistakes, right? And I, yes, I’ve had a lot of success stories. Sometimes we talk more about them, but mistakes is what you learn from, and that’s how you really grow. And I’ve been doing this for a long time. At least the people management part of it for, I would say a good 15, maybe more years.

What are the mistakes that people can learn from? Let’s go couple of, maybe these are obvious things, but let’s, let’s see them right. Army manager. I made the typical mistake of not letting go, not actually trusting my team to take control. I was still this, Oh, you know what? This is me. I’m accountable for the whole thing.

My team is my helpers. I am still the smartest person in the room. And that was obviously not true. I was actually very lucky that my team was really, really capable junior that’s. Okay. But the collective capability obviously was much, much higher. Right. Everything had to go through me and she was interviewing every document for the last line of the design to every line of code to testing it himself.

Everything was because I was like, Hey, it’s my ass on the line in some sense. And then I don’t remember exactly who said it, but variety of my team and my superiors, my coaches told me, you know, your team can run much, much faster than this, and we understand you’re new, but letting go and understand it’s hard, but try it.

Why don’t you try it to save space, see what your team does. If you just let them be, just give them the problem and let them come with the solution. And they might surprise you. And I started doing that and, oh boy, that was eye opening. And from then on I have learned this. And unfortunately I did not have to be a large cost in this lesson because this was early days and there were supportive people around me.

But I will say that is something that I see a lot of new managers do at any level. Right. It’s not just when you go from an IC to a manager with the same thing, when you manage it to a manager of managers or VP or whatever, Letting go saying, “Hey, I will let my team solve this problem, even though I have good ideas about it, I can give input, but let me give up control.”

So I think that is one mistake that I see a lot of managers make everywhere, small companies, big companies, different levels.

Christian McCarrick: [00:08:46] Definitely.

Ashish Aggarwal: [00:08:47] Yeah. If I may share one or two more, the other part is about team building, right? And again, these are known things in the industry, you know, it’s better to hire one A-player than two C players.

And again, I have done that sometimes without knowing it, but then after I have done it, I realized later on how to distinct was sometimes I was, I just got frustrated with, because there was a position open for so long. I was like, let me just get somebody in here. It’s okay. If they’re a C player, I know it, but let me just kind of get things started right on the Workfront. And then I had to pay the price later on. They were not happy. They did not gel with the team of A-players and so on, so forth. And then eventually they had to go. And that was a painful, painful breakup in every case that has happened. So if your team is of A-players and your philosophy is to hire A-players and I’m watching this, the only thing that everybody should have, there are circumstances and different needs, but.

If your philosophy is to hire A-players, then take the time, hire the players. It takes time. You will have to be patient. Anytime I lost patience, it was a mistake and I paid for it. And similarly on the flip of it is when you know somebody’s not the right fit for the job. You know what, don’t drag it out. I dragged it out a couple of times.

Obviously there are situations where there is a temporary thing and can be turned around and those help. But my mistake was even when I knew that him and this person is not the right fit for this job, they will be probably a better fit for some other job in another team or with another role or another company for that matter.

I knew it. I honestly knew that it’s only a matter of time before I’ll have to pull the plug, but I just didn’t because I was uncomfortable. It was hard to give that message. There was confrontation. I was avoiding that. And again, it took some coaching from my superiors. This part actually gets harder as you grow because the person you’re sending the message to is usually more senior.

Christian McCarrick: [00:10:52] Yeah, exactly.

Ashish Aggarwal: [00:10:53] And the key thing you need is, is the support and a safe space from people around you, your peers and your managers to say, “Go ahead, make the decision.” It’s okay to have tough conversations. It is actually going to be good for both the company and the person concerned,

Christian McCarrick: [00:11:07] RIght. And the team itself.

Ashish Aggarwal: [00:11:09] Right.

Christian McCarrick: [00:11:10] You know, that’s another thing because it starts off with the one hard conversation. But if you lead, let it drag along enough, it can turn into five or six hard conversations and your team might lose some of that trust. And I like what you said though. That resonates with me. It sort of by the time, you know, like if you have something, if you have an inkling even do managing for a little while, like clearly you want to look and investigate all of the reasons to make sure there’s no snap judgment of, is there any bias or anything, but usually I think it is true that if you have something, you know, then it’s at least worth that conversation it’s at least worth diving into and sooner rather than later.

Right. So, yeah.

Ashish Aggarwal: [00:11:44] Absolutely. Absolutely. So those are the three mistakes that I can relate. There are actually a lot more, but let me pause it.

Christian McCarrick: [00:11:51] Absolutely. And that’s good for that. I appreciate those. We all make mistakes. I know it’s usually just which one of the many ones that we choose from, but like you mentioned, also the mistakes are opportunities to learn and that’s kind of why I do the show and why I have experienced tech leaders like yourself on to kind of help guide those maybe are not as senior or even there are a senior, but we still can all learn from each other.

One of the things that I want to talk to you about and kind of spend the rest of the time when the show is talking about something that I think you’re passionate about engineering your teams for impact and focusing a little bit, why that should be your team should be focused on the marathon and not the sprint.

And one of the things I want to start with this is. Let’s start with the vision of what good looks like. So if you could help me paint an ideal picture for my listeners, what does a well-rounded high performing team look like? Like how do you know that if you see one?

Ashish Aggarwal: [00:12:38] I have seen high performing teams work with me and around me. There are a few characteristics that show up and they’re all interrelated, but I can tell you what things show up. The obvious thing that shows up is competence. The skill, like people are really skilled in whatever job they’re doing. Like in engineering teams even are technically very talented. I mean, you can’t have a high performing team without core capabilities, whether it’s whichever role the team is playing.

But beyond that, you know, passion shows up, you will find that I don’t have to ask people to solve a problem if a problem needs to be solved and they know the solution they will solve it. They’re self-motivated, I’m not kind of going around ripping people saying, “Oh, what was not done today?” A standup or a weekly thing status is more of them just telling, Hey, what’s going on rather than being a documentary proof that I was actually productive this last week. So self-driven part comes in, A-players attract other A-players.  The team gels very well. When I talk to people in a high functioning team, they don’t talk about that.

I’ll say, “What are the issues we are having?” Very seldom do the talk about people being, you know, am fighting this person or that person doesn’t help me out. Blah, blah, blah. They don’t talk about people. They don’t talk about as, as problems or consent. They don’t even talk about processes. They talk about problems, customers’ problems. Every time I have an engineer or asking me, “What is the next big problem I can solve? Because I know you think I’m busy, but you know what? I think I can handle more. Just let me know what is the next big problem?” And I say, “This is a high functioning team,” his or her biggest concern that they want to ask.

Yeah, VP or whatever is I want to solve a big problem and let me, you know, ask what he, I want to raise or I want more titles or what have you. They just want to solve big problems because that’s what they say around them. And let me finish it by the biggest thing that kind of gets into just delivering results, which is obvious, but taking ownership to me, taking ownership is kind of the culmination of all of this.

People are not just solving problems. They are actually identifying problems. They are defining problems. I don’t give problems anymore to my team members, especially if they’re senior enough, I pointed them in a certain direction and they come to me with saying, Hey, she actually, you know what? There are 10 things that we need to do here.

Five of them will be directly customer impacting to get to those five. And one is maybe infrastructure or process or what have you. But we need to do these 10 things. Here’s kind of my ideas about this. Here are the things that I don’t have the expertise for. I need you to kind of find me the talent or the support for this.

They come to me with a plan. My job is, well, you kind of have a plan, let me see how I can put things around so that we prioritize this. And so the problem was identified by them. The solution was identified by them, the delivery of the results. They know what success looks like, and they are diving to get that done. It is amazing when that happens.

And that happens a lot, especially in Productiv now because they’re a small company, our interns take on and come back with problems and solutions to the extent of shipping things to the customer. And this is what I mean by running a marathon, right? When an entire team is the problem identifier and a problem solver, you naturally start thinking more.

The longer I can think about the longer run. Teams can think about the longer run. Sure. That’s what high performing teams look like, teams which take ownership or other teams in which every individual takes ownership of solving the customer problem and do. And that’s what a high performing team looks like.

Christian McCarrick: [00:16:25] Excellent. And now that we’ve painted that picture, which I agree with in a lot of ways, it, it just, there’s just something I’ve played sports teams and college and stuff growing up too. And there’s just something that gels, it’s something you can’t necessarily put your finger on, but you just know it. And you know, you’re part of it and it’s really amazing to be on.

And I feel that way too, when teams get that way. But for a lot of managers that might be listening right now, maybe their team hasn’t reached that level of maturity yet. What do you think? Because there might be getting frustrated, like everything else it’s we’re in this like instant gratification sort of environment today, but what do you think is a realistic estimate?

If someone inherits a team or they’re building a new team from scratch, like these high performing teams don’t just happen overnight, if you try to work on it, what do you think would be a good expectation from a timing standpoint, to really start seeing a team gel and come together and start performing, like you just mentioned.

Ashish Aggarwal: [00:17:14] Yeah, I’ll tell you, honestly, this is a tough question because the situations can be so different. I mean, I can not blurt out a numbers. There’s no formula for this, but I would say the answer is probably a few months. Now, if it takes close to a year, then we are doing it wrong. If it was done in three weeks, well then I don’t know if there was too much wrong to begin with.

Right. So if it’s a decently sized team and if it’s not jelling very well and not performing, there could be talent issues. Like there are talent gaps that we haven’t identified, we just don’t have big problems to solve their vision gaps. Right. There could be cultural gaps. The team is fighting against each other, other than the competition outside.

Right? I always tell my teams, the competition is outside this building competition is not called productivity is called something else. If you are competing with each other in a healthy fashion, that. Thank do we, you know, kind of in a funny way or in some other way, one of each of them that’s fine, but there is no competition amongst each other.

I’ve seen teams where the culture of collaboration is not there. Competition is there. Cut throat culture is there. And honestly it could be also, the managers have to look change starts from self first, right? Are they defining the vision? Are they letting these people–their team members–solve the problem?

If they don’t have large problems, are they asking their team members to say, “Find the three biggest problems” and are they trusting them? Everybody wants to work in a great team. Not for lack of intent or desire. No engineer comes and says today, “I will kind of add this note. Reasonably one comes and says today, I want to be inefficient.

And today I want to be in politics and whatnot”. They all want to make impact. I will say the honest path forward. Is really just to find what is broken by talking to the team, right? Whatever is missing. Yeah. I have asked sometimes my teams and they give me really good, bad directions to say, if we don’t have a good vision or we don’t have the right tools, or we are just missing this capability in the team, you keep asking us to do this.

We don’t know how to do this, or you don’t ask us enough. We have great ideas, but you just keep seeing your own ready ideas. I mean, of course we are limited. So in a typical team, I would say if you have to change people around, like if you have to get different mix of talent in, by hiring or by letting go, then it might take six months to kind of get to a high performing team.

If you already have the right talent, if you’re just fixing culture and processes, culture takes a little bit more time to fix. Honestly processes should not take that long to fix. So processes can be fixed fairly, fairly quickly. So I would say anywhere from one to six months, depending on how bad of a situation you are.

Christian McCarrick: [00:19:57] Sure. And to reiterate too, for the listeners, what you said too, is one of the paths to get there is asking your team, right? It’s not going to come from you. So like you mentioned. Make sure to wear your team, ask them, they’re on the ground. They’re the ones that might be blocked. They’re the ones that’s doing a lot of the work.

So you’d be surprised at how creative, as you mentioned, not only problems, but a lot of them probably have solutions. And if it’s a safe enough space, make sure you create that for them.

Ashish Aggarwal: [00:20:22] Absolutely. Absolutely. And let me add to that. Please ask them not just what is wrong with you guys. Please ask specifically, “What could I do better as a manager?” It seems to be is it’s okay for you to say, “Hey Ashish, you are doing XYZ wrong.”

Christian McCarrick: [00:20:40] Absolutely. I a hundred percent agree with that because part of the problem might be you, like you mentioned with one of your early mistakes, they might be afraid to say, you’re the one blocking everything.

I think we can move twice as fast. And maybe you don’t realize that because you have a blind spot. Right. So yeah, absolutely. Okay. Great. So one of the things too, and I think you’ve mentioned this in the past, but I see so many teams working on hard problems because a lot of times teams, like you mentioned, high-performing teams, they want to work on hard problems, but how do you help a team or how do you help the team decide what’s the right hard problems to work on? Like as a leader in an organization, how do you help provide guidance?

Ashish Aggarwal: [00:21:16] I’m going to challenge that a little bit. High-performing teams don’t work on the hardest problems. Right. High-performing team work on the most impactful problems and they understand the customer. The customer could be, there was a team which is working on solving the problems of fellow engineers or for the sales team or whoever inside of the company.

But that’s their customer. High-performing teams take ownership of the customer’s problem. And then they say, here’s the highest impact problem. And maybe for this solving this problem, the solution is pretty low tech. Maybe the solution doesn’t add too much to my resume, but the problem is not that I’m trying to estimate assuming the problem is I’m trying to have impact on my customer. And that’s where, when you say high performing high performing doesn’t mean that their performance was so well that their all resumes look awesome after, you know, whatever one year, but they have done some cutting edge technology and discover that a lot of them’s or whatnot.

No a high performance means that their customers say, “”Oh man, my problems are solved in record time. And in fact, these teams are solving more problems that I could have thought of myself, but you are the customers that representative in your team. So high-performance teams, when they start thinking in these terms and it comes from everybody, you are rewarded.

Yes, of course we appreciated that as a problem, which is very hard to solve. And so putting the right people around it and give you enough time to solve that. Sure, but we measure results by impact. We measure results by results in some sense, right? Not by the effort, correct. It’s irrelevant how busy I was, the only relevant piece is what impact did I produce or what I produce?

It’s not always, by the way, when I say impact, it’s not always dollars. It’s not always revenue. Depends upon the problem. It depends on thecustomer. Define what is going to help your customer and that’s what teams do now. And yes, high capability teams, what they do then is because they are free to define problems and think of the hard problems or think of highly impactful problems.

Yep. They know their own capability. Trust me. They trust in their own capability, much more than a manager does. And every single time my teams have outperformed what I thought they could do. Every single company, regardless of how much I believe in the team, they always surprise me. And so when I asked them to pick up the high-impact problem to solve, they were not shy of picking up a problem, which was very highly impactful, but I would have not did because it was very hard to solve. It was risky for me as a manager to come into that. You just need to agree that this is a high impact problem. And as long as we agree on that, don’t worry about it. We got this solving it. I understand it’s hard, but we got it.

We’ll do it. So then naturally then pick up the hard to solve problems as long as they are high impact. So yes, you do see hard problems getting solved, but it’s from the other perspective.

Got it.

Christian McCarrick: [00:24:17] No. Excellent. Yeah. And I appreciate that. That was good. And moving kind of to the marathon, not sprint topic. I mean, even mediocre teams are poorly run teams, rig you can potentially accomplish a lot of things in a short period of time, but there’s usually a lot of bad consequences that happen with that. Maybe burnout or lots of tech debt, but it takes a really good team to deliver consistently over longer periods while maintaining that team health and morale and everything else.

Right. So you’ve discussed this before solving short-term problems versus taking shortcuts. What are some of the examples you see of teams that take shortcuts versus long-term problems. What are some of those categories that you’ve run into?

Ashish Aggarwal: [00:24:53] So there is,there’s always a mix of tactical and strategic problems that you need to solve. And again, it comes down to what are you asking our teams to solve? Are you going to ask them. Every week, every month or whatever time frame about some tactical things that they have done. And because they’ve checked that box and the result is there to see, and they will naturally work towards solving the bugs or the asks from the, whatever the sales team, or if you give them space, if you say, “You know what, it’s okay to attack a very big high-impact problem and it’s okay to pick a problem.” They are not to deliver that impact of, they take you six months to actually write that up. All of that. It’s okay. I’ll wait for six months. I’ll give you the resources. I understand for six months. You will not ship a feature because you are building the infrastructure.

Christian McCarrick: [00:25:42] Sure.

Ashish Aggarwal: [00:25:43] And that’s what the marathon is. The results of that will only come maybe in six months, maybe in one year. In big companies, you can plan multiple years in advance in small companies. You don’t quite say, H””ey, this problem will be solved, which is the impact will be five years from now because you have plenty of problems, which are kind of low hanging fruit before that. The marathon really comes from sayin, “Hey, how are you just doing this thing to check a box?” Sometimes it’s time to fix up. Well, it was beating customers down. You need to stop the bleeding. So you put a band-aid and move on, but good engineers. Whenever we ask them, I went out, I asked them saying, “What is the right way to solve this? They will always come back and they’ll say, “Here’s a shortcut.

I can take that. You’ll be happy. You won’t know this.” The next engineer who comes in will say, “This is bandaid,” or three months later, “We’ll have to rewrite the whole thing,” but you know what? It’s going to be my fault then. People who take ownership. they say, hI’m not going to do the shortcut” unless there’s like super urgency.

I’m not going to take the shortcut because you are promising that the company is going to be around for the long time that my customer is going to be around for the long time. If I actually solve a good long-term problem for the customer, and I take the time to solve it because someone will be happy and I’ll be happy because my performance and rewards or whatever whatever’s in that culture is aligned with their not incentives that are aligned with solving problems, where we don’t need to resolve them.

Christian McCarrick: [00:27:00] But that incentive is not always the case. Right? So I think one of the examples, and I agree with you, but I think one of the examples is that lots of managers face I’ve faced is the trade-off discussions and dilemmas that you have, whether it’s a fundraising effort next rising a next raise of money or large strategic customer comes in and you’re getting some of the pressure maybe from above. And, you know, as you mentioned, being an engineers, this is the right way. But the right way might not be the way that gets us there in the time needed for something. How do you manage that? Is there a decision matrix you have? How do you handle those situations?

Ashish Aggarwal: [00:27:33] Yeah. Yeah. I hear what you’re saying. And I hear the, at least from my perspective, I hear the confusion. When I say, if you’re running a marathon, it doesn’t mean that, “Oh man, whatever I’m working on, don’t ask me for two years after…” When you run a marathon, you still run it mile by mile. There is a checkpoint by checkpoint, right?

Yeah. It’s just that you run it up passionate because you know that, you know, I have whatever 26 miles to go. You don’t just sprint to the first one and just blow yourself out and get to the a hundred meter line. And then you’re dead, right? When I asked my teams that we are running a marathon, I still say we need to deliver results one mile at a time.

We need to do things in a phased fashion. We just need to think maybe five miles, maybe all the way 26 miles ahead. That’s what running a marathon means. Right? You think of the long term, but you do execute in the short term. So the trade-offs we have to make short-term trade-offs we know that that this is a term trade off.

This is away suboptimal, what that we are doing for some special circumstance, right. That’s customer really wants it tomorrow. And they know that will kind of a half broken solution. And they will then be patient for us to build a proper solution in whatever three months then on whatever a fundraising thing or whatever, as long as the trade offs are deliberate, it’s okay, good. Yeah, absolutely. And when you start doing deliberate trade-offs, you’ll probably do the classic 20/80 thing. Right. You’ll make 20% tactical things. And 80% of marathon meetings and marathon meetings again don’t mean that they don’t mean slow. They just mean they will last for a long time.

Christian McCarrick: [00:29:15] Yeah. Got it. Excellent. Excellent. One thing. And we’ve touched about this before briefly. How do you go about ensuring that your teams maintain a deep technical excellence over time? How do you make sure that the bar is always high for bringing people onto a team and then that the team itself sort of maintains and then increases actually their technical excellence over time.

Ashish Aggarwal: [00:29:38] Yeah. You know, I might sound like a broken record here, but again, it goes from taking ownership, right? When my team members come to me and say, you know, we have identified this problem. I think I kind of know the solution. I don’t know how to implement it. I just don’t want that technology very well. If there is somebody else in the team who knows that, then I say, do you want to partner with them?

They will implement it, but you will learn it along the way. Because, you know, you are passionate about this thing. You want to be the owner of getting this thing to the finish line and they will say, “Yeah, absolutely.” Nobody says no to learning from others, especially if they propose the problem and the solution to begin with.

But the interesting thing that happens is a lot of times, especially in Productiv, I find people come to me with solutions. Yeah. They say, actually they come to me with problems. As they say, “we don’t know the solution. And actually we don’t know if anybody else in the company who knows how to solve this. What do we do Ashish?” I said, well, if we can wait to hire somebody, but we don’t even know to hire there, or why don’t you do the research? And then they find a technology or some solution, and then they say, “Well, it’s a new one.” And then they start saying these things now more and more, “Ashish, I need a couple of weeks to train myself on this thing. Then I need a couple of weeks to train somebody else on this thing.” And then they’ll do this thing because that’s the baby will go because they are just focused on that outcome. Right. They’re like I have identified a problem. In fact, I’m more deliberate. The only one in my way is myself. Let me say it another way.

The way you pose the problem is “It is my requirement that my team knows the latest technologies and are up to date on technologies.” And the way I am posing this back to you is it’s not my requirement. I’m not the only owner of this part. Why do we need people to be technically savvy and up to date with the latest technologies or keep learning?

Because it increases capacity increases our ability to solve bigger problems or solve problems faster. Well, whose problem is it? It’s not just mine. Yes. I happened to be the leader of the team, but it’s not just my problem. If it’s everybody’s problem. Then the solution is in front of everybody too, right?

Increasing their own technical capability to solve bigger and better problems is as much their problem as it’s mine. And so then once they take ownership of this part and my team members, I’m very lucky. They all do. So I have very, very funny opposite conversations with the team..,

It’s a technology

Christian McCarrick: [00:32:11] looking for a solution sometimes. Right? And it’s always challenging to do that.

Ashish Aggarwal: [00:32:16] What’s pressing them to some, I just need to sometimes bring them back saying, Hey, I know you’re passionate about it and you’re going to learn it. But you know what I mean? Can we put two people together and both of you learn kind of the similar technology, rather than both of you learning two different technologies for the solution.

I cannot mandate passion. I cannot mandate learning. Learning-passion for learning-of solving problems that come with that higher capacity that comes from inside from the team. I just need to hire the right people and I need to have the environment around them. Sure. That everybody’s in this culture.

Christian McCarrick: [00:32:52] Absolutely.

Ashish Aggarwal: [00:32:53] I tell you then things work on autopilot. I take no credit for this, by the way, things will come autopilot around in great teams and in performing teams.

I agree with that too, right.

Christian McCarrick: [00:33:03] Sort of build the environment, build them the space, give them the support they need. Give them the challenging environment and magic happens, right?

Not that sad, but yes. You know.

Ashish Aggarwal: [00:33:14] No, you said it right. Magic happens. You hire great people. You give them hard problems to solve. You actually let them solve the problems or maybe even better. You let them identify the hard problems to solve and magic happens.

Christian McCarrick: [00:33:28] So I’m going to flip this. I love that part of the conversation want to flip to this one next question, because you have direct experience with this. And I know I have a lot of listeners who work for some of the larger companies, Google, Facebook, et cetera. And they’re looking at maybe smaller companies, maybe a smaller startup, or maybe a mid startup. How would you advise managers coming from some of these larger companies today to be successful at a smaller company, maybe like a productive or something else where they’re coming from a Google or Microsoft, et cetera.

Ashish Aggarwal: [00:33:54] Sure. I love the companies. I’ve worked at a few of them.  But I would  say I loveProductive the most. And the reason, the way I tell people who are coming to small companies is you need to unlearn. I’m not pointing at any big company by the way, but you need to unlearn some of the things that in general, big companies kind of pitch you. This is the way to succeed. Right? Big companies sometimes teach you a waterfall model to succeed. Not my problem model.  X percent really define the vision. Y would you define the actual problems? Somebody else will actually make sure the customers use it. Somebody else will track it.

It works in a large team and a smart team. It’s funny. You actually get to solve every problem that you raise your hand. And in fact, it’s not just allowed, it’s actually expected that you really punch above your weight class. Lots of companies will, by definition will ask you to punch below your weight class because that’s safe.

We can throw money at the problem, right? If I need 50 engineers for something. I’m going to hire 70 because I can afford it. I, my main priority is to make sure that the project succeeds on time. Sure. You know, smaller company. If I need 10 engineers to solve something, I’ll probably hire three. Then I would say, go figure it out next, phase it out.

Let’s do what you can. But let me also remove the shackles, remove the politics and move the bureaucracy around. So when you’re moving to, from big to small company, be ready to take more ownership, ask others to take more ownership and expect that that essentially sometimes translation to be more hands-off right.

Understand the domain. You will not be spoonfed to a large extent, be ready to enjoy the shock of normal bureaucracy. When you think of something, you will be able to do it, you won’t have to kind of fill a form in triplicate and stay in your lane. Things like that are going to have to define your lane.

There will pronanly be no lanes. It sounds chaotic, but it’s that freedom is what gets the speed. If there’s an analogy I make me that helps me think a big company is a cruise ship. It moves as a lot. It takes a lot of time for the cruise ship to turn. If you will come in and want to turn a cruise ship, you will have to go through, you know, seven layers before you get to the captain and on the cruise ship and whatnot, which is fine because it’s a big cruise ship.

You can’t just really turn on a dime or do whatever you want, but it’s going in a certain direction. It has momentum and whatnot. Small companies are like a jet ski. Their super power is not their big size and momentum. Their super power is their speed and agility. Yup. Speed. As in how fast we can go in a certain direction. And as it is, if we can turn directions, both are very important.

So that’s the difference. If you are cruise ship, captain or manager, or what have you, once you jump to a jet ski or a speed boat, or what have you, that’s what you are jumping for. You’re optimizing for speed. You’re optimizing for making decisions without a lot of data you’re saying I can make mistakes and I can change my mind direction because we can do it very quickly.

So speed is what you optimize for. And is it, it is what helps you in kind of keep correcting your course and finally find your path. That’s what I would say. There are a lot more different things, but that is probably the biggest thing that I will say.

Christian McCarrick: [00:37:24] Okay, perfect. Awesome. And one of the, part of the show too, which I like to ask is. Any recommendations you have for a book, a podcast, a show, something that could be something you read 15 years ago that stayed with you or something you read last week that you find interesting.

Ashish Aggarwal: [00:37:39] Don’t have a podcast or even a book to recommend. And there are a lot of different things, but mostly the books that I read, advise me more about big companies, how to work in a very different thing.

Then I joined Amazon. Amazon has said “Here are our 14 leadership principles” and they are public. You can go read them on their website. And they don’t track them. But two of the most important ones I found were customer obsession and taking ownership there a lot more, all of them are paid by the way. Sure.

And honestly, personally, just for me, I thought I knew both of these. Hell I’ve been in the industry for, I don’t know, whatever, you know, 15 years or something like that before that I’m a director of coming from eBay. I was, you know, some senior person at Microsoft, blah, blah, blah. I know what thinking about customers means.

I know about what taking ownership means. Amazon just really taught me what these things actually mean. To the extent that after a couple of months, I was like, “Hell, I actually did not know these things.” Like you want to have a fit proposition. Wasn’t quite to my advisors. Go read those principles. See if you can find some things around whichever principle that strikes you as, Hey, you know, I want to learn more about that material on the internet to learn about that.

But dig a few principles and understand them deeply. And my two favorite ones are customer obsession and taking ownership, but understand them deeply. What do they mean? Customer obsession from the perspective of I’m not a company’s agent anymore. I am the customer’s agent taking ownership is not that I will complete my task, it’s about, I take ownership of that, of actually delivering the impact is or whoever the customer was. And even if I’m not doing all the work, but I will get it done and I will push for it. And I take ownership of the entire thing, including defining the problem if it needs to be.

Christian McCarrick: [00:39:28] Sure. Sure.

Ashish Aggarwal: [00:39:29] I have learned more from my peers, my seniors, my leaders in all of these companies and men in Microsoft and eBay and Amazon Postmates out in front of them finding those topics to go after.

So if there’s one thing you want to your listeners want to read, I would say go hit Amazon’s leadership principles.

Christian McCarrick: [00:39:48] Yeah. That’s why I love asking this. Cause there’s all different kinds of questions and it can go very meta. It can go tactical. So, yeah. And I’ll put the link to that in the show notes on simpleleadership.io as well.

So people can go kind of find that one last thing. What is the best way to people to contact you? Whether it’s about Productiv or just in general, they want to reach out to you. They have some questions or want to chat with you.

My email usually

Ashish Aggarwal: [00:40:10] is the best. Cto@productiv.com productive, just like the word productive with ‘E’ or without “E’, both should be able to work, but cto@productiv.com or LinkedIn. My name is Ashish Aggarwal.

Christian McCarrick: [00:40:22] Excellent. Excellent. Well, Ashish, we’re kind of coming to an end to this conversation. I’ve greatly enjoyed having this time to talk with you. I love talking with other engineering leaders. It always gives me some more motivation to kind of go back and be better for my teams and help to support them better. So I do thank you for your time this afternoon.

Ashish Aggarwal: [00:40:39] Thank you, Chris.

Christian McCarrick: [00:40:40] Thank you for listening to this episode of the Sempra leadership podcast, hosted by me, Christian McCarrick. If you’ve enjoyed the show, please subscribe and don’t forget to leave a review on iTunes, full show notes, and additional information can be found on simpleleadership.io.

If you know someone who would be a great guest for the show, or you want to share your own experiences, please drop me a line. We’ll see you back next week for more technology, leadership tips and advice. As I interview more top software engineering leaders. .