Does Agile make you faster? Yes! But not how you might think: A reorganization plus a calendar filled with recurrent meetings won't magically make things move faster. So - how do you become faster?

Work on fewer jobs in parallel

Think of it like this: We have 8 working hours in a day. If we work on 8 jobs for 1 hour each, it will take over a week to complete something that could be finished on a single day if we weren't distracted by 7 other things.

Work on smaller jobs at a time

Let me illustrate: If you have a job that says, "Paint porch and garage" - obviously, that thing will take longer than only painting the porch. By slicing the larger package into two parcels, you get two jobs that can each be delivered faster. The benefit? If you have painters paint your porch and garage over a period of two days, you need to inconveniently park somewhere else for two days in a row. But if you have the garage painted on day 1, and the porch on day 2 - you park in front of the porch on day 1, and return to your garage on day 2. Yay!

Admit that we're only guessing until we have a result

We often try to get the requirements right the first time, then do a perfect job. But - that usually doesn't work. The consequence? Arguments, blame and rework. None of that speeds things up. How about we simply accept that "this is version 1, now we need feedback, and we'll incorporate that?" The time spent on justifications, escalations and bickering can be eliminated from the process entirely.

There you have it.
We didn't reorganize.
We didn't assign new roles.
Or create new meetings.
Or introduce new tools.

With these three simple life hacks, I have helped development teams cut their time to market in half, while also increasing quality and stakeholder satisfaction

Collaboration Patterns we know from science

Team structures - should be a straightforward enough topic, although in many organizations it isn't. Here are six phenomena you may remember from science class - and how they relate to your organizational structure.

To keep matters simple, this post refers to "entities" - which could either be individuals, teams or entire departments. While the nature of the entity changes, we are concerned with the relationship of the entities with each other. Since some terms have different definitions in different domains, let us refer to the point of origin.

Cohesion

(Origin: Chemistry)

Cohesion is the connection between entities of one substance. Organizational cohesion, thus is the bonding strength between entities of the same category.

Examples

We have organizational cohesion when there is collaboration occurring within one team.

We have poor organizational when team members act as a group of individuals, picking their own work items.

---

Adhesion

(Origin: Chemistry)

Adhesion is the strength with which two different entities stick together. Organizational adhesion, for example, is the amount of effort it would require to separate two different entities.

Examples

We have high organizational adhesion when a process has a complex critical path.

Two business units serve different customer segments independently have low adhesion.

---

Covalence

(Origin: Chemistry)

Covalence happens when two atoms share an electron to form a bond, which molds these two distinct entities into one "complete" entity. Within an organization, covalence occurs when two or more entities share resources.

Examples

Component ownership causes covalence - let's say team A owns the Customer entity, and team B owns the Contract entity. When B needs to access the Customer, they rely on whatever A provides - whereas when A references the Contract, they rely on whatever B provides.

In situations where the Contract relies on a new or modified attribute of the Customer - such as consumer credit score, team B must coordinate with team A on how and when a change can be made, and team A might want to store a "previously rejected" attribute that must be provided by Team B. Covalence thus means that while the inner dealings of A and B become intertwined, an outside change from covalent entities requires that the change works for all covalent entities.

---

Bridge

(Origin: Chemistry)

A bridge connects two entities to turn these into one common, stable structure. Bridges require covalence bonding between two entities plus the presence of a third entity. The bridge is an entity that connects two entities by being the missing part in both.

Organizational bridges are entities equally bound to two or more other organizational entities to form one entity of higher complexity.

Examples

The analyst role is often an organizational bridge - they are close to business from development perspective and close to development from a business perspective: they are neither, but connect the two entities to turn demand into solutions.

---

Coupling

(Origin: Physics)

Capacitative coupling occurs when an energy transfer occurs between two separated conductors. Organizational coupling thus occurs when two structurally separated entities affect the outcomes of one another. We would refer to "tight coupling" when either entity could cause blocking interference to the other, and "loose coupling" if there's a generally uncritical impact. If there is no interference, we would consider the entities uncoupled.

Examples

We see tight organizational coupling when the Maintenance Team decides to shut down the Deployment process, thereby incapacitating the development pipeline.

Loose organizational coupling could be the relationship between Marketing and Sales - while they can technically work with or without the other, they do have a performance effect on each other.

---

Coherence

(Origin: Physics)

Coherence is the ability of a signal to withstand interference. We discriminate between spatial and temporal coherence: Spatial coherence is the ability of a signal to withstand interference over distance, whereas temporal coherence is the ability of the signal to withstand interference over time. In an organization, it's the ability of the information to cross entity boundaries without getting distorted by interfering signals (e.g., from other work items, other projects or line management.) Note that coherence is only relevant in the context of cohesion - incohesive entities who don't work towards a common goal require no coherent signal transmission.

Examples

Low spatial coherence would be a process with a lot of "telephone game," where information is modified in each step.

High spatial coherence would be provided by a synchronization event which ensures that all stakeholders have the same understanding on a subject.

Low temporal coherence are the deviations from a plan over time, usually caused by unanticipated events.

The problem with maturity assessments

There are a lot of "Agile Maturity Assessments" out there, and these tend to be good ideas when dealing with teams that need a kind of vision where to improve. And yet, it's good to be cautious with such assessments, as they could really send you off on the wrong track, especially when you're a coach evaluating a team.

