Skip to content

Main Index

Dr. Neil's Notes

General > Projects

Agility from Diversity

Introduction

In a world viewed through obsessive compulsive eyes, all things should be consistent and aligned. It is easy to understand how an engineer, or systems thinker, would like to have a set of rules that govern everything. The belief is, that to achieve a repeatable outcome, a repeatable process must be applied.

A robust solution is often envisioned as having a single set of process steps, which, when followed, create the same output. When assembling a known, well defined artefact, this single way to reach the intended outcome, is the defined set of rules to be obeyed.

Successful Past

When starting a new company, or a new project, with a small team, sometimes a single person, having a set of fixed rules for that single project has value. The rules allow people to know what is good practice and what is 'not allowed' in that team. As the small team grows, having rules helps the team scale. A new starter in a team can follow the rules and, if the rules are well documented, it is clear how to achieve outcomes in that team. For the rules to be valuable, the rules must evolve and change as the team grows and changes. The way things get accomplished when you have three people working on a product in the same room, will be different to how to achieve good outcomes when you have one hundred people distributed around five different offices. If rules do not change and evolve, the team will not be able to scale, and it will become harder to keep building and growing the product.

Fragility from rules

As a company, or product, gains success it will continue to grow. Areas of the product will become the responsibility of specific teams. Successfully growing to a certain size by applying a set of rules across the entire company has limits. The fixed rules for the whole company will become detrimental to the company as it grows. It is a common mistake to believe that the mechanics that enabled a company to reach a certain level of success, will continue to enable a company to reach the next level of success. Creating a single set of steps, or rules, across multiple teams to achieve an outcome is fragile. A large system will become impossible to maintain if only one process is allowed to achieve all outcomes. The teams that are formed to manage, grow, and maintain areas of the company, and areas of the product, need to be empowered to create and modify their own rules to be successful. As the size of a system increases, the number of mechanisms required to maintain that system must increase, if they are to be successful.

Agility from flexibility

To state the obvious; agility comes with flexibility, and not rigidity. It is common to meet leaders who claim they want agility in their environment, and also insist on a set of fixed rules be applied when working in the environment. These two concepts are opposed. As a company of people grows it will form sub-teams, with each sub-team focussed on goals that enable the entire company to reach the next goals. Each sub-team should be empowered to form their own mechanics to achieve success. This flexibility across a larger organization enables more resilience, in the system, to a single point of failure in the rules bringing the entire organization down.

Rules have value at the correct scale

This flexibility should not be down the to the individual level, it is still of value to have team specific rules. Having a set of rules will to help those teams scale, and deliver the outcomes they aim to achieve. Consider the teams as small companies within the bigger organization, and allow those small companies (teams) to determine the rules that will enable them to succeed. Measure the outcomes, not the obedience to organization wide rules. The diversity of required outcomes, cultures, and people within an organization, leading to a diversity of teams, with different structures and rules, will lead to a stronger, more agile, and robust, organization.


Last update: September 11, 2022 01:20:25
Created: September 4, 2022 01:42:58
Authors: Neil Roodyn