How to Create High-Impact Development Teams

Today’s high-growth, high-scale organizations must have well-rounded tech teams in place -- teams that are engineered for success and longevity. However, the process of hiring for, training and building those teams requires careful planning. Tech leaders must ask themselves a series of questions throughout the process: Are we solving the right problem? Do we have the right people to solve these problems? Are we coaching and empowering our people to solve all aspects of the problem? Are we solving the problem the right way? Are we rewarding excellence? Is 1+1 at least adding up to 2 if not 3?

As someone who has built software development teams within large organizations (including Amazon and Microsoft) and startups, I’d like to offer three best practices for constructing your high-impact development team.

1.  Determine which problem(s) to solve for your customers

Understand the customer enough so that you, and each of your team members, can represent the customer. The onus is on you to innovate on behalf of your customers, without requiring them to outline the problems for you.

When thinking of problems to solve for the customers -- don’t constrain yourself by the current resources. A poor path is to first think of solutions based on resource limitations and then find the problems that fit those solutions. An even worse path is to lose track of the problems and simply start implementing solutions because “someone” asked for it.

Instead, insist on understanding the actual problems/pain points. Development teams who understand the problems often come back with alternate, and better, solutions than the initial proposed ones. A ride-hailing app could be built simply because building mobile apps is cool, or because someone wants to order a taxi using an app instead of a phone call. Here, the “problem” is that such a solution doesn’t exist.

Instead, understanding the root problems -- for example, that customers find the uncertainty of arrival time and waiting at the curb as painful -- will help your team build not just a ride-hailing app that transmits the request to the provider, but also real-time location tracking. After all, that was the actual customer pain point, wasn’t it?

2. Gather the “best” talent to solve those problems

What is “best” though? The exact technical skills depend upon your problem domain -- but one fundamental trait of “best” people is that they don’t just solve today’s problem. That’s just the sprint.

What about the marathon? Look for people who are capable of actually identifying future problems and are “passionate” for solving such problems for the customers. You want people who are driven by impact and who are not held back by constraints of resources in a startup or bureaucracy in a big company. People who take ownership of delivering the results to the customers as their personal mission, assume long-term success, and build solutions with the mindset of eventually achieving that broad success. It becomes a self-fulfilling prophecy, really.

3. Empower your people -- no matter where they are located -- to collaborate, innovate and solve problems

So, you have a good set of short and long-term problems and a great team capable of solving those problems. What’s left? Well, letting your people do it. Point them to the right problems, set the pace and expectations, ensure they are competing against your external competitors and not against each other, and lead from the front or the back depending upon your style. Just let your marathon team run and trust that they’ll deliver the results. Don’t let unnecessary bureaucracy or processes or hierarchies become roadblocks. Handle these hurdles yourself if you need to but clear the way for your high-powered team.

A special note about today’s world of globally distributed talent. Awesome talent is not limited to any one geography, so it is natural that one might have teams in multiple locations. In each of my jobs, but especially when I was at Amazon and eBay, I worked extensively with geo-distributed teams. I learned not to create a “main” team with satellite “remote” teams. I gave each of my teams a “charter” -- a set of short/long-term problems with high impact, a minimum size of team to solve those problems, and then independence and trust to execute. I treated them equally regardless of where I happened to be located. And, the results were so impressive that each of these offices/centers/locations often joked that they considered themselves as the “headquarters.”

The above guidelines are not exhaustive but can be thought of as mile markers along your own team building, problem-solving marathon route. Once you are past these, you’ll find more challenges to tackle from speed vs. quality tradeoffs, to scale, to recognition and incentives and so on. But like a marathon, focus, preparation and consistent progress will push you across those milestones and toward the finish line.

Ashish Aggarwal, co-founder and CTO at Productiv, is a hands-on technical leader with 20+ years of expertise in software planning, design and implementation with high efficiency and quality. He has built and led multi-disciplinary teams of up to 125 engineers, program managers and senior managers across three countries. Prior to Productiv, he served as VP of Engineering at Postmates, where he led the worldwide engineering team. Before that, he held director of software development positions at Amazon and eBay. He has also served as Principal Engineering Manager at Microsoft.