Before I get into some techniques we can use to facilitate organizational design, as part of my next book, I thought it would be important to lay out a few overarching principles we can use to guide our thinking. These principles are:
- Organize For Cross Functionality, not Functional Specialization
- Organize Based On Market Pull
- Try To Keep Teams Stable, But Continuously Evolve Structure To Eliminate The Need For Hand Offs
- Define Organizational Structure around Social and Domain Boundaries
It's important to remember that these are principles, not hard and fast rules. Paying attention to these principles will help us grow structure that increases Organizational Agility, but it will frequently not be possible to follow them to their fullest. Pragmatism will often need to prevail. Politics, mindset, technical / system limitations, geography of people, permission, etc will factor in to how close we can get to these principles as we organize for agility.
Now that I have the pragmatic speech out of the way, (I likely do keep doing this to remind myself more than anyone else) I will say that not considering these principles when making your organizational design decisions will lead to making it harder for your teams to self-organize. I feel I need to point that out because working with these principles will feel counter intuitive to many. There will always be reasons not to move to a structure that fosters agility. Reasons include:
- we will lower our efficiency
- my people don't have the expertise
- how will I ensure consistency and quality of my functional deliverable
- I will have less control over people
- how will I manage my people and their careers
These points are actually all true, but they place focus on a functional, command, and capability perspective. When thinking of these principles, we are trying to enable a value and customer perspective.
Organize For Cross Functionality, not Functional Specialization
Use Cross Functional Teams To Deliver Value, Use Functional Departments to Build Capability
Hopefully this one is straightforward. When we use functional departments to deliver value we end up with single contributors who coordinate their work with other single contributors from other functional departments. The collaboration required to deliver value happens outside of a functional organizational structure, and often in spite of it. When we make functional departments responsible for delivery, then we need to hold functional managers accountable for results, so we are reliant on bureaucracy and management to get things done.
A much better model is to rely on functional departments and functional management to define and grow functional capability, to hire people that can exhibit a functional capability, to train them in a functional capability, and to grow their careers to excel in that functional capability. Delivery of value becomes the responsibility of teams. Team comprised of people who represent all the functional capabilities required to deliver value. In other words cross functional teams. These teams can have leaders, but these leaders should not be confused with functional management, it is the leadership responsible for empowering teams to deliver value.
Widen People's Jobs to Include a Larger Number of More Narrow, Overlapping Roles
We don't just want cross-functional teams, we want cross functional individuals inside of our cross functional teams. The reality of knowledge work is that no two units of work will be exactly the same. This means that the effort required from a particular skill will always be a bit different across each unit of work a team processes. This lack of consistency can make it hard for teams to deliver customer value to teams with any kind of predictability. Highly specialized people not only create bottlenecks, they reduce our truck number, if only one person goes missing, the team grinds to a halt. High specialization also implies lots of hand offs in the team, work tends to be performed in a highly serialized manner, with individuals working in mini silos. These hand offs create waste, and impede learning. team
One of the most effective ways to reduce the impact of these type of challenges is to ensure that people in teams are able to pinch hit and performs each other's work at least at an introductory level. People often mistake this for thinking that everyone needs to be a complete generalist to be in a cross functional team. The reality is that people can and should possess some form of specialized knowledge to effectively perform in a cross functional team.
The trick is that as people become more senior we want them to get deep knowledge in one or two disciplines while at the same time expanding their area of expertise at an introductory / intermediate level across a number of other knowledge areas. We want domain experts to get cursory knowledge outside their core domain of expertise. We want delivery professionals such as a tester or an analysts to gain experience across the entire life cycle. We an developers to be able to contribute code across the full stack. We want product people to work in operations, and operational folks to learn how to create product features.
In other words, we want to encourage the development of T-Shaped People. Your knowledge literally expands deep and wide, like a T. Perhaps a better description is helicopter shaped people. We want people to go wide in a number of directions. Your depth of expertise still matters, but your depth is the platform for you to teach others on your mission the fundamentals of what you do, at least to get enough knowledge to pitch in and help when necessary.
Again, the ability for individuals to pitch in and help each other is critical when working in an environment of uncertainty. When faced with uncertainty demand is always changing in terms of how much of a particular expertise you will need. One piece of work may require more domain expertise, another more operational support. One of the most effective ways of dealing with this demand is staffing teams with helicopter shaped people.
One way to support the development of helicopter shaped people is to widen official job titles for people. Rethink job definitions so you have far fewer of them, but make them larger, with each job containing many more roles, with many of the roles overlap across many jobs. At it's most extreme, I have seen companies, and fairly large companies at that, have only one job title. Usually something like contributor, employee, or associate. The job lays out the common expectations of anyone working for the company.
A more gentle approach may be to have a few, but still very wide job titles. Each job title would cover an over arching category of contribution to the company. Jobs can be refined by the potential roles a person could fill as part of that job. These role often end up being fairly fined grained. An example job could be Business Expert. Roles in the Business Expert could include Experience Designer, Business Analysts, Functional Tester, Product Owner, Research and Analytics, Design Thinker.
Jobs can be defined as a set of core and adjacent roles and skills. Adjacent roles and skills overlap with other adjacent roles that other jobs are responsible for. By defining jobs this way we allow people to hold onto their core identity associated with their job while encouraging them to step outside of their core domain and work on the edges, the parts that are in common with other team members.
In this model the role of an individual is determined by the play of the team, just like in team sports. Members of team will self - organize around the work to determine who does what. What skills do we need? Who has that skill? Who can learn it? Who has the experience? This tells the team who can most effectively play what role. Until the next piece of work, and the process starts again.
Organize Based On Maximize Market Pull
Maximize People In Edge Teams, not Core Teams
As market uncertainty goes up we want to increase the amount of people that are close to the market, and get feedback from real user and real customers. The most straight forward way to do that is to maximize the amount of people that are in teams that have direct communication with customers.
This in turn implies that most leadership and management structure starts to reorient towards more mission and outcome oriented themes, rather than functional skill based ones. The amount of direct spend on back office and centralized functions tends to reduce over time as market facing teams take on more and more responsibility for owning and operating according to a market outcome.
The Core moves to The Edge Not Vice Versa
There will always be a need for support structure and support services, even in the face of high uncertainty. What changes is how people working for the market facing parts of the organization engage with people working for the support areas of the organization. In the traditional model, the market facing people often send work to support areas. The support people do their thing, and send the result back. Alternatively market people submit their work for review and present it to support areas, who give their blessing to proceed.
As uncertainty goes up, this increasingly becomes a recipe for failure. Work returned by support teams often do not fit the needs of the market teams. Reviews are subverted to meet internal expectations of the support teams' processes and standards, not the actual risks of the work. Support people have a hard time getting the market or customer context to effectively support market people.
In our new model, we flip the direction of how people and work moves. Work goes to an edge team and stays there. When support is requested for a service from a core team, someone from a core team physically picks up and goes to the edge team to provide the service. Alternatively core teams can provide platforms or knowledge to allow an edge team to perform the service themselves.
In rare cases does allowing work to travel across teams represent a good choice to make, typically only if services offered by the core team that are highly commoditized and repeatable.
Use Market Pull to Guide Organizational Design
Market Pull means that constant interaction and engagement with real customers is used to inform how we define our edge teams. Demand is analyzed to form teams largely based on market outcomes. Market pull also means that we look at common demands from Edge teams for support services to help us define our Core teams.
A key distinction here is Market demand. Market demand implies choice! For us to say we are using market demand it implies that edge teams must not be coerced into using the services of core teams. Edge team must be able to choose other competing services both from within and outside of the organization, if a core team does not provide services that meet the needs of an Edge team.
The reality is that choice is an excellent mechanism for improvement. Your core teams have an unfair advantage against external providers. They are in your corporate firewall, they share your overall mission, they share your culture. With the benefit of a bit of market corrective techniques there is no reason why most edge teams wont choose to use the services most core teams. If an edge team decides not to use a core team that is a signal that the core team has an opportunity to improve their service.
Try To Keep Teams Stable, But Continuously Evolve Structure To Eliminate The Need For Hand Offs
Try To Keep Teams Stable
There has been many a time where I have encountered an organization that wanted to adopt agile on projects. While the use of agile methods is commendable, we still suffered from a number of problems. The main one is that people do not get the chance to gel into cohesive teams, once a project is done everyone goes back to their functional department. Because teams don’t get the chance to gel they do not get the chance to achieve high performance. Rework and distraction from part timer syndrome tend to be the norm in a project based model. Learnings that the team gained and any adoption of new culture and values also tends to evaporate at the end of every project.
It is very challenging to make teams work unless they exhibit some form of stability. For teams to work they need a common goal, and overarching mission, some constraints in terms of committing to transparency, feedback, and focus, and then space and time so they can achieve social cohesion. Without some form of team stability we don’t get this time or space.
Eliminate Hand Offs
We also need to be mindful that teams cannot effectively self-organize if they don't own the full scope of the work required to accomplish a mission. If a team has to hand off work to other teams in order to be successful, you have reduced their ability to self organize. They now need to organize with another team. This cross team organization typically takes the form of dedicated management, but can take the form of agile style interactions, like a shared backlog and shared events at cadence. Either way this form of coordination is expensive, it will slow teams down, and reduce feedback.
When a new piece of work comes into our organisation, one that requires work from people across multiple teams, we are faced with a dilemma, do we keep the team structure as is, creating a need for a hand off across teams, or do we change our team structure, in turn introducing instability to the impacted teams?
Continuously and Deliberately Evolve Structure
The answer is to mindfully evolve your organizational structure as market demand changes over time. Thoughtful design of teams and larger context boundaries we can use to group them may not eliminate cross team dependencies, but it can minimize them.
When demand fluctuates it tends to do so in a way that is recognizable to people that the time to correctly observe it. Patterns start to form over time, patterns that not only leaders can see, but team members can recognize. Aided by a bit of Kanban style visual management, leaders and team members can observe changes in demand and participate in the deliberate and continuous evolution of team structure and how people are placed into teams.
Movement of people and change in team structure will start to become repetitive as well and patterns will emerge. This repetition reduces the social strain caused when people move across teams. Team members know when to expect people to come and go. People will start to form a collective understanding of when they need to move to a different team. In effect stable teams evolves to become stable social fabric. A fabric that gracefully flexes to take advantage of new opportunities.
Define Organizational Structure around Social and Domain Boundaries
Use Dunbar’s Number to Group People (5, 15,35, 150)
Speaking of social fabric, the team is not the only social structure we can rely on when trying to organize in a way that allows for social density.
Dunbar's number, or more correctly Dunbar's numbers suggests that there is a cognitive limit to the number of people one can maintain a stable social relationships with. It suggest that close nit groups should be not much bigger than 5 people. A person’s active number, ie one where he maintains a fair A larger network, one where people can still interact with at a reasonable frequency caps at about 50, and the total size of a network that can share a common mission or active identity should not go much past 150 people. When you get past these numbers, it's unrealistic to expect any form of meaningful collaboration. Shared acquaintance, and a common higher level identity is the best you can expect.
While it’s unnecessary to pay strict attention to these exact numbers, they do provide a good guideline to set teams, organizing missions for a set of teams, and a larger organizational boundary. Doing work within a team, it often makes sense to form smaller groups of 3 to 5 people to process a small piece of work. A team likely should not be able to break up into more than 3 or 4 of these feature cells. Likewise a common mission with shared outcomes across teams becomes unwieldy past 50 people. I have personally seen larger business units have significant scaling and communicating problems when they get far past 150. Organizing core services so that a particular core team focus on a specific group of 50 to 150 also makes good sense. Again context matters, culture makes a huge difference, and more work needs to be done in this field before slavishly following any of these numbers.
Use Domains to Guide the Design of Your Organizational Structure
In the last two decades we have seen the rise of what some would call truly software driven businesses. Amazon, Facebook, Spotify, AirBNB, Netflix are all examples of organizations that have gained massive, 20X or more growth in market cap, they have successfully dominated markets that did not previously exist, they have innovated at scale.
I’ve thing they have done in common is to take an API Driven, software driven, service oriented approach to their business and operating model. Teams are empowered to design, develop and run miniature businesses in an autonomous and decoupled way from other teams. Using a service oriented approach these teams have effectively scaled their operations to 1000s of employees working in this fashion, achieving dominance in their core markets, and now expanding to encroach in more familiar brick and mortar businesses.
But no team is truly autonomous, how are these organizations able to scale and manage all of the dependencies across all of these teams? How are these teams able to iterate on the value they provide without accidentally introducing breaking changes to other teams?
If we accept that software Is the key to scaling modern businesses in the face of uncertainty than the answer is reasonably simple, even if seldom practiced well in the classical enterprise world. Organize your business, your software, and your organizational structure around the same structure, according to connected but distinct Business Domains.
Conway’s Law states that the dysfunction of your code will match the dysfunction of the organization used to build your code. Translation layers pop us where teams don’t trust each other. Spaghetti code appears where low social trust cause people to ram work into production to meet an arbitrary deadline. Unnecessary extra software layers show up because a teams responsible for a common component wants to make use of it anywhere they can.
Inverse Conway simply states they we can model our organization around our solution architecture. An architecture described as a set of loosely coupled business services. We can model our teams around this architecture as it currently is, or better yet we can model teams around the service architecture we want to achieve. This enables teams to be responsible for fixing code so that they can effectively build and operate discrete services independently from each other.
Modern technology helps with this, the advent of micro services and event oriented architecture makes it much easier for teams to change the services they own without adversely impacting other teams. But the secret sauce is that these organizations tightly align org structure and architecture according to discrete business domains. When faced with choice of organizing by technical framework, technology stack or business domain, the last choice is almost always better if we want to localize a specific business change to a specific team.
Domain Driven Design is a method that asks people to use a common model to describe the business. This ubiquitous language is reflected in both the way the business speaks, the way teams are organized, and directly into the domain / API layer of the code and software services themselves.
Domain Driven Design encourage decomposing different pieces of your business model / software solution into separate bounded contexts. Each bounded context contains a tightly cohesive set of business data, business rules, and business methods and is loosely coupled to other bounded contexts.
With the advent of microservices we can now ask teams to support a tightly defined suite of services that fit into a single bounded context. Teams can build services such that they are loosely coupled using event driven integration. Each bounded context can be deployed to its own virtual container allowing teams to own not just the build but operations of their own subset of the overall organizational domain.
Note:
