In The Loop—Chapter 7: Organization Design and Self-Organized Teams

17 min read

How would you describe your company? Do you think of it as a set of functions or as a set of systems? This is a paradigm choice — and your paradigm drives your design. Functions are important. But functions don’t produce most enterprise outputs — systems do.

Most systems in the enterprise are cross-functional. That’s why it’s important to view your enterprise as a set of systems. In today’s fast-changing world, the systems-centric view helps leaders approach problems in a more holistic way than a functions-centric view. Contemplate for a moment the intersection of functions and systems:

When you come at organization design from a systems perspective, you end up with designs that are different from those derived from a function-centric view. A function-centric view leads to a function-dominant structure. The problem is that as a company scales, such a structure encounters rising problems, especially with handoffs. Coordination debates must be taken to the top of the company and back down for resolution. This wastes time and costs money. When this happens, functions become monoliths. Given the pace of change, a function-dominant company lacks resilience.

Systems-driven organization design leads inevitably to domain teams — both uni-functional and cross-functional. Change hits the enterprise through its frontline teams. They must sense change, identify the new reality, discern implications and act iteratively towards improved value and execution. Because change is rapid, these teams need the autonomy to act and react. They must do so while remaining aligned with enterprise purpose. To balance alignment and autonomy is a first order concern in the fit systems enterprise.

This chapter addresses the following aspects of organization design:

  • Domain driven design
  • Balancing alignment and autonomy
  • Self-organized teams
  • The example of Spotify
  • Types of teams
  • Matching needs to talent
  • Layering in management

Domain Driven Design

Eric Evans wrote Domain Driven Design¹ to guide architects and engineers towards a more business-centric development of technical systems. At its essence, the book identifies how to model a business domain (expressed in business terms), divide it into subdomains, define the bounded context of each subdomain, and map the dependencies between domains. DDD is closely aligned with microservices architecture.

The principles of DDD are also relevant to the human side of the enterprise. Systems are made up of domains. Domains are managed by people. Inside every system are domains that require human activity to execute business outcomes. These domains complete work that contributes to system purpose, coordinating with each other as required. One domain is loosely coupled with the next, completing its work and passing it on. The business outcomes of domains can be measured. For these reasons, the domain is the primary building block in systems-centric organization design.

To create a domain-driven organization design, you first draw domain boundaries. There are three factors to consider:

  • The criteria that drive the contours of your boundary (segmentation scheme, geography, steps in a process, the problem to be solved, etc.)
  • Granularity (the scope of business outcomes expected by the domain)
  • Size of the operational and / or technical teams that will serve the domain (best to avoid teams larger than 13)

The early stage startup is essentially one fully integrated domain team. On the other end of the scaling continuum, a large enterprise might be made up of thousands of domain teams. Note that multiple domain teams may be assigned to one domain. For instance, in the accounts receivable domain there could be one team or thirty. On the scaling path, leaders will add domain teams as necessary to address volume. Periodically, the domain itself may need to be split. Domain driven organization design keeps the organization structure modular.

Take a mid-stage B2B SaaS company. Inside its revenue engine system, one domain might exist for campaign management. This domain might have within it growth marketing experts with specializations in search, digital marketing and email marketing. Another domain might exist for lead management and opportunity management. Here multiple operational domain teams might operate, each made up of two SDRs assigned to one account executive.

As the company scales, domains themselves might split. Perhaps the campaign management domain atomizes into separate domains for search, digital marketing and email marketing — with separate domain teams inside each of these.

As a company scales, the granularity of domains and domain teams increase. Say you serve SMB, Mid Market and Enterprise customers, in three chosen verticals, in three regions around the globe. Your organization might evolve into a cube:

In this case there are twenty-seven cube permutations of segments and personas, each with unique needs. In this company’s revenue engine system, the domain teams for campaign management, sales development and opportunity management might all be organized consistent with this segmentation scheme.

