Manage the Machine
As a leader or manager one question comes up again and again. How do you design an organization for high performance?
The core problem is that you need to coordinate a lot of people and they often aren't clear on who needs to do what and how to make that repeatable, scalable, and predictable. When I was a consultant I made countless process maps that attempted to solve this, but they were hardly used because they were too long, too rigid, and outdated.
As the pace of change has accelerated in recent decades, we need more simple and flexible ways of managing. In order to solve for this, several successful entrepreneurs and scholars have described an organization (or team) as a "machine" and emphasize the importance of "managing the machine". Let's consider two prominent examples.
In High Output Management Andy Grove, founder of Intel, uses the example of a breakfast factory to explain his simple principles for managing an organization. He describes the organization as a black box where there are inputs, labor (the black box) performs work, and there's an output.
In Principles Ray Dalio, founder of Bridgewater Associates, says that the most successful people are able to "design a machine consisting of the right people doing the right things to get what they want. They are able to assess and improve how their machine works by comparing the outcomes that the machine is producing with the goals."
This begs the question: What is a machine?
This is exactly what I will explain in this post. I will provide the conceptual framework for understanding the difference between a machine and process. I will give you an example and provide a simple machine map template you can use to start designing your own machines.
What is a Machine?
My simplified definition is that a machine is the concept that represents the system in-between goals and outcomes. All systems have three critical parts: elements, interconnections, and purposes (i.e. goals). Donella Meadows provides a great example of how these critical parts work in Thinking in Systems: A Primer:
"A football team is a system with elements such as players, coach, field, and ball. Its interconnections are the rules of the game, the coach’s strategy, the players’ communications, and the laws of physics that govern the motions of ball and players. The purpose of the team is to win games, or have fun, or get exercise, or make millions of dollars, or all of the above."
From Andy Grove we get the concept that a machine is a system. From Meadows we learn that a system has three critical parts: goals, elements, and interconnections. We now look at how Ray Dalio applies these concepts to his definition of a machine:
[A] machine will consist of the design and people you choose to achieve the goals [you set]. For example, if you want to take a hill from an enemy you will need to figure out how to do that—e.g., your design might need two scouts, two snipers, four infantrymen, one person to deliver the food, etc. While having the right design is essential, it is only half the battle. It is equally important to put the right people in each of these positions. They need different qualities to play their positions well—e.g., the scouts must be fast runners, the snipers must be precise shots, etc. If your outcomes are inconsistent with your goals (e.g., if you are having problems), you need to modify your machine, which means that you either have to modify your design/culture or modify your people."
Ray's definition hits most of the definition identifying goals and elements (people) but one thing he doesn't explain well are the what the interconnections are in the machine. My time at Bridgewater Associates taught me that the interconnections in the machine are the responsibilities of each individual (or team).
A common mistake people make is to confuse a machine with a process. They are different but related! While processes specify when and how people will produce an outcome, machines specify the responsibility set and who will own them to achieve the goal(s). Machines are higher level and more flexible than processes. More than anything else, machines specify which people own which responsibilities while giving the responsible person autonomy to design how the goal is achieved. An organizational chart is the simplest form of outlining a machine design for who owns what responsibility in an organization.
To apply this abstract concept to organizations, it helps to imagine Matryoshka dolls — inside one is another and another. The organization as a whole can be thought of as one large machine trying to achieve it's purpose (e.g. profit) each department owns a responsibility set of the whole. And within a department teams own the sub-goals of the larger organization and have their own sub-sub-machines for achieving their sub-goals. That's why it's so important to be clear on who owns what responsibility in a organization. To illustrate this let's consider the basic machine of a company by looking at the C-suite as an example.
Example of the Company as a Machine
Goal: Build a resilient and profitable business that can live in perpetuity.
Generate $80MM in ARR and $20MM in net income
Hire 100 new people and have <20% turnover
Implement new CRM by end of Q3
Machine Design:
CEO: responsible for setting a vision, getting people, and building a machine that successfully meets the goals (i.e. profit) of that vision.
COO: responsible for implementing the vision through efficient and effective execution of machine operations that power how things get done.
CFO: responsible for monitoring the financial health of operations and not running out of money, capital raising and allocation, and preventing fraud.
CTO: responsible for enabling technology that is safe, efficient, and effective to power how things get done.
CHRO: responsible for acquiring great people and ensuring their high performance and wellbeing to achieve the company's goals.
Outcomes:
The business generated $100MM in ARR and $25MM in net income.
The business hired 80 people with an annual turnover rate of 15%.
The business implemented a new CRM in Q4.
Using this basic example, we can see the machine is performing very well but didn't hit all the goals. It exceeded the revenue and profitability targets. The CRM was implemented behind schedule. And hiring was behind but with lower turnover.
Say we're managing this machine and we want to know why we were behind in implementing the CRM. We learn that it was due to not having enough people on the implementation; those 20 missing hires included engineers and revenue operations people key to the project. We would now want to investigate the area where the machine didn't meet its goal. We would meet with the CHRO and person (or team) responsible for hiring and ask to review their "hiring machine" (a sub-sub machine) in order to find out what needs to be changed in order to help the larger machine meet it's goals. But wait, how do we know what the machine is? You need machine maps.
The Machine Made Practical — Machine Map
A machine map is a simple one or two page document that defines a machine's goal(s), design (roles and responsibilities), and expected outcomes. Importantly, the Machine Map should be treated as a living document so people know whom to work with and feedback on the machine's performance can be easily incorporated. Let's review a simple machine map example that every organization needs — an "onboarding machine".
Example: Onboarding Machine Map
Goal of the Machine: Onboard new team members excellently
New member knows their role and how to operate in the team
New member outlines what they want out of their tour of duty
New member understands how the business works
New member gets to know peers and key stakeholders
Expected Outcomes:
New member feels welcomed and excited to be part of team
New member meets key people and learns about what the company does
New member has completes onboarding workbook: conducts self assessment, establishes role responsibilities and expectations, and sets professional goals for year
Responsibility Map:
High-level Process:
Create onboarding workbook for new employee
Arrange team lunch on first week
Set up 1-on-1 on first week
Complete workbook in first month
People Ops 30 day check-in
Resources:
Link to document or tool (e.g. onboarding workbook template)
Wrap Up
You now have a holistic understanding of the concepts that make up what a machine is, a simple example, and a practical tool to do it for yourself. Outlining responsibilities might seem pretty obvious, but I can tell you very few organizations do something like this.
When we built and scaled Knotel from into a unicorn scaling from 25 to 500 people in three years we found machine maps were much easier and more flexible than process maps. They helped us move fast and iterate quickly by clarifying goals and directly assigning responsibilities. Let's review the difference between a machine map and process map one last time:
Machine map: Outlines the goal(s), machine, and expected outcome(s). The machine consists of responsibility set, responsible parties, high level process, and link to tools or resources used.
Process map: Outlines the series of sequential steps people take and tools they use to execute a part of a machine over a given point in time.
Now that you understand what a machine is I encourage you build one machine and teach it to your team. If it isn't perfect the first time don't worry. Figure out why by working with the people in the design and iterate on it. After all, the objective of managing in a machine-like way is continuous improvement — the key to high performance.