Enable your organization to operate with less information

“Confronted with a task, and having less information available than is needed to perform that task, an organization may react in either of two ways. One is to increase its information-processing capacity, the other to design the organization, and indeed the task itself, in such a way as to enable it to operate on the basis of less information”

(Van Creveld, Command in War)

In order to thrive and maintain a competitive edge in environments characterized by rapid changes, the ability to move faster than competitors is fundamental. Movements like the Lean Startup and the various Agile methodologies have popularized the concepts of being nimble and staying lean as a way to lower the cost of change and react faster than competitors. Most of these approaches are based on the concept of speed of decision making enabled by less mass: the less massive is your organization, the less energy is required to change its direction.

While this is certainly true, I’d like to show in this post how focusing just on speed of decision making gives you just half the picture: if you take into account the whole decision cycle, the quantity of information that you need before making a decision is actually more limiting that the absolute speed of decision making. Hence, the thesis of this article: if you want to achieve a superior performance, enable your organization to work with less information.

The decision cycle

We can describe the decision cycle that happens inside any organizations using the OODA loop concept developed by John Boyd. According to this model, decision making is a recurring cycle of four steps:observation, where the entity tries to make sense of all the details connected with the execution of the task at hand; orientation, in which the entity modifies and evolves its mental patterns to match the changing world; decision, where the entity recognizes the occurrence of a pattern and decides to react to it; act, where the response for the selected pattern is executed.

I want to show now that in order to win over your competitors, it’s not the absolute speed that counts, but your relative tempo or rhythm: it’s the entity who is able to go through more cycles that has an increased chance to win.

The central step of the OODA loop is orientation. Orientation is the way we interact with our environment. It is the set of all our patterns and beliefs about the world. Orientation is the element that builds effectiveness in our actions: fast decisions and heroic actions are useless if they follow wrong information because of the inadequacy of our orientation. Since the organization who has the best repertoire of orientation patterns and the ability to select the correct one according to the situation at hand has an increased chance to win, in order to keep being effective, an organization has to keep its orientation updated; it must validate its beliefs and modify them to incorporate new ones, as circumstances demand. This means, to use Boyd’s words, that “he who can handle the quickest rate of change survives“. Since survival is all about the capability to evolve, to adapt and learn, speed is important only in the measure it enables you to evolve and adapt better than competitors. Victory goes to the side that can complete more cycles from observation to action.

How information can slow you down

Having framed the “move faster” mantra in the context of tempo of the decision cycle and rate of change, the next question to answer is: how can you increase your tempo?

It’s easy to see that, before an organization can actually move, it has first to gather all the information relevant to the task at hand and then process them. Thus, performing a task generates a demand for information. One might be tempted to say that in order to move faster, you need to get better at gathering and processing information. I want to show how this is impractical.

Gathering and processing all the information is a time consuming task. First of all, one has to gather all the relevant information, and this poses the first obstacle. Getting the right information is not easy: information can be insufficient, contradictory, superabundant or plainly wrong; you can’t get information on what you can’t observe, for example, your competitors intentions. Also, let’s say that one is able to gather all the relevant information. You still need to process them. Because of the nature of information, the more information you have, the longer the time needed to process it, the greater the difficulty of distinguishing between what is signal and what is noise. This happens because information, in a competitive setting, has a time value: it is perishable. As General Patton said, “Information is like eggs. The fresher, the better”. As you use your time to process information, the information you have already collected is becoming obsolete. This means that you need to collect new information! This creates a negative feedback loop in which the information you have is useless and you are constantly looking for new one.

One way to escape this negative feedback is to realize that one will never be able to achieve certainty. You have to accept that uncertainty is the natural condition of any human endeavor. So, instead of trying to gather and process more information, you structure your task and your organization to work with less of it. Instead of reducing the uncertainty, we reduce the number of things we need to be certain of.

Enable your organization to operate with less information

According to Van Creveld, there are four main factors that influence the quantity of information your organization needs in order to perform a task. By acting on these factors, you can modify your information need and increase your potential performance.

Degree of specialization
The more specialized people in your organization are, the more information they require for coordinating their performance. The cost of coordination grows not linearly but geometrically as the number of specialties increases. One way to mitigate the issue is to assemble cross-functional self-contained teams capable of independent action.

Stability
When people share a common frame of references, ideas, experiences and trust, one knows what to do and what one can expect of others, and implicit communication will suffice. In order to let this common frame establish, you need to provide a certain stability and homogeneity in the organizational structure.

Complexity
Everything else being equal, a larger and more complex task will demand more information to carry out. One way to avoid the the multiplication of communication channels is to divide the task into various parts and assign each of them to a force that is able to deal with it separately and on a semi-independent basis.

Centralization
Centralized resources increase the need for planning, coordination and internal communication. Degree of specialization can also have an impact on centralization: more specialized the people, less capable separately are of making independent decisions, hence requiring an higher decision threshold.

Real world examples from Yammer

I want to provide you some real examples of how you can work with less information. I’ll give you two examples drawn on my experience at Yammer since our development methodology is inspired to the same principles. The examples are the way product teams are organized and the concept of product specification.

Teams at Yammer are organized in a crossfunctional way. Each engineer is member of one of the five functional teams: frontend, APIs, Core Services, Apps and Infrastructure. But this is not the way we work. When a project is ready for implementation, a crossfunctional team with representatives from each functional area is assembled and assigned to that project. The size of the team is kept small, between 2 and 10 engineers. This has some benefits. First of all, by grouping together all the specialists involved in implementing a project, we ensure that the team has no external dependency and thus it’s full autonomous and independent. The decision threshold is very low, since the team is empowered to make decisions across all the functional areas represented. The communication burden is reduced because all the communications happen inside the small cross-functional team.

The following example has been provided to me by my colleague Marco Rogers, manager of the Frontend Team. The Product Specification describes the product your company will build. Its purpose is to clearly and unambiguously articulate the product’s purpose, features, functionality and behavior. How many information do you need to include into a specification? An obvious goal would be for it to be complete enough to provide the development team the information they need to do their jobs. But how much is “complete information”? The way Yammer tackles this is that we don’t expect the specification to be the single source of truth document. We don’t expect everything to be deeply specified in it. Instead, we design the task of implementing a feature to require less information. The Product Specification roughly defines the scope of the project, but everyone on the project team is responsible for building their own understanding of the scope. The Product Manager is an integral part of the product team. QA people talk to Product Manager to clarify gaps. Developers talk to the Product Manager to negotiate changes in scope if the work is too expensive. Since people work together on the project team and we make collaboration easy, a detailed spec which specifies all the requirements up front is not needed.

— — — — — -
Obviously, it is important to find the right balance between too much and too little information. Too little information, and you risk to go in the wrong direction. Too much, and you risk to remain in the same position forever. How much is too much is a judgement call. It can’t be taught, and it is what makes our job so interesting.

Originally posted on the Yammer Engineering Blog: http://eng.yammer.com/enable-your-organization-to-operate-with-less-information/