The same thing happens in all other systems. In the accounting system, accounts receivable and accounts payable separate into distinct domains early on the scaling path. At enterprise scale, the accounts receivable domain might be organized into multiple domain teams, broken out by geography or spending tier or some other criterion. In the product discovery system, a large enterprise might spawn multiple domain teams pursuing different innovative hypotheses towards product breakthroughs. In the product management system, domains and domain teams might be organized around product feature sets (such as the self-serve onboarding experience, or payments, or dashboards), around clients (such as iOS, or Android, or desktop, or web), and around infrastructure domains.

A domain team is comprised of the people required to complete domain work. Most domains are managed by one of two team types. Teams can be operational or technical. A single domain is served by both when an operational team is required, but where there is also an automation opportunity inside that domain. The automation opportunity causes creation of a technical (development) team. Sometimes domain teams are episodic — such as the external audit team inside the accounting system.

Domain teams fall into four buckets. Some domain teams are uni-functional, such as accounts payable teams. Others are cross-functional, such as product management teams. Some conduct work with low variation — such as accounts payable, or payroll management. Others conduct work with high variation — such as account based selling, or legal work. This results in four team types:

High variation domains, by definition, are the places where change hits hardest. In a world of fast paced digital change and where market truth is in motion, the performance of high variation domains is paramount.

High variation domains demand sharp problem solving skills. Top performers in high variation domains (such as architects and algorithm builders in product management system domains) often perform at 10X (or greater) the level of the average performer. This compares to low variation domains, where top performers may have a 2X advantage over average performers. This is why it is especially important to continuously increase the density of high performers in high variation environments. Doing so is the only effective antidote to rising complexity.

Low Variation / Uni-Functional

Accounts payable, HR recruiting and HR onboarding are examples of domains that are managed by a single function, and involve low variation in the nature of the work. Workers execute most daily work on their own, with few handoffs required.

Functional leaders establish the teams. They define team objectives, based on quality and efficiency measures. Leaders must make sure the right data (dashboards, etc.) is available to the team to track performance. Individual members of the team are coached by functional managers in standard operating procedures and best practices.

But functional leaders and managers are not, by and large, in domain team meetings. These weekly meetings are facilitated by a team leader that is a working member of the team. The team pursues continuous improvement through process optimization.

Wherever there is rote work, automation can be pursued. Both operational and technical teams are often assigned to low variation domains. For example, a development team might implement robotic process automation, either homegrown or through a vendor tool, to automate human steps in a low variation domain.

Low Variation / Cross-Functional

Some domains are low variation but cross-functional. Accounts receivable, HR compensation administration and sales development are examples. In such situations, transactional cross-functional coordination is required to complete a task. For instance, the resolution of an accounts receivable issue may require coordination between the accounts receivable rep and the customer success rep assigned to that account. Similarly, an HR representative administers compensation decisions for new employees within a standard set of parameters, but final decisions require transactional coordination with the hiring manager. In sales development, sales development reps (SDRs) must coordinate with marketing people regarding lead quality, and account executives regarding the acceptance of qualified leads.

In domains that exhibit low variation but cross-functional coordination, self-organized teams meet weekly to optimize quality and efficiency, focusing special attention on handoffs. Once again, functional managers don’t participate on the weekly team meetings. One member of the team is identified as team leader. The functional manager’s role is to coach team members affiliated with the function. Functional managers collaborate to ensure everyone shares a common definition of purpose and related KPIs, and to support cross-functional coordination by ensuring the right data is available to the team to track performance.

Once again, a development team might work side by side with an operational team if automation opportunities exist.

High Variation / Uni-Functional

Certain types of work involve high variation, executed by a single function. Examples include corporate development, campaign management at the top of the funnel (growth marketing), and legal dispute management. Wherever there is high variation, the goal is to reduce variation and narrow in on truth. For corporate development, that involves winnowing down potential acquisition targets and confirming “truth” through an effective diligence process. In campaign management, reducing variation involves testing hypotheses via A/B tests to find which ones deliver highest conversion rates per invested dollar.

