Hi all —
This week, I’m continuing the theme of the Company Operating System.
Last week I mentioned the topic of company entropy: The force that tends towards reactive firefighting, prioritization of the urgent over the important, ad-hoc meetings and nonstop slack messages.
In early-stage startups, it makes sense to operate reactively because your entire business should shape itself based on what you’re learning about demand in real time. But as you grow, you know real things and can have your company shape itself around the outcomes you judge to be feasible and desirable.
What I’ve learned about the company operating system so far: It’s about organizing around achieving outcomes.
Outcomes = reality
Outcomes exist in the future, partially as the result of our actions
The present moment for our customers & business is an outcome that is partially the result of our past actions
Companies exist to achieve outcomes.
Work is the set of actions performed to achieve outcomes.
Work activities are completed through systems (repeated sets of actions, like new customer onboarding) and projects (discrete, non-repeated sets of actions, like changing the customer onboarding process). Actions may be completed by people or automation.
There are different kinds of outcomes.
Responsibilities focus on the core outcomes achieved by person or department.
Goals focus on future outcomes, which may involve projects that change the way today’s responsibilities are executed upon or projects that build new systems.
There are infinite potential outcomes; actual outcomes exist at many levels and at many time scales.
A company’s context (strategy, mission, vision, values, etc.) helps constrain the focus on a subset of all potential outcomes
Formal planning is a way for leaders to create a coherent symphony of outcomes worth achieving now, as well as a path to achieve those outcomes
Companies organize around outcomes.
Leaders, teams, and individuals own outcomes
Company rhythms / rituals determine the process around which outcomes are selected, adjusted, executed upon, and achieved.
That is the story I’m currently working with on the Operating System - which fits into the diagram below:
This week, I’m thinking about Rhythms in that diagram. One of our executives recommended I call these Rituals - so I will!
On Rituals
A company’s rituals define how it operates. Rituals are the cadences of meetings and communications that serve as the “wrapper” around all the things we do - planning, executing, problem-solving, etc.
When you set up the right rituals, the company runs itself. As I shared with our team:
Rituals help us accomplish our goals in a non-frantic way, with fewer ad-hoc meetings and conversations.
Creating the right architecture of rituals will help us scale, as new people plug into existing rituals.
Rituals are the “train tracks” we put our company on, so that the right things happen by default – rather than us all needing to be superheroes all the time.
Rather than constraining our creativity, rituals help us focus our creativity and intellectual horsepower on the SUBSTANCE of the right topics… otherwise, we’d (1) have to remember too much, (2) always worry that we’re missing something important.
I spent a while thinking about what constitutes a ritual, what kinds of rituals exist, and how to make sure you’re building the right set of rituals. For me, this wasn’t intuitive.
I didn’t just want to say, “We meet quarterly to do X, Y, and Z” without having a way to think about what X, Y, and Z SHOULD be, and having thought through why they’re the right things.
What I came to is that each ritual is the deliberate combination of a few building blocks, and you should design rituals to set & achieve your desired outcomes with the fewest number of ad-hoc meetings, fire drills, and Slack messages. Diagram below:
I’ve come up with five ritual “building blocks” that are modular and combinable into any ritual at any level in the organization.
Planning: This building block is about determining which outcomes are worth pursuing and how we’re going to achieve them. See last week’s mega-post on planning HERE.
Execution & Problem-Solving: This building block is a way to handle issues, brainstorm problems and solutions, get advice, workshop ideas together, or simply execute together on the path to achieve outcomes.
Reviewing, Reporting, & Comms: This building block is about communication and inspection. How do we know we’re on a path to achieve our outcomes? How do we share this information across the company or externally?
People: This building block is anything to do with culture, satisfaction, celebration, performance, advancement, and learning.
Meta & Context: The “meta” building block abstracts one level and looks at the rituals and company as a system.
Each building block can stack into a ritual, or rituals can simply include one building block. For example, a quarterly leadership retreat might combine four different building blocks - as shown in the picture above.
We can then determine our rituals by combining building these building blocks at different cadences. As an example, you might have:
Annual leadership retreat focused on high-level planning, people, and getting “meta”
Quarterly leadership retreat focused on reviewing the past quarter and planning for the next quarter, serving as input for board communications
Monthly leadership day focused on reviewing progress and problem-solving issues, serving as input for a company all-hands meeting and monthly company update
Weekly open-forum leadership check-in focused on problem-solving and potentially a lightweight metric review
The point is: You can design these rituals however you like, for the kind of leadership team that you want to run. What matters is being deliberate and explicit about your company’s rituals, executing them well, and reflecting upon the rituals to make slight changes. Especially consider tweaks as you observe goals being missed or ad-hoc meetings happening: Those are indications that something might be wrong with your system of rituals.
The same is true for a department: Set up your rituals deliberately, tweak them over time. The closer to the frontline you get, the more rituals might occur daily or weekly.
Final thoughts:
Scrum is a set of rituals
There’s no reason this doesn’t work at an individual level, too