Set up a product development team for success

"The best teamwork comes from people who are working independently toward one goal in unison." -James Cash Penney

Your organisation has grown significantly. You hired a great talent, highly-skilled engineers or super smart individuals motivated to move your organisation to the next level. You might be continuously adding more people on board to meet the increasing demand of the customers. But you are not achieving what you aim for. Instead of speeding up, you are going even slower than before.

Are you doing something wrong?

Most likely you are, and most likely you can do something to improve the productivity of your product development. But before you get into solving the problem, you need to set the right expectations and be realistic. If last year your team of 10 engineers was quite fast in building new product features, now with 20 people on board you should not expect to move twice as fast. There is a natural force against your desire to quickly accelerate.

The Ringelmann effect and product development

In 1913, Max Ringelmann, a French agricultural engineer, has identified an interesting phenomena in human behaviour. There is an inverse relationship between team size and the individual performance of the people in the team. In other words, as team size increases, the individual contribution of the team members decreases. The potential productivity of the whole team - when all individuals would use their maximal potential, is much higher than the actual realistic productivity.

Ringelmann has shown this pattern on a simple activity - rope-pulling. But this pattern can be applied anywhere and certainly in product development.

According to Ringelmann, there are two main sources for decreased individual productivity: 1) Loss of motivation and 2) Coordination problems.

Loss of motivation. When a group of people is assigned a task to complete, every person feels only partial responsibility to complete the task. The bigger the group, the lower the responsibility of each person individually, which directly leads to decreased motivation in the group. There are always exceptional contributors in every team, but these are just exceptions. For most people in the team, this rule applies.

In the 1960s, Derek De Solla Price came up with an interesting observation that roughly the square root of the number of people in an organisation perform 50% of the work. This means that for large teams only few of the team members perform most of the work. This picture is not different in a product development organisation. If we compare the individual contribution between the product development team members, we would typically get figures like these. The bigger the team, the longer the tail of the figure would be.

Coordination problems. Working in a team requires a great coordination between the team members. When this does not work well, time and effort is spent on waiting, alignment, or redoing the work due to misunderstanding.

Product development is not different. Product development is a highly complex and dynamic system. It not only consists of people, but there are also software systems, data entities or other physical components that are shared among people. In a growing organisation, the challenge is bigger as the system is more dynamic, with teams growing or being reshuffled, or software systems that grow continuously. Lack of coordination rules in such a system will lead to a complete chaos and will undercut the efforts of even the most skilled and motivated people.

Basic principles to design your product development organisation

There is no magic bullet to solve the Ringelmann effect in product development. Frameworks and methodologies like Agile, SAFe or Lean can only provide guidance, but they do not offer a solution for your specific situation. Instead of applying a concrete framework, it is better to think in terms of principles. What exactly do you want to achieve? Which exact problems do you need to solve. When you have a good understanding of the problem, it is easier to come up with a solution that works well for your unique situation.

Below I have listed the core principles that I find essential when designing a productive IT organisation.

1. Enable high team autonomy

Minimising dependencies between teams increases team autonomy and directly decreases the coordination problems. In practice, achieving a full team isolation is not possible, but the more you succeed in this, the more you can enjoy the benefits of high productivity.

A team should ideally be formed around a product or component of enterprise value, e.g. an online shopping mobile application can be one such product. When the team owns the development of the product, there will be a better alignment between the team and the customer.

Mapping teams to products only is not sufficient. On the other side is the technical view of the product. Structuring the teams in a way that does not match the technical architecture of the product can negatively affect the team productivity. If two teams share the same software component, the need for coordination between them increases as well as the chances of introducing errors.

Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure. — Melvin E. Conway

In a growing organisation, this challenge is even bigger. The technical products continuously grow, teams are also growing as well as the number of customers. A team structure that works well now might not be a good fit in a few months.