Domains that exhibit high variation require creative problem solvers. Creative problem solvers generate better hypotheses, which is critical in high variation domains, and they are more rigorous in testing them and iterating on them. That’s why the difference between good and great in these domains is 10X or more: better hypotheses, more rigorously tested and iterated.

Domain teams can be small — for instance, a director of corporate development or chief legal counsel might work alone, or with just one or two assistants. Most of the work to be done is solitary. As a company scales, however, even domains like corporate development can grow in size. Team self-organization only becomes relevant, of course, once there is a handful of worker peers who need to work together. High variation / uni-functional self-organized teams focus on best practice discovery and problem-solving collaboration.

High Variation / Cross-Functional

Some domains feature high variation in the nature of the work, and require cross-functional coordination to complete it. This is the case, for instance, in product management, product discovery and account based selling. It is here that the principles of self-organization become particularly powerful. In such teams, creative problem solving is ongoing, and cross-functional collaboration is a part of daily work. That’s why in agile development, cross-functional teams meet daily. Leaders make sure teams are in alignment with purpose. Purpose is stated in terms of business outcomes, not outputs. Functional leaders coach the people affiliated with their functions. But teams are expected to figure out how to most effectively pursue their purposes on their own. Teams may meet daily.

Balancing Alignment and Autonomy

If your company exhibits high alignment and low autonomy, you are in a control paradigm — a benevolent dictatorship. There are times when this paradigm may be necessary — Ben Horowitz has called such situations “wartime”. The wartime posture ensures speed and decisiveness of decisions, executed without question. In such situations, the company’s generativeness and adaptiveness are constrained by the decision capacity of the top team. In some enterprise operating systems, such as the accounting system and the control system, high alignment and low autonomy may work — but for most company systems it doesn’t — not in a world of accelerating digital change.

If you have low alignment and low autonomy, you are caught in a pattern of dysfunctional control. Low alignment and high autonomy implies leadership abandonment and chaos.

For most company systems — certainly the ones that require human judgment and creative problem solving — it is only when you achieve high alignment (in strategy, principles and frameworks) and high autonomy (in how the work should be done to accomplish the strategy) that you achieve a self-organized and purpose driven system.

As such, most teams in the fit systems enterprise live in t he top right quadrant:

The whole point of organization architecture — the way you organize roles and how roles relate to each other — is to maximize the health and performance of your enterprise operating systems. How do you design the organization to ensure effective system performance? That’s the key question.

Self-Organized Teams

The point of self-organization is to optimize team effectiveness with the lowest possible level of management involvement. That enables management to have a wider span of control, and to work on higher-level transformations. If frontline workers can execute team responsibilities effectively on their own, they should. Functional and system leaders are still responsible for team performance. Leaders use feedback loops (team performance data, team health survey data and insights from their coaching) to ensure domain teams and the individuals within them remain purpose driven and performing.

Self-organization will look different, depending on the type of team. Low-variation teams (both functional and cross-functional) will leverage data to pursue continuous improvement in weekly meetings. These are the teams most likely to also be working with a paired development team to automate steps. High variation teams (both functional and cross-functional) often need to meet much more regularly — even daily.

The team leader role is particularly important in self-organized teams. Team leaders are fellow workers, involved in the real work like a captain on a hockey team. Their job is to organize the agenda, facilitate the meeting, and keep the team focused on achieving its targeted business outcomes. While individual team members in a cross-functional domain team “report” to their functional leaders, they have a strong dotted line to the domain team leader. An effective team leader has high emotional intelligence, is organized and is purpose driven. Strong team leaders are good candidates for advancement.

Team performance is tied to formation status. New teams (or old teams that are welcoming a new member) go through four stages of development: forming, storming, norming and performing. That’s why it’s ideal for domain teams to have a certain amount of membership continuity. Where possible, keep team membership fairly consistent. The more team members get to know each other, the easier it is to blur the lines of role-specific responsibility so as to leverage member gifts and cover for member gaps.

The Example of Spotify

