The Company Operating System
The Why, What, and How
Probably most companies start with the “why.” So ultimately, with the problem that the company wants to solve.
Every successful company has this “why,” but not every company communicates the why clearly and understandably to its employees. From the “why” follows the “what” - the mission and the vision. In other words, what the company wants to achieve or change.
This “what” must exist in various degrees of detail. Even very experienced employees don't find the general company mission sufficient (or better efficient) to make the appropriate decisions in day-to-day business. What is needed for smooth operation are coordinated goals, for example, for each quarter: “What's most important right now?”
And last but not least, a company also needs an agreed framework for effective operations — the how. That means shared values and defined ways of working.
All this isn't forever. On the contrary, an essential part of the corporate culture must be constant goal-oriented reflection. Of course, one must not constantly change the big objectives and values — but they, too, must be examined again and again, just like the ways of working.
Retrospectives must therefore be an integral part of all organizational levels.
Why do we need a “why”?
Before I get into the specifics, I want to take a step back and reflect on why we do this. Of course, most modern companies have a vision, mission, values, and so on written on their website. But what's the goal? What's the purpose?
What's the added value from the point of view of the Company Operating System?
That's a nice way of putting it. But what does an employee need to be able to act in precisely this way?
Exactly, they need to know the goal and the conditions — or the rules of the game — under which we're trying to achieve the goal.
Employees need different levels of detail.
But this is still much too abstract to really help in the daily work. That's why it's crucial that the overarching goals are broken down into concrete targets for a quarter, for example, not as tasks but as objectives. To be more precise: As coordinated objectives that count for the whole company. By that, departments can align for sensible prioritization.
The same applies to the framework conditions: the values and ways of working, but also to decision-making scope and budget.
Psychology Safety and non-blaming culture
And, of course, the most important thing is to create a corporate culture in which it's permissible to make mistakes. Because entrepreneurs make mistakes, too, and so entrepreneurial employees must also be allowed to make mistakes.
From my point of view, it's very healthy to think that if an employee has made the wrong decision (from the leader's point of view), the leader should be blamed for the problem: What information did the leader forget to tell the employee, what skill did they miss to train the employee?
I think it was Daniel Ek, CEO of Spotify, who said that he’d explored that when it comes to decisions, 70% doesn’t matter whether they’re made by a team member or a leader. 20% of the decisions made by team members are even better (as they might have more knowledge of the details and so on).
But in 10% of the decisions, the leader is better (as they might have more strategic knowledge or a better overview of the overall situation.). And this isn't something the leader can be proud of, but they must work continuously to make this number smaller.
The how – rules of working together and tools that we use
From my experience, it is very effective if a company agrees on certain rules that are much more concrete than the values. What these are depends very much on the company in question. In the past, for example, I found it very conflict-avoiding if you clearly regulated what response times you expected to a message in Slack or Teams that address you personally. At Frontastic, we've defined that Slack is asynchronous. So I encouraged turning off all notifications to be able to focus on work. But we also defined that you have to respond within 4 hours. If that response time isn't enough, you must pick up the phone.
Another example is decisions. When can decisions be made by the employees themselves, when can the team make them, and when must the leadership be called in? Here, the image of the decision tree was very helpful:
Simply put, a tree consists of leaves, branches, a trunk, and roots. When there is something to decide, you think about where on the tree the decision lies. Example: New values or a new vision would definitely be compared to the roots or the trunk. Here the founders or the leadership are to be included. If, on the other hand, it is a question of a single leaf, for example, the purchase of a keyboard, then it’s more of a leave-level decision, isn’t it? And when it’s about your team’s ways of working, it’s on the branches’ level. With this picture in mind, it’s much easier to decide who needs to be included in the decision-making process.
In the next step, however, it must also be clear where decisions are recorded and how they are communicated. For me, e-mail is the wrong medium. Decisions belong in a decision database. In our case, this was in Notion. Here it is also recorded to whom the decision applies (for example, an agreement that a team makes). And the link to it is then simply shared automatically or manually in Slack (in the appropriate group).
Streamline the spoken language
What probably isn't common is that our "tone of voice“ was defined.
However, language is very important and defines a large part of how we give ourselves. Both externally and internally. For example, since our team members came from more than 20 cultures, we defined that we use language very explicitly and talk about things as concretely as possible. In some cultures, this is perceived as impolite; in others, a request formulated too politely is not perceived as such. Therefore, it made a lot of sense for us to define how we communicate internally.
The software stack — keep it simple
In addition to these "soft" things, we also need a solid framework of software. I am a big fan of the following products:
- Google Workspace (for all the basics)
- Help Scout (for external communication, team mailboxes are much more scalable for all departments than personal inboxes — using Help Scout, it still feels human to the other party)
- Slack (the easiest way to communicate, many integrations, so it’s much more than an asynchronous chat)
- Notion (the one and only, far more than a Wiki, it offers many different kinds of databases, too).
- Zapier (to combine the data and information of all the above systems and automate everything)
- Pleo (if you want mature team members, having their own credit cards helps a lot. And you don’t have to chase the invoices)
- Streak (I'm still not sure about CRM. I find Streak great for small companies because it is very well integrated with Gmail. For large companies, then Hubspot or Salesforce. But there are certainly smarter solutions)
I will go into more detail about the tools in a later article.
From my point of view, it’s important to define the following:
- If possible, communicate to the outside via Help Scout and not via private e-mail addresses.
- Internal communication is exclusively done via Slack (how to use Slack more efficiently, you can read in this blog post).
- All internal documentation etc., go in Notion.
- All payments are made via Pleo.
- Anything that can be automated in any meaningful way is automated with Zapier (documented in Notion).
- …and so on.
Start quickly with the big picture in mind
Again, keep the big picture in mind and just start with the first step. The important thing is to keep moving forward and to check regularly if you are still on the right track.
Especially when you are growing fast, the framework conditions often change rapidly, and you must revise the structures and rules. This is quite normal and should not stop you from simply getting started.