The Dual Operating System
Over the years, we have had the opportunity to work with a number of founders of start-up companies or those Leaders that started a new business unit. Surprisingly, we have a very similar conversation with them, and it often goes something like this:
Founder: “I really loved it when we were a small start-up company. I had a small team around me, I knew everything that was going on, I was able to direct them all in the right direction, and conversations and collaboration were really easy. But then we became successful, and we grew the organization to the point that we had to introduce a hierarchy. And while I recognized that we need to be more ‘corporate’ and we needed this hierarchy for stability and, to some extent, efficiency, I now find that this hierarchy just gets in the way. It is now more difficult to get things done because I feel that I have to navigate the hierarchy and the functions within the hierarchy to achieve anything. So, can we get rid of the hierarchy, and I can go back to run my small team?”
Our response is always the same – “NO!” At this stage, we take comfort in the words of Dr. John Kotter and from his book Accelerate [3]:
We have been doing this for years. We have a functional hierarchy and from that hierarchy, we create project teams. By their very nature, project teams are temporary organizations with people “loaned” from the hierarchy.
In Chapter 2, we will discuss in more detail about team formation. But for now, let’s accept that as we form a team, they go through Tuckman’s five stages of development – Forming, Storming, Norming, Performing, and then Adjourning. At the point that the team is high-performing, the project is now completed, and then we crash and burn the team, returning them to the hierarchy to wait for an assignment to another project team. The fifth stage is known as “Adjourning” or sometimes called “Mourning” because the project team member really liked working with that project team, and it is a form of “grieving” that they left a really great team and potentially now have to work with another team that they are not relishing.
So, rather than creating temporary teams around project, we want to create long-lived teams around products. These are long-lived, stable, persistent teams that cannot be static because people move on, and the nature of the product will change over its lifespan from a skills and funding perspective. And when we say product, it could be a product, a service, or even a system that we often call collectively a solution.
The concept is not widely different from a project; the difference is that we create long-lived teams from the hierarchy that are aligned around a product rather than a project. We call this complex adaptive network a Value Stream, and SAFe® is the operating system for this Value Stream network (see Figure 1.2):
Figure 1.2 – SAFe® as the second organizational operating system (© Scaled Agile Inc.)
The ability to respond quickly with innovative business solutions—what we call Business Agility—is the deciding factor between success and failure. Therefore, enabling Business Agility is a mission-critical goal for every organizational leader.
Achieving Business Agility requires this dual operating system and a significant degree of expertise across SAFe’s seven Core Competencies. So, let’s have a look at these Core Competencies next.