One company that has developed highly effective self-organized teams that fit the high-variation, cross-functional description is Spotify. Spotify is committed to systems thinking and principles of self-organization. In 2012 Henrik Kniberg and Anders Ivarsson published a seminal blog, “Scaling Agile @ Spotify”², describing the company’s agile engineering organization. The basic building block in its organization architecture is a squad — usually thirteen or fewer people. It is a small, cross-functional, loosely coupled, self-organizing unit. A squad might be comprised of a product owner, an agile coach, some front end developers, back end developers, a designer and perhaps an analyst.

Each squad has a mission and pursues quarterly goals. A squad sits together in a common work area, and has access to space for retrospective meetings. The squad has end to end responsibility for what they build — design, commit, deploy, maintenance and operations.

Quarterly surveys track squad health. The survey tracks the status and trend of key performance indicators, like this:

In squad 2, for instance, the team has assigned the product owner a green performance status, but is signaling a negative (red) trend — indicating a concern that his performance is declining. In squad 4, the agile coach is perceived as a poor performer, but the performance is improving. Since the number of survey takers is never more than seven, the survey is authentic communication in action. Placing competency assessment in the hands of peers may seem radical. But it is central to the performance of self-organized cross-functional teams. The people closest to the real work are the ones most capable of defining the standards for expected performance, and they are certainly the ones with the most direct line of sight into the actual performance of each team member. This frees functional leaders to focus on functional development and performance, taking into account cross-functional feedback.

Squads are organized into tribes. Tribes are in the same physical office, and usually don’t exceed 100 people. A tribe is led by a tribe lead.

Chapters comprise the functional part of the matrix, as follows.

Each worker inside a function (such as an engineer, or a product manager) reports to a chapter lead — in other words, that function’s leader. Chapter leads are responsible for the competency and motivation of fellow function participants across all squads within a tribe. To ensure they are connected to reality, all chapter leads are members of squads themselves. Chapter leads report to tribe leads, who report to a senior functional leader.

Engineering and product are organized into three groupings (for infrastructure, clients and features) as follows:

The role of the infrastructure team is not to manage operations — that responsibility resides in the client app and feature squads. Rather it is to provide tools and frameworks that support more efficient, effective development and operations in the feature and client app squads.

The organization architecture goes beyond squads, chapters and tribes. Spotify also encourages guilds — loose cross-group affiliations that advance key capabilities such as continuous development. Guilds are voluntary and open to all. They look like this:

Spotify’s organizational design is centered on its product management system. But small, loosely coupled, cross-functional self-organizing teams make sense in any system that requires the coordination of multiple functions to perform.

Types of Teams

The Spotify example focuses on technical teams, but the principles are the same throughout the enterprise. In a world of constant change, the fit systems enterprise must be organized everywhere for agility. A single worker may be a part of multiple organizational forms. The organization design must recognize and name them.

What are these “multiple organizational forms”? They include standing teams (those that are persistent and role-primary), episodic teams (those that are spun up and down as required), and purpose-based affiliations (persistent but role-secondary).

Standing teams include:

  • Standing domain teams, such as the campaign management team inside the revenue engine system, or the accounts payable team inside the accounting system
  • Functional groups, such as product managers or sales development reps or accountants

Episodic teamsinclude:

  • Project teams, where a project is chartered and a team assembled to accomplish a time-bounded mission
  • Tiger teams, where a problem domain has been defined (often technical) requiring a SWAT team to be assembled for a short, intense period of time to attack and fix the problem
  • Skunkworks teams, where market opportunity exists that cuts across multiple business units or does not naturally fit inside an existing organizational unit — skunkworks teams can get right to work without worrying about conflicting incentives or bureaucratic barriers; those can be addressed later if and only if the opportunity proves real

Purpose-based affiliations include:

  • Councils, such as an Operations Council that coordinates data integration across the enterprise or an Investment Council that reviews innovation experiment investments
  • Competency guilds, for instance groups that hold monthly meetings on systems thinking, or digital literacy, or agile development principles or data analysis techniques
  • Culture guilds are similar; in these groups the participants seek to promulgate core company values

The Efficient Match of Shifting Talent Needs with Talent