It's not a linear scale

To some degree, product development is like a form of art: there are standards of professionalism known to the vast majority of people in the field, and those who do not apply these standards stick out. Usually, that's a bad sign. We would probably call these people amateurs. But sometimes, the results are excellent. Is that just "Beginner's luck?"

Let me give you a practical example of how a maturity assessment could go wrong:

Suppose you meet a team of developers who don't talk much, using mostly scripts, don't even branch out their code, there are very few tests in their repository and people simply put every change straight into production.

A disaster, right? They need a lot of coaching to become a professional development team, won't they?

Maybe. But maybe not. Maybe they're a high-performing team, and there's nothing you can teach them, because they're far ahead of you!

The assessment

Let's take a look at this simple "Maturity assessment":

It was on purpose designed with the same content for "Amateur" and "Mastery".

Most maturity assessments we know would stop in the fourth column - at the highest standards of professionalism. 

And that is exactly the reason why assessors might give terrible advice and why ignorant coaches could deal a great amount of damage. And as an aside, it's the reason why I refrain from having an opinion on a team until I see how they actually perform over a prolonged period of time.

True Mastery

To save some time, let's just look at the "communication" aspect in more detail here.

Communication is always good, isn't it? No - that this is a false belief!

Have you ever seen that elderly couples don't talk so much, yet don't feel there's a problem? It is because they wordlessly understand each other. She doesn't need to ask him what food he likes - she knows. He doesn't need to ask where the plates are - he knows. There is no reason why they should have a meeting to align on the meal preparations.

Communication has no value in and of itself. It has to serve a purpose. We need to communicate enough to meet the objectives of our communication. Every bit of communication beyond that is waste.

1. Amateurish teams don't know what they need to talk about, hence they under-communicate, generating communication debt.
2. In the first stage of professionalism, teams will establish cadenced planning and alignment events where they will communicate about key topics.
3. In the next stage of professionalism, teams will pair on development to speed up feedback and prevent common errors that would cause rework.
4. In the highest stage of professionalism, mob events replace discussion meetings, eliminating the delay between plan creation and execution. Cadenced planning becomes redundant and alignment implicit.
5. And yet, true masters of communication don't need any of that after having spent sufficient time together. They already understand and can predict each other's actions, so why should they align on it?

And how about simple scripts instead of high-end enterprise-level object-oriented programming? In a context. I'll leave it to you to figure that one out, although it could be quite tricky unless you've seen it.

It's quite similar with all the other aspects in our "maturity assessment." There are pretty good reasons for people who absolutely know what they are doing and who know all the tricks in the book to avoid using any of them.

It's a great exercise to reflect on the reasons why or how true mastery could make the professional patterns superfluous.

Lack of awareness

So once we realize that Amateurish behaviour and mastery might be indistinguishable from the outside, how about we ask the team? Probably not a good idea, because they can most likely explain to you why their way of working is the cherry on the cream, even when it's not. With regards from Dunning-Kruger. And even if they are well aware of the professional practices, most reasons for neglecting them are bad reasons.

Thus, you need a way to realize whether an organization has had a healthy evolution beyond the need for professional practices.

Proof in the Pudding

Again, taking a look at our communication example - the proof is in the pudding. How would you know a team is meeting its communication objectives?

When there are misunderstandings or unresolved controversies, individuals go off on tangents or people deliver fragmented piecemeal work, then clearly, we have a team who has not mastered communication, irrespective of whether they are still very amateurish or have learned professional patterns.

When a team harmoniously delivers great results, where everyone understands what to do why, how and when - what "communication problem" would you want to solve by adding structure?

Likewise, it's for all aspects of our "maturity assessment." 

When a team manages to sustainably deliver high value, high quality outcomes, they may have no need of adding anything. Most likely, the things you'd want to add would make them worse, not better. 

Once a team can deliver excellent results, our key question is what we can remove and retain our excellence. And that's the road to mastery.

Order vs. Chaos - a look at the science

Order creates a feeling of safety. Chaos, on the other hand, is a term with negative connotation.
But is order really what we want?

Using an analogy from material sciences, let's take a different look at the struggle of "order versus chaos".


Take a look at this model:

Order is the "frozen state" and Chaos is the "volatile state". I use this example on purpose: Kurt Lewin has proposed a 3-state change model, "Unfreeze-Change-Refreeze". It perfectly correlates to material sciences.

Lewin assumes that organizational structures and/or processes are best kept in a "frozen state". And in many organizations, that's true. Does it need to be true? Let's take a step by step look by examining the states first.

Different states

Frozen = Ordered

A frozen organization is ordered. It doesn't matter how effective or efficient the organization is - things are clear. Well, maybe not so much, but still. There are known structures to uphold, there are known people to address, there's a known protocol to follow and know processes to apply.
This makes things simple: If A, then B.
I go to work in the morning, know what I will be doing - and even when I take a week off, when I come back, I know the exact state where I will resume.

Terms used to describe a frozen state include: "predictable, reliable, convenient". All of these words are positively connotated both with workers and managers.

Hence, the desire to freeze the organizational system.

Along comes a troublemaker. A person who does things different. Who won't accept "That's how we always done it" for a reason. Who breaks rules to get stuff done. Who bypasses hierarchies getting in the way of success. Who messes with people following dysfunctional processes without further ado. Like - me.

