Building the team

When building a team the first few choices are critical for the problem you are about to solve and how to solve it. The first few persons brought in on the will be important to grow a team culture and even more importantly they will be the critical competence that will define the solution going forward.

Building the team is the same as building the solution, people will create things they are capable of imagining and think are feasible to achieve. Managers or products owners do not mainly decide the solution by influencing the features or capabilities of the product but more so during their recruitment of the team.

"Match the person to the design. When building a machine the design preceedes people, because the type of people you will need depends on the design."
- Ray Dalio, Principles

When deciding on competences to have in the team the depth and breadth is a primary concern, you will need to find a compromise that suits the product you are going to build. While knowledge depth and specialization is always tempting too much of it will risk being overly focused on a specific solution path too early. Too much focus on breadth can restrict progress early on simply by having too little expertise in the critical area to make the product or a prototype of the product.

As a rule of thumb I try to map the problem to the domains in the cynefin model. If the problem area is chaotic go for the maximum amount of breadth and diversity of knowledge possible. If the problem is complicated and you know roughly what product to build find at least a few experts in that area to join the team. For complex problems look for team members that are strong in scientific method and experimentation to complement the competence you need to do prototyping of the current best guess of what to build. For simple problems try automation or out-sourcing.

Once a small seed of the team has been established and some parts of the product are getting defined then a more classic approach of recruiting additional competence be started involving the team itself. Lack of competence and information needed to build the product can then be viewed as a problem limiting progress that the team can drive, provide the details on and help solve.