How do you build an engineering team of A-players? What does a well-rounded high-performing team look like? Why is engineering for impact more important than solving hard problems? In a world where engineers are looking to pad their resume and solve cutting-edge problems, Ashish Aggarwal shares the one thing that is far more important: solving your customer’s problems. In this episode of Simple Leadership, he walks through building high-performing teams, solving customer problems, and the best way to maintain technical excellence. Do not miss this one. 

Ashish Aggarwal is the Co-Founder and CTO of enterprise SaaS management platform, Productiv. Prior to founding Productiv, Ashish was the VP of Engineering at Postmates, where he built and led a team of over 130 engineers to develop all technology for the food delivery marketplace. Before Postmates, Ashish led product and engineering teams at Amazon, where he helped build and launch Amazon’s own Freight Transportation Network in North America, Europe, India, and China. Ashish has also held senior leadership roles at eBay, where he built the e-commerce platform’s checkout experience, and at Microsoft, where he built the enterprise conferencing solution, Skype for Business. Ashish holds a Bachelors in Computer Science from the Indian Institute of Technology, Delhi. 

Outline of This Episode

  • [1:14] Ashish’s background in the space
  • [3:46] The transition into a management role
  • [6:15] What Ashish has learned from years of management
  • [12:11] What does a well-rounded high-performing team look like?
  • [16:49] High-performance teams don’t happen overnight
  • [20:55] Solve high-impact problems—not hard problems
  • [24:50] Solve short-term problems versus taking shortcuts
  • [29:18] How to maintain deep technical excellence over time
  • [33:43] How to find success with a smaller company
  • [37:29] Amazon's leadership principles
  • [40:02] How to connect with Ashish Aggarwal

What Ashish has learned from years in management

Ashish notes that he made the typical mistake of not letting go. He struggled to trust that his team could take control. He admits that he needed to let go of the notion that he was the smartest person in the room. Once he realized that he needed to let things go, he stopped reviewing every document from the last line of the design to every line of code. What led to his change of heart?

One of his coaches told him, “You know, your team can run much, much faster than this and we understand you're new, but let go. We understand it's hard, but try it. See what your team does when you just let them be. Give them the problem and let them come with the solution. They might just surprise you.” Ashish notes that it was eye-opening.

He can now say, "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."

What does a well-rounded high-performing team look like?

Ashish states that the obvious thing that you must look for is competence and skill. You can't have a high performing team without core capabilities. But beyond that, you need a team that is passionate. You want to build a team of self-motivated players who see a problem that needs to be solved and will solve it. 

Ashish emphasizes that taking ownership is a culmination of all of this. He wants engineers that are constantly asking, “What is the next big problem I can solve?” Ashish doesn’t assign problems to his team members. Instead, he points them in a certain direction and they identify the problem. They identify the solution. They know what success looks like, and they are diving in to get that done.

When an entire team is the problem identifier and the problem solver, you naturally start thinking more long-term. High performing teams take ownership of solving the customer’s problem and do. 

Ashish has seen teams where the culture of collaboration is not there. Competition is there. Cutthroat culture is there. So the question must be asked—is the management defining the vision? Are they letting their team members solve the problem? Find what is broken by talking to the team. 

Solve high-impact problems—not hard problems

Ashish emphasizes that high-performing teams don't work on the hardest problems. High-performing teams work on the most impactful problems. High-performing teams take ownership of the customer's problem. The solution may be pretty low tech. Maybe the solution doesn't add to their resume. That doesn’t matter if the impact on the customer is there. 

High-performing doesn't mean that their performance was stellar or they worked on cutting-edge technology. High performance means that their customers say, "Oh man, my problems are solved in record time.” Impact is not always dollars. It's not always revenue. It depends on the problem. It depends on the customer. You should define what is going to help your customer and that's what your teams should focus on.

How to maintain deep technical excellence over time

Take ownership. If your team doesn’t know the answer to a problem or have someone to solve it, allow them to do the research. Find out what it takes. But it’s also not up to you to make sure your people are tech-savvy and up to take with the latest technology. Ashish firmly believes that it is everybody's problem.

“Increasing their own technical capability to solve bigger and better problems is as much their problem as it's mine...I cannot mandate passion. I cannot mandate learning. Learning—the passion for learning—and solving problems comes from inside the team. I just need to hire the right people and I need to have the environment around them.” 

Ashish is full of amazing insight into building A-teams in the engineering space. Listen to the whole episode to take advantage of his years of expertise in the field. 

Resources & People Mentioned

Connect with Ashish Aggarwal

Connect With Christian McCarrick and SimpleLeadership

Subscribe to SIMPLELEADERHIP onApple Podcasts, Google Podcasts, Spotify, Player FM, TuneIn, iHeart Radio

Rss Apple Podcaster
Podden och tillhörande omslagsbild på den här sidan tillhör Christian McCarrick. Innehållet i podden är skapat av Christian McCarrick och inte av, eller tillsammans med, Poddtoppen.