In a frozen state, the organization will consider such a person a dangerous foreign body needing to be dealt with. A single person faced with frozen organizations will be forced into one of two choices: adapt - or get out. That's why change initiatives are well-nigh impossible without a strong guiding coalition as proposed by Kotter: It's not about doing things differently, it's about accumulating a critical mass of people with sufficient power to unfreeze the system before even bothering to really go on with the change agenda.

Liquid = Nonlinear

Getting out of a solid, frozen state in physics requires dissolving the bonds between system components. Depending on what you want to change, you may need to un-link structure, people and processes alike - simultaneously!

Dissolving links means that communication structures will no longer work as before, processes will no longer produce the same outcome - and results on any level may change. The bigger the incision, the more likely unpredicted side effects will occur.

People lose the feeling associated with an order state - predictablity wanes, reliability is reduced and people start experiencing the discomfort of needing to think and connecting dots differently. When essential, strong links haven't been dissolved, the system returns back to the former stable state as soon as possible and may even obtain resistance strategies - inoculation to ward off future change.

Going back to our physics analogy, we need to invest energy into an ordered system to unfreeze it. The amount of energy needed to make a permanent change in an ordered structure directly correlates with the strength of the links which need to be broken.

Let's take the example of water:
It takes a rather limited amount of energy to melt an ice cube.
With significantly more energy, we could split the molecular bonds and turn the ice cube into H2 and O2.
Should we desire to reform the very atomic bonds and turn the hydrogen atoms into helium, we need to invest a lot more energy into a much riskier and complicated process.

In either case, the former state will cease to exist - and that's where reactions such as fear, grief (Kübler-Ross) and entitlement come in.

Volatile = Chaotic

Volatile systems do not display the characteristics of an ordered system. The high energy inherent to each particle allows them to move rapidly - making it extremely difficult to predict the next state of even a single component in the system, much less enabling methodic control on the overall system.
In a chaotic state, change doesn't require an investment - it happens continuously and without trigger. Change isn't something that needs to be initiated, much rather, it would need to be channeled to produce something desirable.

In a volatile state, the system's drive to change is bigger than any component's capability to stabilize, hence no change is permanent.

A molecule in a gaseous state would not consider this state "anomalous" - much rather, it would need to be deprived of its energy before entering any other state.

And this is an important part of volatile systems - the components have high amounts of energy!

Like order is produced by draining energy from components, chaos is produced by energizing components.

State transitions

Material state transitions can be measured and predicted with high accuracy - something not quite as simple when dealing with an organizational system combined of a complex structure including many individual people, highly interrelated processes and potentially an innumerable amount of technological dependencies.

State transitions in a frozen organization are often considered undesirable, as people are afraid that something will get broken for good:

As the  "frozen" state of an organization becomes stronger, the more energy will be required to reach the "un-freeze" state which makes state transition possible. Combined with the complexity of the system, the amount of energy required for a successful defreeze might be roughly the same amount required to enter a volatile state - and depending on the size of the desired change, an excursion into a chaotic state may be required.

When being unfamiliar with the chaotic domain, there is both the danger that chaos gets out of hand or that when the system gets into a stable state again, that state is undesirable.

The false Order-Chaos dichotomy

Frozen systems are stable, but they aren't very malleable. The key characteristic of frozen systems is their lack of energy. An organization with stable structures that lack energy is in constant danger of being stuck in the wrong place - and won't be able to make the necessary move to remain sustainable.

On the other end of the spectrum, chaotic systems aren't stable - and equally un-malleable, albeit for a different reason. The key characteristic of volatile system is their high energy - and therefore, the impossibility to ever nail down anything.

It's not so easy to say whether order or chaos is better - that would depend on what you want to achieve. Based on the points above, we should realize that we're not forced to choose between order and chaos. The choice is a false dichotomy.
Just because water isn't ice, it doesn't mean that you'll die from steam burns.
It could equally be a refreshing glass of cool water or a warm cup ready to make some tea.

The idea "If it's not ordered, then it's chaos" is nothing more than a false dichotomy: There's a large spectrum of conditions between frozen and volatile - and while neither of the two extremes is specifically habitable, the range inbetween very well is.

Get used to change

When you look at a glass of water, you can't tell where every single molecule is. Even if you knew where it was five seconds ago, you can hardly tell where it will be in a few seconds. At the same time, you can tell a few things with fairly high confidence:

• You're looking at a glass of water
• The molecule in question is within that glass of water
• That molecule will still be within that glass of water in a few seconds.

You can even make more reliable predictions:

• If you throw a pebble into the glass, the water will (for the most) remain where it was.
• The pebble will not significantly affect the way your water behaves.
• When you take the pebble out, the water will look like it did before.

Interpreting the analogy, the liquid, non-linear state is both more flexible than the ordered and more reliable than the chaotic state. 

If you want to keep your organization robust to outside interference, you need to abolish the idea that everything needs to be in place: The ordered state can't deal with changing circumstances. 

In an ordered state, Lewin's "unfreeze-change-refreeze" process is essential to adapt.
In a non-linear state, there is nothing to unfreeze, and nothing in need of being re-frozen.

The practical interpretation

We talk a lot about "Agile Transformation", and in the minds of people this is unfreezing a non-agile organization, changing it towards an agile organization, then refreezing it in its agile state.
There is no such thing.

