/home/dkramer

David Kramer’s high-entropy blog

The Importance Of Team Composition

I think a lot about process, process improvement, productivity, and efficiency vs effectiveness (believe it or not the difference is not universally understood).  Lately I’ve been thinking a lot about team composition and how it affects the productivity of the team.  In part I’ve been thinking about it because of the teams I’ve had in the past; in part because I’m currently hiring and having to make trade-offs like salary level vs skill level and overlapping skill sets, but also because I’ve been playing the game Overwatch a lot, where team composition essential.

Overwatch is a first person shooter style game, with a difference (if you’re a gamer, it’s similar to Team Fortress 2).  There are two teams of (usually) six players, and one team wins the game and the other team loses the game.  There’s recognition for the best player of the game (from the game’s perspective) regardless of whether they were on the winning team or not, and each player can vote up one of the players on their team or the other team at the end of the game.

The really interesting part to me is that each player in the game chooses one “hero” (character) to play.  There are currently 22 different heroes to play, each one with very different strengths and weaknesses, but they’re also designed to fit in certain roles.  There are “tanks” (players that have a lot of health and a lot of strength, usually with reduced mobility), “offense” characters, “defense” characters, and “support” characters who generally can’t do much damage themselves, but can help other players.  If you have too many or too few of one kind of hero, you leave yourself open for a good opposing team to take advantage of the gaps in your team’s capabilities.  Like in real life teams, you’re limited by how many people you can have on the team in each role (though by game rules in certain modes, not resources), and it takes different roles to get the job done.

Software teams are what I know best so I’ll talk about them, but this is really applicable to any team working on a complex endeavor.  Software companies typically need at least:

  • Heads of business units to set strategy and direction, and suggest new features
  • Product Managers to fit the new features into a cohesive, consistent plan and roadmap
  • Business analysts to gather requirements from the other business units, the development team, and often third parties to fill in the details of the requirements and gather the related technical information
  • Project Managers to build and monitor the milestones and timelines
  • More senior Software Engineers and Architects to design the implementations, do some of the implementation, mentor others, and ensure quality
  • Less senior Software Engineers to do some of the implementations
  • QA Engineers to develop, implement, and run tests to ensure the implementations meets the requirements
  • Systems Engineers to provide, maintain, and monitor working environments for the implementations to build and run in

These roles all complement, and depend on, each other.  In software teams, the BAs help the developers work faster by gathering all the needed details for a story and establishing acceptance criteria.  Developers (and BAs) help QA do their job by writing technical documentation they can base their tests on.  Systems helps the whole team work faster by implementing Continuous Integration to catch problems with the work with every commit to version control.  In Overwatch, heroes are designed to complement each other and help each other out.  For instance, the big “tank” heroes can often create shields to protect other heroes while they do their work, and defense heroes are very good at drawing enemy heroes away from the rest of the team who can then focus on the objective. No one hero can do the whole job.

Having too many or two few people of each of these roles can hurt the productivity of the team.  If you have too many Software Engineers, they may have a higher capacity to do work than the rest of the team can define it and test it.  Too many Business Analysts could lead to a huge backlog of stories the rest of the team never gets to.  All companies are limited by budgets and other resources (desks to sit at, licenses for software, etc) in how many people they can hire, so selecting a roster of all rock-star Principal Software Engineers won’t leave you with the resources for good QA and other functions.  They will also probably get bored and leave if you ask them to write DAO getters and setters all day.

Also like real life teams, heroes which typically serve one role can serve another.  The tanks can be used for defense or offense, and the support heroes can damage the enemy players and distract them from the mission.  Likewise, developers can help QA design and run tests and Systems build out infrastructure or DevOps.  BAs and Software Engineers can both write and expand on stories.  QA can help with making sure the software design is compatible, rugged, and testable.  People in one role can even permanently switch to other roles, but you have to hire the right people on your team with the right team-based mindset and the right skills.  The biggest advantage of having team members that can fill multiple roles when needed is that some projects will require a different mix of roles than normal.  Having “switch hitters” than can help out in other roles can help fill these temporary changes in resource needs.  Similarly, in Overwatch, there are different maps with different objectives that require a different mix of heroes (roles).

Working as part of a team is an ability all to itself.  It’s important to look for people who are used to working in a team environment. Knowing how to communicate well with others (and placing value on that!), knowing what’s expected of you, understanding that there are others waiting for your work to be complete that will be affected by when you deliver it, flagging blockers, understanding the responsibilities and dependencies between all these roles, are all required skills for a team of almost any size.  Looking for these qualities will help your team keep flowing.

I’ll list one more factor here, and that’s diversity of cultures, experiences, and mindset are essential for many projects.  Diversity can lead to better solutions to problems, challenge old assumptions, and account for more contingencies, than a homogeneous group of like-minded thinkers.  Even conflict can be good for a project if it is used to objectively present and compare options.  I say many and not all, because not all projects need truly original thinking.  Some projects are very clearly defined with few real options. Others by necessity require very swift actions by experienced team members that just know what to do.  But most of the time, diversity is an asset.  In Overwatch, the heroes each have established backstories, recorded in video clips.  The come from all over the world.  Some get along and some don’t.  Some are even related to each other.  Of course that doesn’t factor into the game play directly, but it does affect how we think about and play each character.

I hope I’ve shown how team composition and size are important factors in team productivity, capabilities, and effectiveness.  Maybe even thinking of game theory as a way of measuring and demonstrating how real-world teams work.

Share

September 28th, 2016 Posted by | No comments
Categories: Business, Employment, Fun |

No Comments »

No comments yet.

Leave a comment

Site info