As change washes hard and fast across the enterprise, new problems must be solved and emergent opportunities pursued. A leader must assign people who possess the right skills and sufficient time to do the job. But whose skills, and whose time? As a company scales in a fast changing environment, the capacity to efficiently match skill requirements to talent for an array of ever-changing needs can quickly degrade.

In The Loop leaders start by building slack into the system. For frontline employees, at least five percent of time (2 hours a week) should be made available to work on things that go beyond the day-to-day job — to be used, for instance, in weekly continuous improvement meetings. For managers, at least twenty percent of time should be held available. This creates worker capacity. Now a worker can participate in continuous improvement initiatives inside their standing domain teams or join a project team.

But this is just the beginning. The In The Loop CEO takes an expansive view of talent. She understands that the reservoir of talent includes employees, individual consultants, consulting firms and partners. This widens the talent resource pool. Now she can scale up and down more efficiently, creating blended teams to attack problem domains and then disbanding them when the job is done.

Remote Workers and Teams

Mobile devices and collaboration technologies like Zoom and GoToMeeting have enabled companies to build global teams. With the rise of the flexible office, a worker on the move can rent a WeWork space for an hour or a month and can video conference into a team meeting at will. Remote teams are increasingly common with development teams; architects and product managers working in the US can send updates and specs to dev teams working in India or the Ukraine. These teams can be highly efficient when they work well, but can be hard to fix when they don’t.

It’s important to invest time for remote workers to come together in person as a team. Bring these workers together in person at the beginning of a project, or whenever team membership has significantly changed. Deep trust can only be built in person. Once you have enabled the initial in-person “form , storm, norm and perform” cycle, the team will have built enough trust to work remotely. But even then it is advisable to arrange for the team to reassemble in person on some regular cadence — ideally quarterly, but at least three times a year. Otherwise, trust will falter.

Layering in Management

Visualize all the managers in your company (from supervisor up to CEO) as one group. What is this group’s job?

It is to advance the enterprise’s generative and adaptive imperatives. It sets priorities, establishes a bounded purpose, makes investment decisions and gains alignment. It defines the attributes of the company’s aspirational culture. It then seeks to mobilize the systems of the enterprise to achieve the purpose. Inside each system, it establishes domains and domain teams. It determines the business outcome objectives of each domain, making sure that these objectives are aligned with the objectives of adjacent domains, the system it occupies and the enterprise overall. It works to ensure domain team members have the necessary skills for their jobs, and works to elevate competency through coaching, performance management and surgical replacements where necessary.

To accomplish these things, a CEO must parse out responsibility and authority. Make the management superstructure as light as possible while still solving for management’s purpose. Domain team leaders are needed to facilitate team effectiveness. Functional leaders are needed to elevate functional competency. System leaders are needed to ensure holistic integration of functions. Senior leaders tend to the dependencies between systems.

Inside self-organized teams, the team leader is there to keep the team on track. This enables functional managers to widen their spans. A functional manager should be able to manage about twenty-five employees, if these employees are in self-organized teams facilitated by a worker / team leader.

As you work up the organization chart, you must determine how functional managers interact, and whether to place a leader in charge of a system overall, instead of just a function. For some operating systems (such as accounting, cash management, corporate development, control and human resources) the system view and the functional view are similar. But for the revenue engine system, product discovery system and product management system, the system view and the functional view are different.

For instance, a systems-centric organization structure might be more likely to feature a Chief Revenue Officer position, responsible for the entire revenue engine system, with functions underneath — as opposed to having an SVP Marketing, SVP Sales and SVP Customer Success report into the CEO. The same might be true for the product discovery system (new product breakthrough initiatives) and the product management system (existing product optimizations) — which might be led by separate heads of Product.

Of course, every choice has consequences. Take product leadership. A natural, healthy tension exists between the product management function and the engineering function. Requiring two leaders of co-equal authority to hash out differences in the product roadmap and product development disciplines can improve decision quality. Choosing one over the other has the advantage of integration but risks undermining the cross-functional polarity dynamic.