The agile organization is like water, constantly in a nonlinear state. Change in an agile organization isn't a project. Instead, everyone and everything within an agile organization is constantly subject to change.

Every person thinks about new, better ways to achieve things every day - every process can be scrutinized and modified at any time. When outward circumstances change, the agile organization doesn't start a massive adaption initiative, they just do what it takes to deal with the new circumstance.

And that's why you can't "buy agile" - to be agile, you must be in that liquid, transient state - at all times!

The "Technical Triangle" of Effort Distribution

"The TQB Iron Triangle" has long since been overhauled. Still, there is a tradeoff that we need to make - and we all do this, every day. Unconsciously. The Effort Distribution Triangle is one way to bring the tradeoffs we make into visibility, so we can have a meaningful discussion whether we're making the right choices.

The Model

The label indicates "We aren't investing into it" and the opposing line indicates "Everything invested into resolving this".
The normal condition would be somewhere in the middle.

We have 100% of our effort to distribute. We can invest it any way we choose into delivering features, improving technology and discussion about goals and methods.
Regardless of how we distribute our effort, 100% is 100% - so choose wisely!

Opportunity Cost

By delivering features that might add value to our product, we do what development teams are supposed to do: create tangible business value. We always need to keep sight of business value, as this is the purpose of doing development work.

At the same time, excessive focus on delivery might cause us to neglect the underlying technology or communication.
In turn, the risk we run by spending too much time aligning and optimizing our technology is the time we lose on innovating and delivering things others need. This is our opportunity cost.

Technical Debt

Phrased positively, "Continuous attention to technical excellence and good design enhances agility."
It allows us to get more things done faster, and make changes with less effort.

Taking a pessimistic view, everything that isn't as good as technically possible can be called "technical debt". We always have technical debt, so at best we can control whether we consider the debt pressing or not.

Sometimes, we just want to get something through the door, and we're cutting corners on a technical level. We might have skipped the occasional refactoring, or anything like that.
Without accusation, I have observed many developers who prefer spending time on improving technology over time spent in meetings. While there are bad meetings, the consequence might be that some people don't understand things they should understand - communication debt!

Communication Debt

As mentioned in another article, "communication debt is the communications we should have had that we didn't have".
Good communication provides alignment, transparency and clarity of purpose. It's the basis for autonomy and self-organization within a company.

Communication takes time. Scrum, for example, dedicates five Dailies per week, plus one Planning, a Review and a Retrospective plus occasional Refinements - for a total of roughly 15% of your calendar to pure communication, and it's incredibly difficult to function as a team by going any lower. And that doesn't even include work floor communication, such as whiteboard design sessions, pair programming, code reviews and whatnotever.

Communication effort is an integral part of your total capacity to do things.

While some effort put into communication is in fact part of your ability to optimize both delivery and technology - there is also communication aside from that: Like letting other people know what you're doing, letting them learn from you or learning from them.

Make your choice

Take your pick anywhere on the triangle. Discuss the long-term consequences of this choice with your team. This choice is never once-for-all, you can always change it. Yet, there are choices of strategic nature and choices of tactical nature.
Strategically, a delicate balance is most suitable to maximize sustainability. Tactically, the team might decide to go all-in on technical improvements or feature delivery. That's not viable - so the Scrum Master and Product Owner should keep an eye that the triangle doesn't get too lopsided for a prolonged period of time.

Closing question

Who in your organization is making that choice for your team - and who is aware of the consequences of this choice?

Rules in a structureless organization

A critical aspect for Structureless organizations is how they deal with rules. One might think, "As soon as humans need to deal with each other, we need rules". Yes and no. Let's explore how rules change as an organization becomes Structureless.

We will explore the topic by starting with an unstructured organization, then progress from there.

Unstructured rules

Martial law - Unstructured rules

Unstructured organizations have rudimentary rules, which are often simply made up on the spot, either ad hoc or post hoc. Rules mostly serve as a means to protect existing power structures, i.e. to beat others into submission and to exhibit superiority.
Rules are made exclusively by those who have power, and the rules serve them and their interests.

There is little mention of rules unless one is quoted or created to deal with a specific situation - and even then, the rule is hardly ever communicated to anyone beyond those involved. There is no examination whether these rules are consistent, conflicting or even make sense.

Most rules are arbitrary and wouldn't stand up to scrutiny, yet they never get challenged, as challenging them would equal challenging those who hold the power. The only people who will challenge rules are those higher up in the food chain, and only when it serves their purpose. This is usually not necessary, as further rules can be added at any point in time, as the lack of transparency around rules will already ensure that nobody realizes the conflict.

The following characteristics are symptomatic of "rules" in an unstructured organization:

1. Double Standards: Rules apply only to some groups. Others are exempt from the same rules for no transparent reason. For example, favorable rules apply only to those with power and unfavorable rules only to others.
2. Rules that don't solve problems: Rules serve more to shame those who have infringed upon them than to solve a real problem.
3. Post-hoc rulemaking: When a situation occurs that is unpleasant to someone in power, rules are set up post-fact as a smoke screen to deflect the blame.

Such rules will never be written down, as the mere prospect of doing so might end up in a lawsuit. Those in power will make sure that it stays like this.

Indirectly structured rules

