The New Mental Model for Formal Organizational Structure

For decades the predominant mental model for an organization has been based on the hierarchy. We grouped people, typically according to specialized capability, and put a single manager in charge of the group. As the group grew larger we in turn grouped similar manager's and the people they managed under a single senior manager. Senior managers were likewise placed under mid level executives. Mid level executives were placed under senior executives, and senior executives report to CxO suite member, with the CxO suite reporting to an ultimate boss, often a CEO, nur perhaps a minister if we are talking government. This hierarchy of accountability, when looked at from a distance forms the shape of a pyramid. With direction flowing from the top and information flowing from the bottom. While some organizations empower better than others, all organizations operate through command and control when referring to this model.

In contrast, when we think about our organize using our new mental model we form a very different picture. Instead of thinking about layers of control and authority, we think of defining out structure in terms of markets we serve. and the outcomes we want to achieve. Instead of the hierarchical pyramid, we will use circular value network. One where teams within outer zones of the organization are serviced by teams in inner zones. In effect each outer zone acts as a market to the inner zones within the organization. When using this new mental model it is useful to think in terms of the following organisational zones.

The Teams everyone is in a team, each team may look more or less like a classic agile team; but the need for everyone to feel like they share an outcome with a smaller group of peers is paramount.

The Market are all the groups that exerts external pressure on your Organization.

The Identity establishes a common identity that directs self-organization towards value creation. In Organizing for Complexity this zone is called the Sphere

The Edge is made up of every team connected to the market and contains all roles that make decisions based on market interactions. In Organizing for Complexity this zone is called the Periphery

The Core is made up of teams that are intentionally deprived of market contact. These teams serve the Edge, providing services that the Edges chooses to use. In Organizing for Complexity this zone is called the Center.

In larger organizations that number in the 1000s of employees, you may find it necessary to model both an Inner Core, or one or more Outer Cores. It can also be helpful in larger organizations to define distinct subsets of the organization into Context Boundaries. We can use ****Context Boundaries ****to group teams into units that share a subset of organizational identity, outcomes, and capability.

What's In a Name

It's important to note that I have borrowed most of these element from Niels' book Organizing For Complexity, changed the names, and then added a few elements based on my typical context of working with very large organizations. I changed names because they resonate better with many of my clients, but this could change, especially as I work with new clients. At the end of the day, use words that resonate with you and the people you are working with. Get consensus, within the scope of your transition effort, on the terms you are using so as to avoid confusion, but by all means use terms that make sense to your clients. Some Alternative terms for each of these zones could include:

The Teams: Pods, Squads, Labs, Studio, Garage, Band

The Market:

The Identity: The Sphere, Organizational Boundary, The Enterprise,

The Edge: Periphery, Market Teams, Customer Teams, Value Centers, Feature Factory, Digital Factory,

The Core: The Center, Support, Shared Services, The Glue, Infrastructure,

Going Through Each Zone in a Little More Detail

Ok, lets go through each piece in a bit more details, and provide a few examples in an attempt to make it a little more real. Let's start from the outside and work are way inward.

The Market

The market are all the groups that exerts external pressure on your Organization. This list is not limited to customers and users, but all stakeholders that influence the way your organization provides services to the market. This list includes:

• Users of product features and services that you provide
• Customers who pay for those goods and services, either directly through some form of monetary compensation, or more indirectly by providing some other form of contribution such as their time, knowledge, or presence
• Supporting Organizations that help you engage with, or even better understand the Market you are in, such as Research Institutions, Educational Institutions, Industry Guilds, Technical Standards Committees, etc
• Regulators who place constraints and rules of conduct and validate compliance for organizations working in a specific market
• Competitors others outside the organization that serve the same or similar market to the organization

When starting to think about re-defining our organizational structure, it is very important that we start by identifying all of the players that our organization must interact with in order to deliver value to market. What roles do each of these market participants play? What is our primary means of engaging with them? Is there a particular stage in our value creation life cycle where we need to pay special attention to a specific market participant. Are there opportunities where we can practice better co-creation of value with our market participants? Are there opportunities to exercise tighter feedback loops?

When articulating our Market, it is often useful to map our organizational outcomes to one or more market participants. This puts focus on how we engage outside of our organizational boundary. We want the boundary between the Market, and the teams responsible for engaging the Market, the Edge, to be as porous as it can be.

Important: The Market contains every external stakeholder that influence the way your organization provides value to the market. Every external stakeholder

The Identity

The Identity establishes a common identity that directs self-organization towards value creation. **Unlike other "zones" in our org mental model, the Identity does not define where people are placed or who they engage with. In contrast, the Identity contains normative artifacts that describe who we are, and more importantly, who we want to be, as an organization. I am not aware of any organization that has made a serious move to agility without paying attention to organizational identity. Done poorly, and we get propaganda, we get meaningless platitudes posted on walls. We get principles that leaders don't understand and don't follow. Done well, and we get Identifying artifacts that inform the right culture. We empower people to make decisions for themselves, we have something to point to when we fall back onto familiar old ways of thinking and behaving.