Here’s how Spotify organizes its product management system:

The depiction of leaders at the bottom of the organization chart sends a powerful signal: leaders are there to coach and support.

The concept of self-organization can apply to management teams. When I worked at the Minneapolis Star Tribune in the nineties, I was privileged to be part of a strategic transformation that yielded a unique organizational architecture. Its design served well the product discovery, product management and revenue engine systems of this newspaper. This was in the mid-nineties, when the web was just beginning to emerge as a potential future threat to newspapers. Though the example may seem dated, the organization design we developed is as relevant now as it was then. It focused on the vertical business unit.

In the traditional newspaper structure, a large, monolithic advertising sales department sold ads and handed off ad mockups to a large, monolithic ad operations department, which produced the ads for the newspaper. The ad sales department was supported by a monolithic marketing department that served both advertising and circulation (the newspaper subscription side), and a centralized finance team for accounting and analysis.

The monolithic mindset distanced us from our customers. We had a one-size-fits-all solution for all advertisers, despite the fact that our advertiser customers were highly diverse. Our customer base included retailers, banks, auto dealers, realtors, companies trying to recruit talent, and grandma trying to place a classified ad. The result was poor ad quality, dissatisfied customers and flatlining sales.

So we blew it all up. After six months of work, the new organization looked like this:

We organized everything around market verticals. Each vertical group was headed by four managers: sales, marketing, operations and finance. These managers led cross-functional teams. One of the four managers was designated the group leader — in one group it might be the head of Sales, in another group the head of Marketing or Operations or Finance. These leaders were responsible for effective collaboration within the four-person leadership team, leading to performance results.

It took awhile for the shift to play out. But our new organization connected us much more closely to our customers, and it paid off. The four-person management teams yielded more holistic decision making. Vertical groups began to act like startups. 1.0 websites were launched in Recruitment (our first product was an early version of the model adopted by Monster), Real Estate (an early version of the model adopted by Zillow), and automotive (an early version of the model adopted by Cars.com). Monthly magazines were launched, including Real Estate Extra and Rent Right (both generated >$1M new revenue). Ad quality soared. Sales grew significantly.

Gallup measured customer satisfaction before and after the change. They reported back to us that is was the most significant two-year improvement in customer satisfaction they had ever recorded.

If you are the CEO, your decision on executive structure is shaped in no small part by your own desired role. In a mid-stage startup, if you want to drive product strategy, you might surround yourself with an SVP Engineering, SVP New Products and an SVP Product Management. In that structure, you become the final point of convergence in managing two systems (product discovery and product management). In a large enterprise, you might put in place a CIO to manage existing system performance, and a CTO to lead the product roadmap or your digital transformation strategy. In an enterprise with multiple business units, many senior executive positions might report into a business unit general manager who in turn reports to the CEO.

There is a wide array of reference architectures for exec suite composition. The one you choose depends on enterprise purpose, the weighting of your generative and adaptive imperatives, the talent you can access, their aspirations and your own.

Summary

In the fit systems enterprise, tight alignment with bounded purpose sits comfortably with high work group autonomy. Teams work with significant autonomy to advance their assigned part of the enterprise’s bounded purpose. Teams are small, self-organizing and often cross-functional. Each team is responsible for solving a specific, bounded objective. Leaders provide the “what” and the “why,” but leave it to the team to solve the “how.” These teams are linked in a loosely coupled way with other small teams as part of a whole system, with message passing between teams as required — just as is true in technical systems with a microservices architecture. Teams are supported by leaders whose job it is to coach, support, maintain alignment and ensure shared accountability.

That’s systems-centric organization design.

 


Notes

  1. Kniberg, Henrik, and Ivarsson, Anders. “Scaling Agile @ Spotify”. 2012. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

To view all chapters go here.

If you would like more CEO insights into scaling your revenue engine and building a high-growth tech company, please visit us at CEOQuest.com, and follow us on LinkedIn, Twitter, and YouTube.

Tom Mohr

Leave a Reply

Your email address will not be published. Required fields are marked *