Indirectly structured organizations do have rules - and lots of them!
There seems to be a rule for everything - and most of these rules are highly formalized. They are intended to prevent any potential misunderstanding.

Most rules serve as a means of avoiding the need to address the root cause of the problems which have surfaced in the past, and every action of people is encompassed by some form of rule. Similarly to unstructured organizations, there is little discussion around whether rules make sense or are even applicable.

When people are unsure what to do, they will either try to discover which rule needs to be applied, or will look to someone in charge to provide a rule. In fact, people will try to avoid situations where no existing rule can be applied, as this poses an undetermined challenge. People tend to be more concerned with keeping the rules they have than whether these rules make sense.

Rules in indirectly structured organizations serve a more noble purpose than those in an unstructured organization. There are actually two different purposes:

• Providing safety to those acting upon the rules that their actions are meeting prescribed standards.
• Providing a sense of reliability to those creating the rules that people will act predictably.

The most denominating characteristic of indirect structures is the separation of decision and execution: Those making a decision are not the same people as those acting upon that decision. The indirection is in full effect when people state, "If you want to know why - please ask that person!"

The following three items are symptomatic for rule-making in indirectly structured organizations:

1. Decision proposals: Instead of just doing the right thing, people need to prepare formal proporals with slide decks for managers to get approval for doing what they feel should be done.
2. Central Process Decisions: It's not the people doing the work deciding what the best way to do the work is, but some people who - for some reason - are believed to have some form of superior knowledge about this work. This often comes with a Process Management division defining SOP's.
3. Finger-Pointing: People would rather apply an inappropriate process than admit they are not aware of what needs to be done. They can point to someone who prescribed the process and will claim inaccountability for the consequences.

The rules in indirectly structured organizations are often religiously followed by people at lower levels of the organization, while people on the higher levels are hardly aware of their existence. 

Managers in indirectly structured organizations are often even aware of this problem, yet are unable to trace this back to the system they have created.

Directly structured rules

Directly structured organizations oddly have fewer rules than indirectly structured orgs!

Rules are less constraining and prohibitive than in an indirectly structured organization, as they are aimed more at clarifying structure, helping people organize themselves and getting things done than at stopping undue actions.

Rules serve everyone and no longer treat everyone equally unfair. Rules acknowledge context and provide guidance. Rather than abolishing the application of common sense as an indirectly structured organization would, they guide common sense decision making at every level. Unlike indirectly structured organization, inapplicable rules are scrutinized and reworked as needed.

Rules help people discover the most sensible course of action without being prescriptive on the course of action, permitting leeway for sensible choices. As the social and procedural context of the work might be dynamic, people need to be comfortable with discovering the best way to move forward. Rules would only be created when those doing the work are unable to produce a desirable result.

Rules in directly structured organizations serve an even more noble purpose than those in an indirectly structured organization. Rules are directed at:

• Providing a basis for mutually beneficial, positive collaboration.
• Providing consistency on a larger scale.
• Avoiding preventable fault, thereby providing psychological safety for those doing the work.

Direct structures align need and provision: Those who have the need are able to either resolve it by themselves or directly access those who can. Rule decisions are made by those who can see and affect the outcome of their choices. The most sensible form of rule making in a directly structured organization is by asking those at the receiving end of a rule which kind of rule makes most sense for them.

Characteristics of rules in a directly structured organization include:

• Alignement with business goals: Rules support the work, rather than impede it. Rules that contradict business goals will be revised.
• Scrutiny: Everyone may discuss rules, and this doesn't happen out of frustration, but to drive improvement. Rules that no longer serve their intended purpose might be abolished or changed.
• Consistency: Conflicting rules which would result in a stalemate get revised.

Rules in a directly structured organization clearly correlate purpose and outcome. It's not essential for people in areas unaffected by the rule to know about the rule - and when effects occur that are not intended by the rule, it will be subject to scrutiny.

Structureless rules

The weird part about rules in a structureless organization is that they don't seem to exist. This, however, would be a misunderstanding as rules actually do exist - except that they are usually implied rather than defined and people don't even feel the need to formalize them, as this formalization does not add any value.

In general, the need for rules decreases as mutual understanding and alignment increase - and the high levels of collaboration in a structureless settings foster these things. While the creation of collaborative bonds usually requires a clarification of mutual expectations, rules are often not very helpful, because they are created with a lot of ambiguity and therefore, often misdirected. Much more important than setting a rule is aligning on the intended outcome of collaboration and creating an environment where impediments are quickly addressed and resolved.

Formal rules in structureless organizations are usually externally imposed, such as laws. It goes without saying that structureless isn't anarchy - so such imposed rules need to be maintained. As they are not an intrinsic part of the organization, people will discuss these rules not in a setting on what to do with them, but on the easiest way to get along with them.

Because structureless organizations no longer care about the rules themselves, discussions aim at:

• Finding positive, effective ways of collaborating
• Aligning mutual perspectives, understanding and outcomes
• Resolving issues which might otherwise require rules.

Nonetheless, these are already implicit rules - the rules of getting along and communicating. Probably the most important implicit rule of a structureless organization is the "No Asshole Rule". It will never be mentioned, as the mere need to mention it already means that a problem occurred that should not exist.

Characteristics of the rules in a structureless organization include:

