An early stage startup will not exhibit a separate control system, nor a corporate development system. In fact in an early stage startup HR, cash management, control and accounting will all be inside one system. At the other end of the spectrum an enterprise brick and mortar retailer would have all eight, plus a store operations system and a supply chain system. The point is that the systems schema shown in this book is just a starting point — you will need to modify it as required to properly reflect your enterprise.
In the previous chapter I exposed the difference between the product discovery system and the product management system. Here I will provide a short overview of the six remaining operating systems in the schema. In each of these operating systems I will show a system map.
System maps attempt to describe the integrated nature of things. By considering the people, workflows, tools and money flows that exist inside a system, you can better think through the impact of change. You’re reminded that people occupy roles, for which there is a certain level of current staffing. The competency, motivation and energy of each person impacts performance, and should be tracked. Archetypes are active inside your systems; a system map helps you better diagnose where they might lurk.
Systems are made up of stocks, flows, and feedback loops. Stocks identify the status of things. Flows are where transformations happen. And feedback loops provide information about key stocks to the flows, influencing the transformations. In the system maps shown below you will find stocks and flows, but not feedback loops — that would make the drawings too complicated. However, they may help you isolate where new feedback loops are needed. With the right sensors in place you can measure key stocks then build time graphs (feedback loops) as dashboards for teams to use in continuous improvement.
System boundaries change slowly. Systems are made up of domains. Domain boundaries change more frequently — domains cleave as a company scales. Leaders decide the boundaries of domains. A single domain may be made up of multiple domain teams. The reference architectures shown below expose domain boundaries, but of course you can vary them as appropriate for your enterprise.
The composition of domain teams are also leadership decisions. You’ll notice on the map that some of the standing domain teams are operational teams, and some are technical teams. Operational teams are teams that execute human steps in the daily workflow. Technical teams are the dev or ops teams dedicated to automating human activities in low variation domains, or those dedicated to product teams. In a couple of instances you will see episodic teams. These teams are spun up episodically to accomplish a specific task, such as management development initiatives or the budgeting process.
Remember that standing teams (as might be shown in a traditional organization chart), episodic teams (such as project teams, tiger teams and innovation experiment teams) and affiliation groups (such as the Operations Council, or a culture evangelization team, or an agile practices evangelization team) are the three building blocks of organization design in the fit systems enterprise. All can be shown as domain teams.
The following maps are reference architectures. Use them to build your own.
The Revenue Engine System
The revenue engine system includes within its boundaries all activities involved in the capture of revenue. In the reference architecture below, the enterprise is assumed to be a B2B SaaS business with a mid to high lifetime value (LTV) profile. As such there are sales development reps, account executives and customer success reps. Three types of domain teams are shown: operational, technical and episodic. If the map is too complex to absorb, go back to Chapter 3. In that chapter we went step by step through the build-out of this revenue engine system map.
For more about how to build a powerful revenue engine, read my first book, Scaling the Revenue Engine.
The revenue engine system is comprised of mid and high variation domains. At the top of the funnel, campaign management is high variation. Sales is a high variation domain. The onboarding domain may be low, mid or high variation — depending on your product’s dependencies. Customer success is mid variation. Sales Ops and Marketing Ops are high variation domains.
The Human Resource System
The human resources system exists to gain leverage by effectively mobilizing and motivating human talent. It has a key role at every stage of the employee lifecycle, from recruiting to hiring to onboarding all the way through to eventual termination. It also plays a key role in the development of managers.
The HR system is comprised of low, mid and high variation domains. Payroll is low variation. Recruiting is mid variation, and the role of the HR generalist is high variation. So too is the episodic domain of management development.
The Accounting System
The accounting system manages the inflow, outflow and accounting of all money in the enterprise. It is responsible for maintaining proper controls and delivering GAAP financials. It executes financial planning and analysis, and provides financial and operational metrics to the executive team, enterprise systems and functions.
There are both low variation and high variation domains within this system. Accounts payable is a low variation domain. Here, a technical team might be paired with an operational team. So too with accounts receivable. Financial planning & analysis; audit; and Finance Ops, on the other hand, are high variation domains.
The Cash Management System
The cash management system is a system in its own right, separate from accounting. Cash management and accounting are separate in the same way product discovery and product management are separate. Cash is so vital to business survival and resilience that it requires visibility a separate-system status provides.
Early stage usually means low cash position. Company stage and cash position are correlated. The cash you have available to you, and how you manage it, will evolve as you scale. Cash can become a problem for large enterprises as well. For that reason, at all stages of growth the In The Loop leader keeps one eye on cash. Cash must always stay above a certain defined threshold to ensure business continuity. A healthy cash management system depends on sensors and feedback loops.
Cash monitoring and planning is high variation work, ultimately the responsibility of the CFO and CEO. Cash management is the execution of the cash plan — a mid variation domain.
The Corporate Development System
At enterprise scale the corporate development system becomes strategically significant. Acquisitions and corporate venture investments are key components of transformation into a digital-at-the-center, fit systems enterprise. In this reference architecture corporate development is broken into two domains — a team for M&A (acquisitions), and a corporate VC team. Both are high variation domains.
The Control System
This system plays “defense” for the enterprise; it’s responsible for compliance, insurance, legal and security. The control system emerges as a company grows towards enterprise scale. For the compliance and security domains sensors, feedback loops and dashboards are critical to monitor the enterprise. All of domains in the control system are high variation domains.
The In The Loop leader adopts a systems view of the enterprise because it helps him lead better. System maps, along with the time graphs that expose the system’s feedback loops, give leaders the insight into current state they need to identify problems and prioritize action.
This book is called “In the Loop Leadership” for a reason. Feedback loops — their sensors and dashboards — are critical components in all of these operating systems. An In The Loop leader devotes time and energy to building into all operating systems a rich diversity of feedback loops.
We are now ready to explore the five meta systems of the enterprise.