Qualities of Highly Capable (Software Development) Teams

I have been a member and/or leader of a dozen software development teams over the past two decades. Some of those teams were dysfunctional and some were phenomenally productive. Although, every team in every context is highly unique, I’ve come to believe highly capable software development teams share a few import qualities.

Note: When rereading this article, it was clear it doesn’t apply solely to software development teams. On the contrary, these same qualities were part of most teams I’ve been a part of over the years… the inspiring teams I was proud to be a part of. I expect these qualities are present in most teams engaged in a creative endeavor where personal skill, passion and creativity result in a new, highly-complex product. Since my experience has primarily been with software innovation, though, I’m going to keep “Software Development” in the title–even if in parentheses.

Skilled

Perhaps the most easily identified quality of highly capable teams is their high skill level. The individual team members are highly capable.

With software development specifically, great developers are an order of magnitude more productive than good developers. While this is supported in research, I consistently observe this in my coworkers. Some people finish ten times as much real, valuable work as others.  This is for countless reasons–experience, tools, grasp of fundamentals, insightfulness, raw intelligence, personal pride.

I’m not sure if the same order-of-magnitude gap exists in every other discipline (design, user research, product/project management, etc.), perhaps because there are just so many ways to tank your programming productivity. Still, great skill is undeniably more productive than good skill no matter the discipline.

The traits I look for in any field are curiosity and a disciplined approach to personal improvement. I’ve never met a “rockstar” who didn’t possess these two qualities.

Curiosity is always asking “why”, driving towards core principles while broadening one’s knowledge-base. Curiosity gets your hands dirty.

Discipline is focused practice; a systemic approach to continuous improvement. I’ll take discipline over natural talent. If a naturally talented person develops a bit of discipline, they are unstoppable.

Cross-functional

It is easy to forget just how multidisciplinary software development is. When looked at comprehensively, developing a (primarily) software product requires capabilities in domain-specific knowledge, user research, strategy, information and ux design, process management, prototype development, programming, quality control, marketing, sales, and more.

Oftentimes, these disciplines are separated from one another; organizationally, physically, culturally. This separation sometimes helps in scaling small team processes to massive enterprises. If you want to create a productive, responsive small team, though, make sure all these disciplines are on the same team. A cross-functional team is more creative and more efficient than coordinated discipline-focused teams.

Autonomous

Add project and product management capabilities within a team to make it fully autonomous. A team that has everything it needs to operate within itself will never be blocked from making forward progress. Meetings for “updates” or “handoffs” are unnecessary. When a decision needs to be made, the right people are always in the room.

Empowered

A team is only truly autonomous when it is empowered. Having a team with the capability to take on all aspects of a challenge, and then not giving them the authority required to execute leads to frustration, strategic miscalculations and, in general, is just an epic waste of capital.

If your capable team does not currently have authority, solve whatever trust or management issues are causing it to be withheld. If you don’t, you soon won’t have a capable team anymore.

Aware

One common reason a capable team is denied the authority to execute autonomously is because the team does not have the situational awareness to make good decisions. I find it particularly bewildering that this is so often used as an argument for organizational machinery such as product management, program management, governance, executive teams, strategy teams. The duty of this machinery is not to isolate information away from development teams, it is just the opposite–to provide critical, actionable information to these teams so they can make excellent decisions themselves.

Highly capable teams develop broad and keen situational awareness of their product.

Mature

Trust is the substrate that holds highly capable teams together. Trust is earned–through promises kept, through skills demonstrated, through naked intentions. Trust is extended–by asking for help, by refraining from taking over, by answering “why”. This is maturity–the emotional maturity to handle your own disappointment; the social maturity to take responsibility for your own impact on a team; the personal maturity to maintain discipline to set and meet expectations in the face of disruption.

Really, we are all children in many ways. Maturity is something to be developed. Allowing immaturity to run unchecked (within your self, or within a team) is, at minimum, an ongoing tax against productivity. It many cases, immaturity just outright destroys a team.

Responsible

At the end of the day, a team composed of highly-skilled, mature individuals empowered to function autonomously with full situational awareness may still fail without the most critical element of all–responsibility. The team and the individuals on the team must be personally responsible for the outcomes. Some teams are formed around a singular vision composed of individuals inspired by the enterprise. Some teams develop a deep pride of their brand or ability to execute. Some teams have significant equity stakes or OKR-based bonus incentives.

Whatever the method, capable teams are made up of members that take it personally. They are never “along for the ride”. They are fully engaged. They put it all on the line.