• Implicit: Probably the most important characteristic is their implicitness: Rules do not need to be formalized, because they are implied by interactions.
• Minimal: Since rules cause or hide problems, they are a "last resort", when all else failed.
• Ephemeral: Structureless organizations rely on being able to constantly change and adapt, so rules might simply disappear when their context disappeared.
• Local: Rules would only exist in a local setting, and there is no attempt trying to consider whether they could be generalized to a broader context, as if there was a need, it would pop up anyways.

Structureless organizations aren't about rules. They are about aligning, collaborating and moving forward. When considering, structureless organizations have a lot of implicit rules - potentially more than the explicit rules found in an indirectly structured setting. The big difference is that rather than being in a manual nobody has ever read, these rules live and are part of people's lives.

Summary

An unkeen observer might confuse structureless rules with unstructured rules - although the difference is immense! Whereas unstructured rules are makeshift constructs to preserve power, a structureless organization understands the advantages and disadvantages of formalization and has moved from the level of top-down exercise of power to mutual understanding.

Structures are created to minimize communication over rules, assuming that rules can be formalized in an unambiguous way. Structureless organizations acknowledge that communication is essential to move beyond a limited and superficial mutual understanding. Once the necessary communication over collaboration has happened, the need for formalization disappears. Hence, the rules become implicit rather than explicit.

Communication in a structureless organization

How do structureless organizations communicate - and why is that an advantage?

In a recent post, I addressed the topic of "structureless organization" from a maturity perspective. Let us explore structureless communications by comparison.

Unstructured communication

An unstructured organization doesn't have direct, congruent or consistent links between people. Somehow, everyone fits into the picture - but this "somehow" may neither be meaningful nor helpful to the organization or its customers.

Broken links, ineffectivity everywhere: Unstructured!

In the above illustration, there are inconsistencies between formal and lived structure (center), people who are somehow isolated from the structure (on the left) and broken links (manager to CEO). This means that necessary communication either doesn't happen - or only by chance.
An unstructured organization amasses communication debt at the missing links!

Now, let's look at what the communication looks like:

Rabbit Trails, Loose Ends - good hunting!

There are two communication chains. Assume you are a customer and need something that only the person (!) can help with.
Should you happen to address person (1) in the picture, they will refer to their manager, who will refer to another employee, who will refer to a coworker, who will ... blah yada yada -- until another manager gets involved, who will address an employee who happens to know the person who can help you. There's a good chance you've already stopped in frustration before you ever meet person (!).

Should you be so unlucky to address person (A) in the picture, they will refer you to person (B) - and you are none the wiser.

Of course, "unstructured" is merely a strawman as this is definitely an undesirable state for any organization to be in. Just be aware that even within your structure, there may be unstructured areas that simply "fall off the chart".

Indirect Communication

An indirectly structured organization has directed and usually consistent links between people. The only downside is the nearly inevitable incongruence between need and structure. 

A typical org chart

This is what a typical "org chart" looks like. Communication is centralized around managers, who then delegate the task back into their own unit, until an executable level is attained. The idea behind this is to maximize the efficiency of the workforce by minimizing the amount of disruption due to inadequate requests.
And this is how the communication is intended to flow:

Don't worry. You will get an answer. Eventually.

When you have a request that needs to be served by Team Blue (Tech), but your contact point is Team Red (Customer Service), the request will be judged by their manager, who will then take it yet one level higher, who will then inform the division manager, who will then inform Team Blue. The only good news in this one is that even though you have a long wait, something is eventually going to happen. It just takes patience.

Let us examine what happens when people are missing: Flu season is coming!

In this example, the blue manager has delegated represenation (<) to (?), so when Manager Blue is missing, (?) will act in their stead. This works out quite well when only one person is missing at the same time. However, when (1) needs a specific kind of help from team Blue, and the person named by Manager Blue as contact (?) is also missing, the communication chain is broken. When (4) realizes that neither (<) nor (?) is available, they might approach one person that occasionally also represents (<) - (5). However, that person is equally unable to help and so, the matter might remain sticking around until (<) returns. Usually, by then, the issue will be rotting as mail #51194 in Blue Manager's mailbox - abandoned, forgotten.
In the worst case scenario, person (1) would require something from their communication partner (2), but has been named representative of (2) and the superior of (2), namely (3) is also missing - so (1) might be stuck in a catch-22 - making indirect structures similarly susceptible to fault as unstructured organizations.

Side note: I happened to work for an organization once where the CEO claimed in an official newsletter that "if everyone would follow the defined communication paths and stop addressing other departments directly, we would be much more efficient". Does he really believe that?

In reality, most communication in org-charted, indirectly structured organizations happens outside the formal chart - because it's so terribly ineffective. They implicitly create - direct communication, just to be able to get things done.

Direct Communication

The issues so commonly often associated with indirected structured can abysmally hamper an organization. Silo structures with broken escalation chains lead to tremendous inefficiencies. Direct structures resolve this matter by installing direct points of contact between departments who reduce both the amount of managerial involvement as well as the amount of steps required to get something done.

We know who can help you.

The typical term commonly associated with direct organizations is SPOC - "Single Point Of Contact". A senior member of each unit who is familiar both with the work that can be done by the unit and the people doing the work within the unit is assigned "SPOC". This person can be approached by anyone regarding requests within their unit, so SPOC Red would receive all requests done by Team Red.
SPOC's are transparent, so a customer would either approach SPOC Red directly, minimzing the amount of overhead - or, if they don't know who SPOC Red is, they would approach anyone who would immediately know that SPOC Red needs to be addressed.

