The Dynamic Company Operating System
Outcome-driven operations
Hi all —
Last week, I discussed the building blocks of operations. This week, I’m refining the model to think about a dynamic Operating System for a company.
The Company Operating System starts as a conceptual model. This lives in your head, and helps you make sense of and guide the organization in the right direction.
I need conceptual models, and have built quite a few in figuring out how to create products that customers love. They help simplify the infinite potential considerations and variables associated with building something new, so you can focus on the things that really matter.
And for company operations, there are also a ton of different things to consider:
Goals. Responsibilities. Job descriptions. Performance reviews. Company meetings. KPIs. Vision, Mission, Values. Org charts. Processes. Playbooks. Systems. Tools. Tasks. Projects. Tracking. Meetings. Reports. Agile development. Documentation. Functions. Cross-Functions. Communication. Best practices. Strategy. People. Purpose. Planning. Context. Feedback. Etc^1000
Without a conceptual model, it’s hard to tie these different pieces together into a coherent view. And when you don’t have a coherent view, every little decision requires you to investigate it from so many different angles to figure out the “right way to think about this.” If the model isn’t clear in your head, it’s hard to give your team clarity so they can focus. Which means even more decisions come to you, people get overwhelmed and frustrated, goals get missed, and you feel like you don’t have control.
When you have a conceptual model that maps to reality, you’re able to zoom out and focus on the most important pieces of any problem. You know where to apply pressure and leverage to get results, and can leave other things alone so you don’t feel like you’re micromanaging. You’re able to scale with less effort, leaner teams, and less pain.
Last week, I wrote about the building blocks of operations, but not the operating system. This week I’m starting to piece everything together into a system-level view.
How do we get a conceptual model for a company’s operating system? With so many interconnected pieces, where does one even start?
I ultimately cut the Gordian Knot by focusing on outcomes. Organizations exist to make things happen; the measure of an operating system’s success is whether if helps achieve those outcomes. As a founder/executive, if you’re not achieving your results (or if you’re not clear on what results you need to achieve), you’ve got problems.
When we start with outcomes, we can work backwards to create a coherent, dynamic model of an operating system:
Look at today’s outcomes that our “operating system” is delivering
Consider the desired outcome (in detail, not just in metrics)
Plan how you’re going to achieve the desired outcome - through systems, projects, and/or people
Execute on plans, compare the actual outcome to the desired outcome, and repeat
Manage through a rhythm of meetings, reports, & communications that helps you stay on top of the “operating system” with few ad-hoc meetings and fire drills
Provide context to make everything above intuitive
When you have this model in your head, you can then simplify problem-solving:
Are we clear on the desired outcome? Have we gotten agreement from around the company on the desired outcome, and buy-in from the people who are going to be working on this?
Are we clear on the plans to achieve the desired outcome - the systems, projects, and/or people? Do we have the right architecture of systems, projects, and/or people to achieve the desired outcome?
If we are not achieving our desired outcome, is it a systems problem, project management problem, context problem, and/or a people problem?
If we don’t feel connected to the systems, projects, people, and/or how we’re tracking towards outcomes, do we have the right rhythm set up?
I visualize the Operating System below - more on outcomes next week!