There are some great examples of artifacts we can use to help establish our organizational identity, almost all of these artifacts are informal, and focused on telling a story, and not on creating a false prescription of artificial precision. Good identifying element include:

• Business Models ala Business Model Generation
• Shared Values and Beliefs
• Full participation of Common Rituals, such as shared morning updates, standups, or periodic open spaces
• Publishing A Letter To Ourselves,
• Developing and sharing a Culture Handbook
• Developing and sharing an Organizational Brand Proposal
• A common Backlog of Customer Problems

Poor Identifying elements include:

• Detailed Strategies / Blue prints or Road-maps
• Anything over a couple of pages
• Principles that are not immediately recognizable in the every actions of positional leaders
• Anything that cannot be challenged, updated for context, or revised based on learning

Important: Identifying elements foster alignment and inspire culture, they don't lay out a recipe for people to follow.

The Edge

The Edge is made up of every team connected to the market and contains all roles that make decisions based on market interactions. This means every team! If a senior executive is responsible for maintaining a relationship with a strategic partner, he does no do so from the center. He facilitates the owning of that responsibility to an edge team, and performs his responsibilities as part of that team, joining the team on a part time basis. This is important! If we want our new organizational model to thrive in the face of constant change, we must move market oriented activity to the Edge! It is perfectly reasonable and even recommended for people from the Core to supply services, people, guidance, etc to the Edge, but it is the Edge teams that perform the interaction. It is important to note that each Market Participant should connect to at least one Edge team, and that we should perform this mapping as part of any exercise we conduct to understand or define our organization.

There are many responsibilities performed by the Edge. Some of these include:

• Building new Product Features, deploying them to the market and validating them
• Customer On boarding, Maintenance and Support
• Research, Strategy, and Business Model Generation
• Marketing and Creative
• Vendor and Partner Management
• Engagement with Regulatory Bodies
• Participation in professional/standards/technical groups
• Organizational Investments
• Actuary / Credit / Other Financial Models that impact product and services
• Operational Activities that have a direct impact on market participants and good and services that define how we interact with market participants

This is a long list! It's important to think holistically about how we want to organize our people into teams within the Edge. If we want to maximize the amount of people that are informed by the market, then we will want most of our people spending most of their time working as part of a team that is in the edge, so it is doubly important to try to get this part of our organization right, and to continually refine how Edge teams are structured based on the latest feedback from the market.

Some approaches to organizing Edge teams include organizing teams based on:

• Organizational Missions or Outcomes
• User Experience (eg: User Awareness, User Activation and Revenue, Billing and Receipt, Support and Customer Care, etc)
• Specific Customer / User Segments
• Products offered to customers
• Common Platforms / Systems

There are pros and cons to organizing your teams on any of these attributes. It's fair to state that I have ordered this list by an agility rank. in other words when you organize by mission you will find it easier for people to collaborate, self organize, and get market feedback then if you organize by system or platform. But, again context matters. There are many short term, and even strategic reasons to organize by customer or product instead. In certain situations, getting focus on a common platform is the way to go. A key design principle when thinking about organizing edge team is to facilitate the design of teams that minimize the hand offs required to enable a market outcome. Looking at short term demand / outcomes and organizing based on this principle is the key design consideration to take into consideration

Important: The Edge is made up of every team connected to the market and contains all roles that make decisions based on market interactions. This means every team!

The Core

The Core is made up of teams that are intentionally deprived of market contact. These teams serve the Edge, providing services that the Edges chooses to use. While we want to maximize each team's ability to self-organize around an outcomes, and to do it with the minimal amount of dependency possible, there will still be value in taking advantage of economies of scale for some forms of work.

Most people would agree that it would be wasteful for every team to define their own hiring process, or for each team to have their own means to pay employees. Technology teams may benefit from leveraging common technical platforms like deployment pipelines, or security and testing automation systems. It would be equally hard to argue that establishing and maintaining the overall organizational identity requires a cross team view. Common capabilities like User Experience, or Engineering, also can benefit from dedicated focus that spans multiple teams.

Virtually everything that you want to have some kind of oversight, consistency, economies of scale, or strategic perspective can go into the core. Some examples include:

• Regulation and Compliance
• Finance, Budgeting
• People Operations (Formely known as HR)
• Legal
• Security and Privacy
• Any Capability (Marketing, Engineering, UX, Product Ownership, etc)
• Information Technology
• Coaches
• Leadership Management

Most people would recognize these concepts as the traditional departments and organisational units you would see in a classic hierarchical organization. So what makes the Core different? The key design principles that makes the Core so powerful as an organizing element is that services provided by the Core are strictly voluntary! The Core has to treat the Edge as it's market! This means if an Edge team can find a better service outside of our organization then it is free to do so. Edge teams are not compelled to use anything from the Core.