Optimized for efficient communication

SPOC Red might either handle requests to Team Red immediately or involve any team member from Team Red who can help. If SPOC Red receives a request that would massively interfere with how Team Red operates, SPOC Red will involve Manager Red for a decision.

The reason why many organizations do not move towards direct communication is fear - managers fearing the loss of control.

In a directly structured organization, managers aren't even aware of what their staff do most of the time. They operate autonomously to do what they can do to help the organization. This requires trust. 

So - are there any drawbacks? None that would warrant going back to indirect structures. Compared to indirect structures, there are no business relevant downsides to establishing direct structures.
The only drawback is queuing - the SPOC is an implicit queue. In some cases, the queue becomes explicit by having a ticket system where the SPOC stores and distributes requests. The more SPOC's an organization has, the more queues they own.

How do we solve the queuing problem?

Structureless communication

Queues are horribly ineffective to manage - request load is hardly ever balanced in the working world. While one SPOC idles, another might not know how to handle all those requests. Managers might be tempted to install multiple persons as SPOC - increasing the throughput of the queue without ever addressing the issue why the team receives so many requests.

Structureless organizations are different:

In a structureless organization, communication paths are replaced with communication networks. Each person has their own, individual network of persons they collaborate with to get their work done. Managers in a structureless organization work fundamentally different from indirectly structured organizations: instead of controlling the work and communication, each manager supports their own people in order to collaborate better.
Structural boundaries start to lose importance, as the manager's focus moves from departmental efficiency towards organizational effectiveness.

And this is how structureless communication happens:

When someone (1) in team Blue needs something they aren't familiar with, they ask around in their network. Maybe this is another colleague or even the manager - no reason not to. Manager blue might refer them to another person who works closer to that area of expertise, but who might not have the answer either. This person will then check their network until they found someone who can help.

This is where the Bacon Rule kicks in, which posits that the maximum separation path between any two people on Planet Earth would be six, so usually within an organization, there would usually be four or fewer leaps until someone (!) is found. Once help is avaiable, the person will connect directly with the requester - so the next time, no communication path would be traversed.

In a structureless organization, neither Manager Blue nor Manager Red are concerned with what (1) or (!) are doing and how much time it costs: If it's the most important thing for (1) to work on, there's a good chance that (!) benefits the organization as a whole by chiming in.

What happens in a structureless organization when people go missing? Not much. First, people get familiar with the work of people done in their network, so they might actually be able to do part of it by themselves - otherwise, they do have some insight who the contacts of the missing person are and will ask around there.

I would like to conclude with a small illustration of what happens in a structureless organization when one person leaves: Fill a bucket with water and put your hand in. Look at the water, look at the hand. Take your hand out. Look at the hole it left ...

In a structureless organization, you are treasured part able to contribute. No bad things happen when you leave. You are free to be where you are or go somewhere. The organization can cope with it. No bad feelings when you're on vacation.

Summary

From an objective perspective of reason, there is no reason to not move towards a structureless organization. This does not mean that there are no arguments against structureless. Most of them fall into a fear category:

1. Fear of the Unknown ("I don't know what Structureless is")
2. Fear of Poor Results ("But we won't reach our quota")
3. Fear of Losing Control ("I don't know what my team will be doing")
4. Fear of Lack of Authority ("But people need to be told what to do"), or vice versa:
5. Fear of Uncertainty ("I won't know what to do unless someone tells me")

All of these fears can be handled, although this takes a lot of time. Once someone has seen the beauty and effectiveness of structureless organizations, most of them go away. 

To conclude, I will provide you with some examples of structureless organizations:

1. Your friends. Nobody manages the bunch of you, yet you still get along.
2. Any well-functioning team. There might be managers, but it's about getting things done, not about following structure.
3. The agile community. Not only do we have vastly differing opinions and goals, we also argue quite a bit. But we can well get things done.

Moving towards a structureless organization

In a recent post, I explained the concept of "Structureless". Let's dig a little deeper into how we can explore this concept to build high-performing teams and organizations.

Structural Maturity

Without explaining the above model too much further, let's see how we can use this model in team organization.

Unstructured Organization

It's very easy to set up an unstructured team - basically, all you need to do is: nothing. Even then, people dislike the chaos that ensues and will usually self-organize to create at least some kind of structure. What I see happen as a first step to move away from the total lack of structure is contact lists - people making lists who can be contacted for what.
This is often the first thing people would do when confronted with a new working environment.

Key characteristics:

Complexity	Not clear People try to make ends meet. It's unknown how complex the system really is.
Consistency	Low Nothing is really known. There might be be problems hidden beneath the surface, which aren't even explored. When they surface, the way forward is unclear.
Effectiveness	Low Unstructured organizations are significantly less effective than even the added potential of each.
Problem Solving	Ad hoc Most problems never get addressed. Workarounds are commonplace.
Role Distribution	Ad hoc The best way to describe how roles are distributed is: "Might makes right". People either grab roles they can meet in ways that please people in charge or are assigned a role.
Internal Satisfaction	Low There is constant dissonance between expectation and reality, bursting out in occasional conflict.
Customer Satisfaction	Low The customer is the least problem people would care about.
Next steps	Discover what structures already exist Discover who is responsible for what Make communication paths visible Close communication path gaps Create a "skill matrix" who contributes what

