Making the most of software solution teams

Ensuring that work teams perform well is something of a challenge, and the software field is no exception. The upside is that there is no need to start from scratch. There are a number of rules or guidelines we can apply, and this article covers some of them.

Not only are there different kinds of people within a team, as there are also teams that work and operate in different ways. This is necessary for the end result to be coherent and resolve challenges in a due and proper manner. This is where two theories on organizations come into play that we can use as a starting point for successful team-building.

Conway’s Law

In 1967, Melvin Conway propounded that when organizations face the challenge of designing and building new systems, they are in some way restricted to those that mirror an organization’s own communication structures.

A project sometimes does not advance as expected or is even held back, and nobody quite understands why. The fact is that the organization’s design has a direct impact on the solution to be implemented, restricting the software’s possibilities. Hence the reason we need to think about the system we want to build with a view to arranging a team structure that can support it.

The fact is that the organization’s design has a direct impact on the solution to be implemented, restricting the software’s possibilities.

The Dunbar Number

The anthropologist Robin Dunbar discovered that a person can only fully relate to 150 other people. This is due to a biological trait: our cerebral neocortex’s size and data processing capacity.

It is vital to take this limitation into account when dimensioning teams and the interactions between them. Quantity does not always mean a quality performance, and it may even be counterproductive.

Learning from experience

Based on these two theories and on our own protracted experience in different environments and with different teams and arrangements, we have formulated certain principles that we consider valid for making the most of teams that develop software solutions. There are no foolproof answers, but more than one organization will no doubt see itself reflected and maybe helped to understand the success or failure of certain specific cases.


Eight useful principles for successful software development

  1. Code error, human error. When the code “doesn’t work”, the problem tends to lie in the way in which teams are organized, as well as in how their members interact.
  2. Realistic goals. Avoid those goals that overwhelm a team’s capabilities.
  3. Structured teams. Instead of structuring teams according to their technical expertise or based on assigned tasks, it is preferable to do so according to business areas. This means bringing together individuals that can contribute different experiences, know-how, and even ways of tackling problems.
  4. Organizations should be designed to ensure that individual members can extricate themselves from the rest of the teamwork to focus on resolving certain complex tasks.
  5. Flexibility. However much time we dedicate to our organization’s design, it will never be as good as we want it to be, as the system itself evolves. Flexibility is therefore essential for the effective design of each one of the stages in the challenge.
  6. Small teams, big results. A positive impact on performance is sometimes achieved when we create small units to speed up the acquisition of new data.
  7. Organizing communication channels. Although it may seem contradictory, asking everyone to communicate with everyone else is a recipe for disaster. Organizing communications through specific, well-defined channels truly helps to build decoupled and modular solutions.
  8. Limited cognitive load. It may sometimes be advisable to limit the cognitive load that a team can handle. We should remember this principle when the system we are building is large or unexplored in terms of technology or business know-how. This means we will be able to limit the maximum cognitive load that each team can handle.

In view of the above, and in order to resolve the complex problems involved in business targets and challenges, leaders should seek the equilibrium that exists between motivation and coordination across their team members. In other words, they need to detect when processes may slow the flow of value creation, as well as those occasions that call for the team’s full and proper cooperation for achieving an objective. One goal that a single team is capable of resolving.

Asier Ortiz