I can see the apprehension already in many of your faces. How could this possibly work? It works because if an Edge team is provided with an equally good option inside the org versus outside loyalty will win out. If the option inside the organization is not perceived to be as good by an edge team, then it is the job of the core team to improve the service they are providing, or at a minimum do a better job of marketing their services. The principle here is that every teams need a market to organize around. Without market feedback, self-organization and continuous improvement does not truly occur. When we allow for choice, Core services improve, and when they improve most Edge teams will use those services.

Now think of the alternative, what we have now. Edge teams, when forced to engage with core teams, abdicate responsibility of the use of the services provided by the Core. When you tell someone they must use something they no longer will self organize around it's improvement. This leads to two things. Core services don't fit the need of Edge teams, and Edge team abuse the service provided by the Core. Core service teams become protectionist as a result, they make decisions that serve their needs, their outcomes, and do so deprived of market context. Edge teams start to avoid the Core, and do what they can to minimize their impact. Management often reacts by attempting to coerce Edge teams into better using the services of Core teams. Faced with an absence of market forces, services decay over time, we know this to be true. It's true both inside and outside of an organizational boundary. When Edge teams are forced to use the services of Core teams, the services they provide decay over time.

If we take the time to stop and be honest with ourselves, as a person responsible for delivering market value, how often have we had a good interaction with a support team? We likely have had a couple, working with some exceptional people that really wanted to help, and jumped through enormous hurdles to do so. But this kind of interaction is in the vast minority. Conversely as a support person how well do we feel we are treated by teams who are closer to the customer? Its not a pleasant experience on either side.

Important: The Core is made of teams that provide services to the Edge, services that the Edge chooses to use on a voluntary basis!

Inner Cores, Outer Cores, and Context Boundaries

These fundamental structures are my own addition, adding on to the ones provided by In Organizing For Complexity. I have added them to help organizational designers work within the following constraints

1. Lack Of Permission: I have yet to be in a situation where I can facilitate change that spans an entire enterprise in one go. I typically help organizations that number tens of thousands of FTEs, specifically a subset of that organization, numbering from 100s of FTEs to perhaps just over a 1000. I need a way to compartmentalize the group that is moving forward from the parts that are not.
2. Working with the As Is: Really large organizations will be at different stages of their change, I need a way to represent these more legacy parts of the organization. I need to be able to move forward in an incremental way and represent incremental models.
3. The Scale is just to big: Even if I had the permission to change the entire organization, the scale is to big. Really, really big organizations are often a federation of smaller ones. It's often more feasible to work with the smaller pieces. Compartmentalizing thing into smaller bits often make the job easier.

With that in mind Outer Cores and Inner Cores are just a way to slice the onion a little bit more. Depending on the make up of your organization you may have multiple outer cores. Each outer core is placed successively farther and farther from the Edge teams. Lets take a typical federated enterprise, perhaps an organization that has experienced a number of mergers and/or acquisitions. In our example each acquired company has retained a good deal of autonomy to interact with the market, and create customer value. There are some opportunities to leverage economies of scale and shared services. Lets look at what the various layers could look like from the perspective of the Edge.

1. We have a set of edge teams that serve the market based on the needs of a newly merged subsidiary of the company
2. We also have a set of Outer Core teams, dedicated solely to the subsidiary edge teams, provide support services to them
3. The parent company may also offer additional, complementary or even competing services to all Edge teams across the organization, including the Edge teams dedicated serving the market for subsidiary we are talking about. These service would come from teams placed in an inner core of the organization

Every time we use an outer core, it is because we want to introduce some form of shared capability to a subset of the edge teams in the overall organization. In effect we are partitioning the organization into smaller groups, in effect establishing a smaller identity within the organization, one that tends to spans multiple teams. We can define these groups through Context Boundaries. Each Context Boundary has distinguishing elements that serve to distinguish its people and teams from the overall organization. A Context Boundary can often include a subset of all Organizational actors including:

• The Market: External actors engaging with a subset of the organizational Edge
• The Identity: Identifying elements that are distinct from the rest of the organization
• The Edge: A subset of teams serving the market that are placed within the Context Boundary
• An Outer Core: Teams dedicated to supporting Edge teams within a Context Boundary

The concepts of Context Boundaries and Outer Cores can and often nest. Outer cores often contain teams that service a smaller number of Edge team grouped into a smaller Context Boundary. Perhaps a single mission, outcome or portfolio. Inner Cores can contain teams that provide services across a larger portion of the organization. Think of all the Edge teams in a Context Boundary comprising of an entire Business Unit. The Business Unit may be comprised of smaller Context Boundaries, each focused on specific missions or outcomes with the unit.

Context Boundaries can be used to group multiple Edge and Core teams according to:

• Missions or Outcomes
• Platforms or Systems
• Business Units
• Business Portfolios
• Common Business Models

Important: Use Outer Cores and Context Boundaries to compartmentalize a larger Organization into discrete parts that can be thought about in a somewhat atomic fashion from the rest of the organization.