Hackman’s Law is a principle that comes from the research of Richard Hackman, a renowned psychologist and professor who specialized in team dynamics and organizational behavior. The law is derived from his extensive study of team performance and is often summarized as follows:
The effectiveness of a team is determined by the sum of its members’ abilities and the quality of their interactions — J.R. Hackman ( 2002a)
This law is derived from the Five Factors of Team Effectiveness that Hackman identified through his studies, and that are summarized in the image below.
The factors can be summarized this way:
- A Real Team: The team must have a stable membership, clear boundaries, and be interdependent in its tasks.
- Compelling Direction: The team needs a clear and challenging goal that is also meaningful to its members.
- Enabling Structure: The team should have the right mix of skills, roles, and norms that support effective collaboration.
- Supportive Context: The organization should provide the necessary resources, information, and rewards.
- Expert Coaching: Teams benefit from coaching that helps them with task strategy, motivation, and learning.
His observation also helped to shape an important realisation: the effectiveness of a team is determined more by the context, structure, and support systems in place than by the individual capabilities of its members. Which is probably the aspect that links more to Organization Design, and particularly to the concept of Operating Model.
Key Components of Hackman’s Law:
Let’s see now in detail the components of the work of Hackman’s with a few example and their impacts.
1. Team Design.
Hackman emphasized that how a team is structured and the clarity of its goals, roles, and norms are crucial to its success. Effective teams have clear purposes, appropriate tasks, and a well-defined structure that aligns with their goals.
Example: A software development team with clearly defined roles (e.g., front-end developer, back-end developer, tester) and a shared understanding of project goals is more likely to perform well than a team with ambiguous roles and unclear objectives.
2. Team Support.
Beyond design, the support provided to the team—such as resources, training, and organizational backing—plays a critical role in their performance. Hackman argued that teams need the right tools, information, and authority to accomplish their tasks effectively.
Example: A sales team that receives ongoing training, has access to the latest sales tools, and is empowered to make decisions within certain parameters is likely to outperform a team that lacks these supports.
3. Team Composition.
While individual talent is important, Hackman found that the way a team is composed—considering factors such as diversity, complementary skills, and interpersonal dynamics—is key to its overall performance. Teams with the right mix of skills and perspectives tend to be more innovative and effective.
Example: A cross-functional team with members from different departments (e.g., marketing, design, engineering) who bring diverse perspectives is likely to develop more creative and effective solutions than a homogenous team.
4. Task Design.
Hackman also pointed out that the nature of the tasks assigned to the team significantly influences their performance. Tasks should be meaningful, challenging, and provide opportunities for team members to use their skills and grow.
Example: In a product development team, assigning tasks that involve problem-solving and creative thinking, rather than repetitive or overly simplistic work, can lead to higher engagement and better outcomes.
5. Team Process.
The processes that govern how teams interact, make decisions, and resolve conflicts are crucial. Effective processes foster collaboration, ensure that all voices are heard, and enable the team to learn from both successes and failures.
Example: A project team that regularly reviews its progress, reflects on what’s working and what’s not, and adapts its approach accordingly is more likely to achieve its objectives.
Relationship with Team’s Size
Additionally, Hackman also suggested that Team Size also impacts the team’s ability to reach results.
The larger a group, the more process problems members encounter in carrying out their collective work… worse, the vulnerability of a group to such difficulties increases sharply as size increases. — J.R. Hackman ( 2005)
This to a certain extent recalls what we have already seen as part of Parkinson’s Law.
Hackman defined “process problems” as the links—or, communication avenues—among the members in a team. As the number of members grows, the number of links grows exponentially. Using the formula n*(n–1)/2—where n is group size—Hackman found that the links among a group get hefty very quickly
My rule of thumb is that no work team should have membership in the double digits, and my preferred size is six. — J. R. Hackman (2002b)
In many organisation design contexts it is very difficult to limit the number of people to an optimal size. Particularly as we experiment more autonomy related models, there is a tendency to increase the number of participants in decision-making processes and teams. The above element however needs to be take into consideration, and it is a task of the OD designer to reflect the complexity of increased size in the supporting tools for the team to work.
The Laws of Organisation Design
- Conway’s Law and Intentional Design
- Parkinson’s Law
- Law of Triviality
- Goodhart’s Law
- Brooks’s Law
- Hackman’s Law
- Larman’s Laws of Organizational Behavior
- De Geus’s Law 🆕
- Metcalfe’s Law 🆕
- The Law of Constraints 🆕
- The Pareto Principle 🆕
- Law of Requisite Variety
- Law of Alignment
Conclusion
Hackman’s Law underscores the importance of the structural and contextual factors that influence team performance. It challenges the common belief that assembling a group of highly talented individuals will automatically result in a high-performing team. Instead, it suggests that careful attention to team design, sizing, support, and processes is crucial for achieving optimal performance.
Comments and Feedbacks
References
Read More