Indirect Structured Organization

Indirect structures solve the problem of not knowing who to address when or for what. The indirect structure tends to rely on bottlenecks, i.e. communication paths that are used more often than they are available. Most organizations never make the leap away from indirect structures, as those are already stable. Moving beyond this indirection means resolving the bottlenecks - and some people use their bottleneck status as safety zone.
Typical bottlenecks are managers who insist on being part of communication chains and irreplacible specialists.

Key characteristics:

Complexity	High Indirections add complexity to even simple requests.
Consistency	Low When indirection chains break, processes or requests might be hanging "mid-air" without being resolved. Major effort is required to maintain consistency.
Effectiveness	Low The bottlenecks inherent to the communication chain reduce the effectiveness of all those who rely on anything provided by a bottleneck.
Problem Solving	Sporadic Problems get addressed when a bottleneck is aware of a problem and has an interest in resolving it.
Role Distribution	Reactive Communication paths typically determine a person's role aligned with their communication network. A person's role is often defined by the bottlenecks which limit their progress.
Internal Satisfaction	Moderate Bottleneck roles tend to have high satisfaction, both from the feeling of being needed and the power at their disposal. Those limited by bottlenecks tend to get frustrated when blocked.
Customer Satisfaction	Low Indirection is a customer's worst nightmare. The complexity of the structure becomes the customer's problem one way or another. Not getting responses, delayed responses and unproportionally high transaction costs are just some symptoms.
Next steps	Discover where the bottlenecks are Address the indirection issues Strengthen direct communication paths Create a "delegation matrix" to relieve the overburden of bottlenecks

Direct Structured Organization

Direct structures emphasize the value of getting things done. They regard results higher than personal affinity and value outcome over process.
Very few organizations make the leap from indirected towards directed structures, and this relies especially on "managers getting out of the way". Direction requires re-thinking the manager role in fundamental ways. The toughest nut an organization needs to crack when moving towards direct structure is Larman's Law #1, the implicit optimization around preservation of personal power.

Key characteristics:

Complexity	Moderate. Indirections add complexity to even simple requests.
Consistency	High. Processes do not rely on single points of failure. Managers/specialists move from being bottlenecks towards creating robust structures that reduce reliance on their involvement.
Effectiveness	High. Centralized structures remove redundancies and optimize for "The Greater Good".
Problem Solving	Systematic. Problems get resolved where they occur, by those who have central control over the domain.
Role Distribution	Planned. Roles are typically created to meet a specific need. Communication paths are then updated to integrate the role properly.
Internal Satisfaction	High. People know what they are doing and where they fit in.
Customer Satisfaction	Moderate. Customers get the impression that people know what they are doing and that their requests move forward. They do not like that the company's structure is their problem - at least to some extent.
Next steps	Simplify request processing from a customer perspective Instill a "customer centric" mindset in those not directly working with customers Identify the communication issues that exist

Structureless Organization

The structureless organization is not to be confused with an unstructured organization. Instead of optimizing for reaching some kind of internal goal, a structureless organization sacrifices internal efficiency for meaningful outcomes. Redundancies are the means by which a structureless organization generate robustness without falling victim to stasis. 

Managers are no longer the joints by which organizational units move, instead they become the glue keeping the construct together.

Specialists move from adding value by executing on their topic towards enabling others to excel in their field.

Key characteristics:

Complexity	Low. From an individual's perspective, complexity may appear to be higher, as each person requires to be in contact with more people. From an organizational perspective, complexity is reduced, because less formal communication is required.
Consistency	High. People are not concerned with structure as much as they are with collaborating to achieve results. Where communication links are missing, "self-repair" will create the most effective new links.
Effectiveness	Extreme. Removing indirection and structural overhead results in maximal effectiveness from an organizational perspective. Decentralization removes the local inefficiency and the need for ineffective compromizes.
Problem Solving	On the fly. Problems get resolved where they occur, by those who are involved in their occurrence. There is no longer a concern for local optimization, as decentralization removes the problem of needing to globally optimize.
Role Distribution	Irrelevant. Roles are simply no longer important, as the focus moves from "job descriptions" towards contribution potential. Even leadership becomes situational to meet specific needs.
Internal Satisfaction	Extreme. People are able to align their personal sense of worth with the company's goals. Motivation and morale become non-issues.
Customer Satisfaction	High. Customers feel that the company is out to please them, and everyone is pulling in the same direction.
Next steps	Be aware of the danger of falling back into old habits Strengthen informal links Continuously improve

Summary

It's not inherently bad to be in any given stage, even if that stage is "unstructured" or "indirect structure". The important pieces of the puzzle are understanding:

1. At which stage you are
2. Why you are there
3. What can you do to move forward
4. Why it's worth moving forward

While I think that it's possible in theory to move directly from unstructured or indirection to structureless, my personal observation has been that this is extremely difficult. I personally like to move towards direct structure in a matter of days or weeks, and enable structureless from there. 

The most important piece of the puzzle is understanding that once we stop with an indirect or direct structure, we create a stable condition where change becomes increasingly difficult as time proceeds.