In such an environment, it is especially important to have a good control on this and think a few steps ahead. Sometimes reorganising the teams might speed you up, other time refactoring the product to achieve higher degree of isolation might be a better solution. A perfect mapping between end user view, teams and technical view is usually not feasible. But you need to be able to understand well the pros and cons and choose the right solution.

2. Set clear governance

Is there a single person accountable for the profitability of your product? Who decides which features to be built? Who is consulted when setting deadlines for a release? Who is accountable for the technical quality of the product? And who is responsible to manage a security incident?

If you don't have a clear answer on questions like these, you should evaluate the roles and responsibilities in your team. Having a clear governance is a must if you want to fix the disorder in your product development flow.

Clear governance is not about setting a hierarchy in the team, but it's about giving everyone a clear view on what their responsibilities are. It even empowers your teams when they are given an ownership of something that provides directly value to your organisation. Clear governance allows for fluid information flow in your teams and minimises the time spent on alignment or rework due to misunderstanding.

Start by listing the goals that are of high importance for your organisation. Evaluate the processes you have in place and ask yourself: "Is there sufficiently control within the entire process to ensure that the goal is achieved?"

For example, your goal can be to decrease the amount of defects in production. You could not simply assign a quality assurance manager and give her the responsibility to manage the quality assurance phase effectively. Instead, evaluate the whole process. Defects can happen due to unclear requirements, bad design, low quality coding, or poor testing. It seems not only the quality assurance manager is responsible for achieving this goal, but everyone is responsible to contribute to this goal. If you split the goal in smaller parts, you could set requirements for every stage of development (requirements definition, design, coding and testing). Once you have these requirements (preferably measurable), you could explain the responsibility to every team member. It is then a joint effort to achieve the goal. And importantly, the whole process is optimised towards the desired goal - a lean way of working. You could assign one person as accountable for achieving the goal, for example, the engineering manager.

3. Connect teams to the product and the customer

If you want to build a product that customers love, you need to get your development team closer to the customer. In the traditional way of working, the team gets a list of requirements as an input and has the responsibility to implement these requirements. There is so much that can go wrong in this setting. How could you make the customer happy with such a distant relationship?

This is why Agile introduced product ownership as a crucial concept for every product development. A product owner is the person who stays close to both the customer and the engineers. Without this role, there can be a big mismatch between the product you build and the value it brings to the customer. Of course, next to this role there are also product managers, VP of product, or CPO, each of them operating on a different level, but the concept is the same.

If you have a customer facing product, introducing a UX designer in your team is also a step forward. This person would have a good understanding of how your customer operates with your product, and would guide the product development in the right direction to maximise customer experience.

Even when you have these roles in the team, it is still a good idea to involve your engineers in the client meetings from time to time. The engineers will be motivated when they understand the value of their work. Make your development teams love the product. Only then, they would know how to prioritise, and they would feel the urgency of solving an issue in production.

4. Team strength

The culture in your organisation has a huge impact on the motivation in the team. People are motivated when they are surrounded by others with similar values. Some organisations pay a special attention on values during the hiring process. And that pays off. It increases the chance of happy and empowered employees.

When structuring the teams, make sure people in the team match with each other. Michael Jordan has put it nicely:

“Talent Wins Games, Teamwork Wins Championships” -Michael Jordan

But this works only when there is a good match between the people in your team. Successful team work makes 1 + 1 = 3, but if you put the wrong people in your team, you could get even 1 + 1 = 1.

And finally, make sure you have leaders who know to set an empowering environment, who know to provide the support when needed, but who also have trust in the team to get the job done. Make sure leaders know to set a continuous improvement culture. A team motivated to improve will find their obstacles as well as a solution for them.

This post in part of the series “Successful digital product growth”. Check bellow the remaining articles:

#1 Is your digital product ready to grow?

#2 What is an effective product strategy?

$3 Set up a product development team for success

#4 How to remove waste in software development

#5 Unlocking the architectural scalability of software products