Predictability in middle management? Good luck!

If you’ve ever worked in middle management, you’ve likely felt stuck between chaos from below and control from above. Executives demand structure, predictability, and process adherence. Teams, on the other hand, thrive on flexibility, adaptation, and autonomy.
And the manager? They’re caught in the middle, playing a never-ending game of Rock-Paper-Scissors.

Management: A Game of Rock-Paper-Scissors

You may wonder: What do management and Rock-Paper-Scissors have in common? Middle management is a shark basin - the other a lighthearted, simple hand game often played by kids. I often thought about how to explain what happens in middle management to people unfamiliar with it - and came up with this game as a simple model of what middle management has to deal with.

The Three Moves

As a middle manager, you can ultimately play only one of three moves:

Rock = Stability

Large companies are noisy, chaotic and unpredictable. Playing "Rock" means standardization, consistency, documentation, governance, and regulatory compliance create some predictability.

On the downside, an overuse of Rock makes the process itself the goal, and that causes tremendous waste.

Paper = Delivery

Paper is about taking action, getting stuff done, and produces measurable outcomes. With increasing levels of repeatability and reproducibility, performance becomes scalable.

Paper work is smooth. (all puns fully intended.) Unfortunately, Paper will eventually lead to "doing efficiently that which should not be done at all" (ref. Peter Drucker) - and the biggest threat to businesses is investing into results nobody needs.

Scissors = Disruption

Scissors cut through waste, inefficiency and outdated practices. A play of Scissors is leading innovation, making changes, and turning processes upside down - doing something new, or in ways that were never tried (here) before.

The opportunity of Scissors are immense - and yet, an overuse of the Scissors kills productivity: It destabilizes the organization, causing confusion and chaos.

So then - what is the best move? None.

Let me explain.

There's No Single Best Move

Every move creates the conditions for its own counter:

• Rock sets the basis for productivity - but ultimately, Rock itself is unproductive. Hence playing Rock means that Paper (being productive) becomes the next best move.
• Paper means being productive - but also, outdating. A prolonged period of playing Paper must be followed by a play of Scissors (change).
• Scissors cuts the waste - but it causes chaos: forcing Rock (stability).

The Real Complexity: The System Remembers

Middle management is a game played over time and not in isolation. Past moves shape future conditions. There are other players (your fellow middle managers, your teams - and your customers.) To win, you must think several steps ahead:

• Focus on Rock - and you'll lose to Paper. The player who plays Paper in a game of Rock, Rock, Rock - becomes the winner by default: being a results-driver an environment valuing process conformity over outcomes will be a refreshing change to senior leadership.
• Focus on Paper - and you will struggle with Scissors. The player who brings a novel idea into a stagnant organisation wins, as even small, actionable changes can make a world of a difference.
• Focus on Scissors - and you can't handle Rock. When you're constantly facing the reinforcement of status quo, change will be ineffective - regardless of how good and necessary.

Moving in sequence

And now comes the key challenge: "what should you play next?"

Let's explain what the real problem here is: You're playing a Multiway Rock-Scissors-Paper. You're playing against others (a solvable problem), but you are simultaneously playing against your own past and your own future.

We have established that if you played Rock yesterday, your best move today is probably Paper. And if you play Paper today, your best move tomorrow is Scissors. And after Scissors, you'll have to play Rock again.

But that means that you've got to make a tradeoff between scoring today, and scoring tomorrow. And you can only score today if you prepared for it yesterday.

So then, it's all clear: Play Rock, Paper and Scissors in succession.

Right?

Well - not so quick!

Making a winning move

Even if we assume a fully predictable system - the issue is that you're not playing alone. You're competing with other managers on budget, with other companies on market share, and with customers on business versus customer needs.

So if you played "Rock" yesterday, and you're fully predictable, a competitor will play Scissors on you - because you'll be playing Paper today, and that means, you'll lose.

But then - if you can't play Paper, should you play Rock? Well, then you're not being productive, and then your customers will play Paper on you.

Wouldn't that mean the safest bet after a Rock move is Scissors? Yes.

Except - because it's the safest bet, others will prepare for you playing Scissors by playing Rock.

So you should play Paper?

You see where this is going.

Your own predictability is reducing your odds of making a winning move - so your best chance is to not create any hints on what your next move could be.

The winning strategy: unpredictability

We've discovered that being predictable is a losing strategy.

And a manager always playing the same move is definitely predictable - hence, a single move can not be a successful strategy.

We've also seen that a sequence is also predictable, so "Stabilize, Perform, Disrupt" as a cycle is also not a winning strategy.

That leaves only one strategy for success:

• Play all three moves dynamically, and never lock into a single mode.
• Introduce controlled unpredictability to avoid becoming exploitable.
• Plan for future moves (n+2), not just the next one (n+1).
• Break your own pattern before the system forces you to.

And the desire for Predictability? That's the Problem.

Stakeholders constantly demand predictability: "We need a roadmap." "We need a deadline." "We need clear processes." "We need clear roles." Oddly enough, these demands create the very unpredictability they despise:

• Playing Rock (stability) reduces performance, requiring a rapid move to Paper (performance). And that means less focus on "How", and more focus on "What and When."
• Playing Paper (performance) leads to stagnation, inviting Scissors (disruption). This is going to be uncomfortable, but the only way to remain in business.
• Playing Scissors (innovation) leads to chaos, demanding a follow-up with some solid Rock (stability). But the people who thrive in creative chaos are the first who leave when things get cast in stone.

There’s No Easy Way Out - just a smarter way to play

The fundamental truth of middle management is that it is not a "problem that can be solved:" it is a system that must be navigated.

• Expect stability, and you'll be blindsided.
• Expect performance, and you'll be sidelined.
• Expect innovation, and you'll be slowed down.

Winning in middle management isn't about picking the right move - it's about ensuring you remain ahead of the game and are ready to make your move at the right time.

The only way to be sustainably successful in middle management is that you must know all three moves, you must know how to play them well, you must know when to play them - and what to do when one is being played on you. And why you can't win by locking in any of them.

So, the next time someone asks "predictability in middle management" - just smile. Because now, you know the truth: Good luck.

The Phenomenon of Prevalence Induced Concept Change

In organizational change, people may respond to improvements in unexpected ways - even though things are getting better, they may be under the impression that things are getting worse - and they may even have data to back up their claims! So, how do you get out of the dilemma of having to justify improvement without starting a theoretical debate detached from what people see, hear and feel?
In this post, we will take a peek at a typical case of Prevalence-Induced Concept Change (PICC) and how to address it in a constructive manner.

What is Prevalence Induced Concept Change?

"Prevalence induced concept change" (PICC) occurs when the frequency of events changes, leading people to modify their definition of what constitutes a problem. This shift in criteria means that as major problems become less common, minor topics start to gain more attention and are perceived as more significant than they actually are - or in reverse!

We will take a common example connected to "Agile Transformation" to illustrate our case - although you may encounter PICC in many forms and shapes.

Transitioning from Classic Project Management

In Classic Project Management, we have our ways of doing things, and everyone knows that nobody's perfect, so there are always some concerns. But, we have arranged ourselves with them, understand them, and how to manage them.

Classic Project Management

• Long-Term Schedules - Projects span several months, with a final delivery date set well in advance. The impact of missing a timeline tends to be massive, and a slippage in schedules requires serious management attention.
• Delayed Feedback - The first feedback comes on "Release Day," and the events on that day tend to be overwhelming due to the sheer volume and severity of problems that went undiscovered during the project.
• Hidden Issues - Problems remain undiscovered until late in the process, making them costly and difficult to address.

And now let us contrast that with a more modern approach.

Modern Delivery Approaches:

• Rapid Cycles - Large projects are divided into short cycles, with intermediate evaluation points.
• Frequent Feedback - Developers receive timely feedback on completed work in small batches.
• High Transparency - Problems are identified and addressed quickly, promoting continuous improvement.

This leads to many follow-up questions: First, how do we even work in a way that we can collect feedback faster - and second, what do we do when we get "bad feedback?" Especially in organizations where Continuous Improvement is not systematized in project management, the question "what do we do with the feedback" can lead to a quagmire of followup concerns that can completely derail a team if not properly addressed.

The Impact of PICC

An organizations advancing from classic project management to a more modern delivery approach may have stakeholders fall for PICC and misinterpret the nature and frequency of what's going on:

• Buffer sizes - By slicing a large project into a sequential set of deliverables, the project gets more checkpoints, and each of them gains a small buffer. So a buffer overrun on one of them is not even an issue - the main timeline is not even in danger when a day of buffer has been consumed! However, a buffer overrun may lead managers to overreact who are used to a buffer overrun always requiring management intervention.
• Higher Expectations - With frequent deliverables, stakeholders have more time to focus on individual deliverables, so they will pay more attention to minor issues they would never have noticed in a project where it was normal that half the scope was unusable upon delivery.
• Perceived Underperformance - A successful product review will always elicit improvement potential, and the constant appearance and high volume of new issues can be misconstrued as underperformance by a management that's used to every report being a quality flaw.

Preventing Misconceptions Caused by PICC

To prevent the misconceptions caused by PICC and ensure that successful improvements are recognized as such, it is essential to create transparency and educate stakeholders of what's actually going on:

Define the Benchmark

Highlight Changes - Frequent evaluations in modern delivery make more issues visible - but also lead to quicker resolutions and thus, better outcomes.

Differentiate Categories - Clarify that the issues reported now are generally smaller and require lower fixing efforts, unlike the severe and late-discovered issues in classic project management that often led to minor issues not even getting addressed at all!

Create Transparency

Provide Objectivity - Agree on severity levels early, and categorize issues accordingly, illustrating, for example, that whereas before, people were simply accepting showstoppers, they are now arguing about button colors.

Analyse trends - Use trend analysis to show how severity classes and quantities shift over time, demonstrating that the measurement is subtly changing.

Manage Expectations

Frame Feedback - Highlight that the feedback is now on a different level than before, and that the purpose of that feedback has also changed.

Correlate Action - Show how feedback is now differently correlated with action, and that the time between highlighting an issue and getting a fix is improving.

Conclusion

Prevalence induced concept change (PICC) can significantly impact how stakeholders perceive the success of teams. Hence, understanding that PICC is happening is a key instrument in managing change and expectations effectively. Be aware of the situation, create objectivity and transparency, then manage expectations to move beyond category errors, misconceptions and perceived deterioration.

How do we make money?

Understanding how to generate revenue is a critical aspect of running a successful business. The way a business owner approaches the question, "How do we make money?" can reveal a lot about their strategy, priorities, and focus. This seemingly simple question is extremely profound: the answers are crucial to business success. But: how do you ask the question?

Intonation matters

Try emphasizing different words in this simple question: you'll see how various facets of running a business gain the spotlight.

In the table below, you can see how different emphasis leads you to explore how different perspectives influence business decisions and strategies. This analysis helps in pinpointing key areas for improvement and ensuring that the business's efforts are aligned with its financial goals.

Emphasis	Focus	Key Questions
How	Means	What are the specific steps, techniques, or strategies we are using to generate income? Are our current methods effective, or do we need to explore new ones?
Do	Confirmation	Are we actually making money? Can we confirm that our business activities are resulting in revenue? Let's verify our earnings and ensure our efforts are paying off.
We	People	What role does each member of our team play in making money? How does our collective effort contribute to our revenue? Is everyone contributing effectively?
Make	Generation	What activities or products are we creating that generate income? Are we being innovative or productive in ways that increase our revenue? How can we optimize our operations to make more money?
Money	Outcome	How well does our business drive profit? Which of our actitivies are aligned with the creation of profit? How do we ensure the business stays efficient in producing a positive bottom line?

You may find different questions and different answers for yourself. Whatever you discover - be aware that the answers are unique. They define your business. You can not copy these answers from others, nor can we give you the "right" answers.

If you find this exercise inspiring, and haven't had enough: try emphasizing two words and see how that changes your answers.

Conclusion

Dissecting the question "How do we make money?" by emphasizing different words provides valuable insights into the nature of your business.

Each emphasis highlights a different aspect of the business - from the methods and processes employed to the roles of the team members and ultimately, bottom line benefits.

By carefully considering these perspectives, business owners can develop a more comprehensive and effective approach to revenue generation, and also learn where currently, there are gaps between expectation and reality. This nuanced understanding enables them to optimize their strategies, enhance teamwork, and prioritize actions that lead to sustainable financial success.

Remember - the path to a successful business is not just about the end result but about the journey to get there.

The Scrum Master as a Trash Collector

In economics, "waste" can be broadly defined as "anything you must pay money for in order to not have." This expansive definition gives us a fresh lens through which to view the role of the Scrum Master: the trash collector.

With this new stance, we offer a unique perspective for Scrum Masters struggling to articulate their value when asked what they bring to the organization. Take a minute and reflect: when was the last time you asked a trash collector what they brought to your house? If you did that, what would they answer? "I'm getting rid of the trash so your place is clean" - that's what you'd expect! And you're happy with their service when there's no smelly pile of trash piling up.

Organizational trash

What is the "trash" that Scrum Masters should be collecting and disposing of? Here are a few examples:

• Meetings: Reducing unnecessary meetings that waste time, drain energy and break concentration.
• Overhead: Cutting down on administrative tasks that don't contribute to the team's goals.
• Processes: Streamlining or eliminating processes that hinder productivity.
• Effort: Removing redundant work to keep the team focused on what truly matters.
• Delays: Identifying and addressing bottlenecks to ensure smooth project flow.
• Stress: Easing team stress to promote a healthy and productive work environment.

This list is incomplete - ponder by yourself which other forms of trash that might pile up in your organization.

Where does this trash come from?

Just as when you buy a new product, you get the value you were looking for plus some packaging. This packaging is necessary to ensure the product's quality upon arrival. However, once you use the product, the package turns into waste. Most organizations fail to dispose of this waste — they keep it around because they don't even realize it's there and it's waste. Eventually, most dealing with the waste becomes a full-time job, and teams can no longer focus on creating value.

The Scrum Master as a Trash Collector

The more effectively a Scrum Master can take out this "trash," the more valuable they become. A good Scrum Master is identified not by what they add, but by what they remove — making the team's path to success clearer and more efficient.

This perspective also helps clarify the often-asked question of whether the Scrum Master role is temporary. Much like trash disposal, the need to remove waste is ongoing. Believing that "We already had the trash picked up last week, we don't need trash disposal anymore" is shortsighted. Initially, you may not see a problem with a bit of dust and litter scattered about - it's just a matter of time until you're knee deep in the trash and can no longer move!

Summary

The stance of the trash collector underscores the Scrum Master’s commitment to fostering an environment where teams can thrive and focus on delivering value, free from the burdens of organizational trash.

The OPEN Transformation Roadmap

When looking at SAFe's "Implementation roadmap," we basically see "Training, training, training, training, do something, training, training, training, bye - have fun!" That looks great if you're a trainer - but it has little to do with how I, as a coach, perceive the journey of organizational change.
In this article, I'm trying to give you a short summary on how I personally perceive a change initiative - with "OPEN Transformation roadmap!"

Organize
Group	Activities	Objective
Change Direction	Formulate Change Objectives Coalition Formation	A guiding coalition that agrees on clear, relevant change objectives.
Change Planning	Change Backlog Change Coordination Organize Calendar	An overview of the predictable activities - what, when and by whom.
Knowledge Foundations	Basics Training Self-Study Q+A Sessions	Everyone has a fundamental understanding of the changing principles, practices - and what it means for them.
Role Alignment	Role Clarification Coaching Touchpoints	Those actively leading and conducting the change understand their roles and responsibilities.
Prepare
Flush the System	Identify hindering Tasks, meetings, roles & responsibilities Identify incompatible Incentives & Measurement Categorize current hinderances Determine flushing actions	Hindrances to change and suitable resolutions are identified, and resolution begins.
Change Overview	Problem-Solution Fitness Assessment Change Recommendations Extend Change Backlog	There's a map connecting Status Quo, change opportunities and the desired future state.
Team Preparation	Team Structure Planning Working Environment Setup Tooling Configuration Calendar Revamp Kick-Off Event	Teams are known and have the necessary means to get started.
Content Readiness	Content Preparation Feature Refinement Establish Backlog	Content and backlog items are prepared, refined, and established to start development in the new ways of working.
Execute
Event Setup	Establish Events Prepare Events with Role Holders Coach-led Events Team-led events with Coaching support	Events are set up, facilitated, and embraced by the people doing the work. Collaboration, transparency, and continuous improvement thrive.
Continuous Support	Daily I&A Sessions	Regular sessions where the change coalition reviews and adjusts their ongoing application and learning on the new ways of working.
Next Steps
Ongoing Support	Active Coaching Disengagement On-Demand Coaching	People receive Coaching support to address situational challenges and needs.
Change Review	Change Benefit Analysis Closing Assessment Further Recommendations Update Change Roadmap	The current state is transparent, recommendations for adjustment and further change are acknowledged and pursued.
Conclusion	Celebration Retrospective Wrap Up	The Adoption itself is concluded, and the organization continues on their Continuous Improvement and Learning Journey.

And yes, the acronym was chosen deliberately: First, it's catchy and memorable. It radiates confidence that we know what we need to do. And most of all: it makes explicit what needs to be emphasized: The "roadmap" itself is OPEN, and it leads ... into the OPEN!

10 signs that your Transformation has failed before it started

"Agile transformation" is a popular buzzword these days, and the promises improved efficiency, better collaboration, and increased customer satisfaction are too hard for any enterprise to ignore. However, the transformation journey is not without its pitfalls. Let's take a tongue-in-cheeck snipe at some of the common causes of transformation failure.

You Know That Your Agile Transformation Has Failed Before It Started, If you...

Brought in consultants to prescribe the details of what everyone must do, when and how.

An Agile transformation doesn't come with a one-size-fits-all approach. When consultants define roles and processes without considering the unique challenges and context, we'll get a "square peg, round hole" solution. Successful transformations rely on collaboratively progressing on the Agile journey, letting teams experiment and adapt based on their own understanding and experience with a continuous interplay of opportunity, ideas, execution and feedback.

Spend more time documenting the Future Mode than experimenting or talking to people.

Agile transformation is about establising a habit of growth and learning based on iteration and continuous improvement. An overreliance on assumption-driven documentation without enough actual interactions and experiments achieves the opposite.

Already know the perfect solution, before having made a single change.

Agility is only required because we have to deal with uncertainty. An agile approach needs to acknowledge that perfect solutions rarely exist. Assuming that a "perfect" solution can be found without experimentation, learning or adaptivity will lead to missed opportunities for improvement and won't make the future organizational system any more flexible.

Can show the future on a slide deck, but not in a team.

Agile transformation is built on "individuals and interactions," not on a top-down declaration by some smart folks who know it all. A vision that exists only on a slide deck without any backing of teams who can tell "war stories from the trenches" doesn't instill much trust.

Have defined the correct process that everyone just needs to follow.

Rigidly following predefined processes is what got us into the mess that agility tries to address by fostering adaptability and flexibility. Imposing a "correct" process without degrees of freedom undermines autonomy and the opportunity to take advantage of domain specific benefits, leading to decreased motivation and ultimately, failure to realize any significant improvement potential.

Declare a mandatory universal "Agile Standard" for all teams.

Each team and organization has its own unique challenges, needs and potential. A one-size-fits-all Agile standard that disregards context stops teams from effectively practicing Continuous Improvement. Successful agile organizations treat the diversity of teams as an advantage.

Consider teams deciding their own ways of working to be a problem.

Empowering teams to self-organize and make decisions that impact their work is the means by which organizations reduce risk of failure and coordination overhead. Treating team autonomy as a liability annuls this advantage.

Apply so much rigor that Team Retrospectives don't let people change, experiment, or learn to do it better.

If the rigor and formality tells team members that their ideas aren't welcome, they'll quickly stop highlighting opportunities for improvement. When teams can't figure out how to improve in their context, "Agile" will merely become a new status quo without any sustainable benefits.

Believe that "people are doing it wrong," without giving them any leeway to do it better.

Agile transformations often involve a shift in thinking and culture, not just the mechanics of Agile practices. Blaming individuals without understanding the systemic barriers causes demotivation and resistance. A successful transformation acknowledges that there is no single "one right" approach, and focuses on enabling teams to find what works best - for them.

Your Coaches can recite the doctrine by heart, but don't understand the psychology of change.

Coaches play a crucial role in guiding teams on their transformation journey. Reciting Agile frameworks, values or principles without understanding the human aspect of change and the psychology of team dynamics alienates people and deprives them of the meaningful support and guidance they require. Successful coaches empathize with teams, create a safe space for learning, and tailor their approach to the needs of the individuals and teams they work with.

Closing remarks

Although this list might be slightly humorous, it highlights some serious pitfalls that can seriously derail transformations. Understanding these reasons for failure will help you become more successful on your Agile Journey. Being agile, fostering collaboration, and living agile values and principles is as essential for the teams doing the work as it is for the change towards Agility itself.

Product vs. Functional Organization - a false dichotomy!

#

There's a buzz going around that "we should move from functional organizations to product-led organizations." However, this binary perspective ignores the complexity of organizational design. The result of such a change is often a suboptimal, unsustainable system with a strong bias towards products, to the detriment of other things But I'm all for dissolving the classic functional organization model. And here's why.

Organizational Archetypes

Let us take a look at different organizational archetypes. You'll quickly realize that it's not as simple as a "product-led vs. function-led" organization - there are a myriad of possibilities. Before we dig into the details, let's briefly explain that an organization can emphasize different aspects, such as products, processes, or people, and each of these aspects can have a focus, a center, and a lead.

The focus is the organization's benchmark for success. The center defines the purpose of individuals and groups within the organization. The lead drives critical decisions.

Since in human systems, people think, do, and act - a focus means that there will be people paying specific attention to this, a center means that people's status in the organization is directly related to how close they are to the center, and a lead would be someone's primary responsibility.

But now, the heart of this article: the table with the different archetypes.

Emphasis	Focused	Centric	Led
Customer	Deliver high-quality products and services that meet the needs of customers.	Organize around delivering the best possible customer experience, and use customer feedback to inform decision-making.	Prioritize the needs and wants of customers above all else, and use customer feedback to drive decisions.
Data	Use data to achieve business goals. It emphasizes the importance of aligning data-driven solutions with business needs and objectives.	Organize around "what the data says," enhancing efforts that drive key indicators and reducing efforts without measurable impact.	Drive business decisions based on data insights, doing more of what's supported by data and less of what's disproven by data.
Function	Deliver high-quality specialized functional services that contribute in the creation of products and services that meet the needs of customers and stakeholders.	Organize around different functions or departments, and coordinate cross-cutting efforts.	Prioritize the needs and goals of individual functions or departments above all else.
Marketing	Create awareness of, and promote, the brand in order to generate demand.	Organize around generating visibility, demand and impact.	Prioritize activites and outcomes that increase demand for the brand.
People	Build a competent, motivated and engaged workforce that meets the needs of customers and stakeholders.	Organize around the needs and goals of employees, while maintaining a focus on meeting customer needs and other considerations.	Prioritize the needs and goals of employees above all else, recognizing that a healthy and engaged workforce is essential for the success of the organization.
Process	Deliver high-quality products and services through efficient and effective processes that meet the needs of customers and stakeholders.	Organize around executing efficient and effective processes, while paying attention to business objectives.	Follow established processes and procedures above all else, sacrificing other considerations in order to do so.
Product	Deliver high-quality products that fit to the company's market.	Organize around products or services, while maintaining a strong customer focus.	Prioritize product outcomes above all else, relying on the product's market impact to drive business.
Sales	Acquire leads, close deals and grow.	Organize around prospective deals and acquiring customers.	Highest priority is given to activites that generate growth.
Technology	Technological solutions and innovation keep the company ahead of the market.	Organize the business around technology capabilities. The development and maintenance of technology infrastructure are key drivers of business success.	Align technology solutions with business objectives and use technology to drive success.

Beyond the dichotomy

A "functional organization" will become highly ineffective when the internal communication and coordination gets in the way of employee and customer needs. Unfortunately, a similar thing might happen in a "product organization" when either-or situations between product progress and people's needs arise.
The table contains no single irrelevant item. In reality, no company is purely one archetype or the other. We thus can't even ask, "From which one archetype towards which other one should we transform?" We need to ask ourselves, "Which drawbacks do we see in our current archetype, and how could we integrate impulses from other archetypes in order to overcome these drawbacks and become more effective as an organization?"

Then, how should we organize?

Companies must strike a balance between the different archetypes, borrowing elements from each to optimize their performance. For example, a company may claim to be strongly customer-focused, but upon closer examination, may be product-focused, supported by data and people. To ensure success, companies should continually inspect and adapt their organizational mix to ensure it aligns with their goals. Leading questions might be, " Are we overemphasizing something that's not suitable for us? Are we underemphasizing something that we maybe should emphasize? If we continue our current approach, which challenges will we face? What do we expect to happen if we make a change?"

Author's note

I am not in a position to tell you how you should organize. My personal belief is that any single archetype, pursued exclusively, will end up being dysfunctional. I would expect most organizations to take impulses from product-focus, customer-lead and people-centricity, while paying due attention to technology and process, with specialized functional areas for cross-cutting platforms and capabilities. But most of all: they would adapt.

The best organizations wouldn't have to decide up front the lead, the center, and the focus - they are able to adapt both locally and globally without major shifts or changes.

Balancing interests at any time, every level of abstraction and in every area is important - because otherwise, people, teams and groups will prioritize their own needs, resulting in local optimization, cannibalization of efforts and unnecessary conflict.
Different people prioritize different things (e.g. time to market and revenue for product folks, quality and sustainability for technical folks, and growth and learning for organizational folks). A system of balance that makes conscious decisions from different perspectives is necessary. This balance of interest is necessary, and the critical question that many organizations stuggle with is determining whether something is going overboard. This won't be covered automatically when there's no transparency what the various perspectives are. Achieving balance is a difficult, ongoing process. Regardless of where we start to balance things out, at some point, we will discover that unless the company's Board of Management provides a balance, the imbalance will continue.

A possible solution

This post wouldn't be complete if I wouldn't be pointing you to a practical way to get this going:
The TOP Structure offers an approach that will help you make different goals visible and transparent, start discussions on whether you believe you're centered, focused and leading on the right things - and then get going to improve the situation.
You can use the TOP Structure as an individual, in your team, in your product group, in your department - or in your company, to balances the different perspectives and find the best thing that works for your context. Read the TOP Guide for practical guidance to get you started. And don't hesitate to contact me if you'd like to learn more.

Organizational design plays a crucial role in determining an organization's success or failure. As an organization grows, it faces numerous challenges that determine effectiveness, productivity, and profitability. Understanding the relationship between organizational design and organization size is crucial for businesses looking how to achieve their goals. In this article, we will explore the key factors that organizations face as they grow, and how their organizational design impacts their ability to overcome these challenges.

The Rule of Three

The Rule of Three is simple, but once you know it, it's hard to unsee:

When your organization's size gets to the boundary of a "Power of 3," then former structures deteriorate.

That means, when you reach:

Potence	Threshold	Structure	Potential observations
0	1	An individual	No collaboration structure needed.
1	2	A pair	Usually very informal. "Do what it takes."
2	9	Team	A team needs to form. The team will communicate their own affairs mostly ad hoc and informally.
3	27	Team of Teams	Up until this point, most likely, everyone knows everyone else: who they are, and what they do. Most communication remains informal.
4	81	Teams with Coordinators	People detach: no longer everyone will frequently interact with everyone else. Teams will separate communication channels for "inside" and "outside." Coordinative roles emerge.
5	243	Coordination Layer	It's technically impossible for everyone to be in contact with everyone: "everyone can work on everything" begins creating communication overload - specialist areas form. A coordination layer will be essential to stop irrelevant, premature or even wrong information from stifling team performance.
6	729	Hub-Spokes Organization	Executive management begins to lose track of everything going on. The coordination layer begins to become too big to act as a single team. Possible solutions could include a combination of: decentralization, delegation/reporting hierarchy and functional departments. Centralization and standardization are utilized to increase functional efficiency.
7	2187	Team of Hubs	Distinct entities with few touchpoints evolve. The coordination layer will require more formalization and will behave like a "team of teams." Business functions deteriorate into silos. At operative level, people no longer know what's happening elsewhere.
8	6561	Team of Entities	Operating as a single entity becomes unfeasible - entities will separate. Entity basis could be location, product or business function. Each of these has its own mangement. Underlying smaller structures are preserved while the overall organization remains strategically aligned.
9	19683	Coordinated Entities	Entities will begin to detach. Keeping the different entities aligned, effective and minimally redundant is a continuous challenge.
10	59049	Independent economic entities	Most likely, there will be some major entities that are independent economically entities (e.g. individual brands, regional OpCos, subsidies) which each have a smaller structure. Arguments around "duplication versus economies at scale by centralization" have no clear winner.
11	177147	Conglomerate	It's very likely that there are a number of entities that act economically independent, i.e. there's a parent entity is operating more like a conglomerate with smaller, underlying entities. Redundancy is a desired systemic capability.
12+	531441	A Nation?	Hey - we're talking about organizations bigger than the countries of Malta or Belize here! Let's leave it at the point that these are special and have their own, unique challenges.

Approximate or exact?

The question begs for an answer. These numbers cannot be treated as a "law," but rather a "rule of thumb." There is no clear-cut point where a hard switch is required, and it stands to reason whether the given numbers are applicable to a specific organization. Instead, they represent a trend: as we approach the threshold without modifying the structure, more problems will surface. For instance, a shift from a pairing to a team structure may work well for 3-6 people, but with 7 people, misunderstandings may increase overproportionally - or a team of 12 may still be feasible, but have more challenges to navigate.

Up and Down!

The "Rule of Three" not only applies as an upper limit of organizational size, but also as a lower limit. A structure designed for 150 people would be inefficient if applied to a team of only 20 individuals. Similarly, investing in role clarity and formal working agreements may not be necessary for a pair as they can collaborate and achieve their goals with fewer formalities.

What the Rule of Three means for you

Adapting to change is crucial for any organization, but how do you ensure your structure is still relevant as your company grows or shrinks? The "Rule of Three" suggests that as you approach certain size thresholds, the challenges and inefficiencies of retaining the current structure increase significantly. However, relying on traditional, heavy reorganizations is not an effective fix. In fact, by the time a reorganization is complete, your target structure may already be obsolete. Instead, building organizational adaptivity as a core capability can help you stay ahead of the curve and ensure your structure is always optimized for your size and needs.

Growing

It's important to recognize the signs that indicate your current structure is no longer effective for the size and be open to adopting new patterns that work for larger organizations. By familiarizing yourself with these patterns, you can anticipate the challenges that come with growth and take proactive steps to adapt your organizational structure to meet the needs of a larger organization.

Shrinking

Reducing the size of an organization can be a positive thing, as it simplifies operations and allows for more streamlined processes. However, it's important to also eliminate any organizational patterns that were designed for a larger size in order to fully take advantage of the benefits of downsizing. Failing to do so can lead to inefficiencies and ultimately result in the downfall of the organization. Therefore, it's crucial to identify appropriate smaller-sized patterns and implement them effectively.

Decoupling

One of the most effective techniques in organizational design is decoupling, which involves breaking down a large organization into smaller ones with limited touchpoints. This approach allows decoupled areas to function with a lower "Rule of Three" complexity, enabling optimization with minimal overarching patterns. Decoupling scales well and reduces coordination overhead. When organizations become proficient at decoupling, they begin to ask, "How can we decouple further and simplify the structure of each area and the entire organization with less overhead?" There is no universal rule for when to decouple, but when it is appropriate, the benefits are significant.

Consequences of Ignoring the Rule of Three in Organizational Design

The "Rule of Three" is a soft but essential principle to consider in organizational design and management. Ignoring it can lead to consequences such as miscommunication, misunderstandings, overhead, poor outcomes, poor return on investment, and poor customer satisfaction. Growth and shrinking patterns in organizations should be organic, and it's better to constantly look for the next possible move rather than tie a change to a specific event or period of time. By applying the "Rule of Three" continuously and effectively, you can ensure that you're always working with the most efficient structure and prepared for any future changes.

Applying Occam's Razor to Organizational Design

Don't multiply entities without necessity

Occam's Razor

Applying Occam's Razor to organizational design means sticking to the simplest approach that works. This means not splitting teams if they can effectively communicate and collaborate as a single unit. It means avoiding adding a coordination layer if lateral alignment can work. And it means not using a team framework for a small group that could work like a pair, among other things. However, it's important to note that the caveat to Occam's Razor is to not increase complexity unnecessarily without a valid reason. For instance, if a small group of six people could function as an economic entity with their own funded subsidy, it may be better to let them operate independently rather than adding 20 extra people to deal with the bureaucracy of the parent company.

However, it's important to remember that when a simpler approach is indicated by the Rule of Three, but you don't know how to do it, adding complexity is usually the wrong solution. For example, if a single team is already not functioning effectively, creating a coordinated team-of-teams will only add further problems to an already unsolved issue: It's better to focus on mastering the basics before considering adding more complexity.

Closing Remarks
Always keep in mind that the "Rule of Three" is primarily meant to broaden your vision of what is happening, why it's happening, and to spark a conversation. The numerical thresholds are merely a signal of what to be mindful of. It's essential to prioritize doing what's straightforward and effective, and determining the simplest approach will vary depending on the situation.

What "Fail Fast, Move On" stands for

There's some confusion as to what "Fail Fast" means - it's caused some disturbance in the force. Let me give you my perspective. 

I'm going to use a business example for illustration. The message won't change if you apply the ideas to a product, a way of working - or even just a task.

The Fail Fast Move On Philosophy

Of course, we would like to maximize our probability of success. But - sometimes, we just can't know.

Let us use a restaurant as a showcase: I haven't seen any restaurant owner ever who opened a deli in order to go broke. And yet, almost 90% of restaurants don't survive their first year. Worse yet: the average restaurant owner loses at least $50k on the ordeal. Which, by the way, is the reason why I haven't opened a restaurant. For me, the upfront investment plus bound capacity (it's a pretty taxing job) isn't in sound relationship to possible benefits. But I digress ... but only slightly.

Fail Fast

During the "Fail Fast" stage, we start by figuring out what we're trying to do, what we know and what the unknowns and risks are. We exhibit a healthy skepticism of facts, for example, "Do we really know people in this part of town like Sushi?" and ask critical questions, such as, "What will happen if they don't?" We can then classify how much we're risking in case our assumptions turn sour. That gives us an analyzed, itemized list of risks which could make our endeavour fail.

Experiment

With our risk list, we propose a counter to our business idea, and we try to prove that the counter is false:

Returning to our sushi example, "We will offer a piece of Sushi to 100 pedestrians and ask them whether they'd visit a Sushi bar offering the same level of quality. [Counter:] Fewer than 10 positive answers mean that there's not enough interest in Sushi here."

Next, we're not even going to try to open a Sushi bar: all we want to do is disprove the pessimistic notion of an empty Sushi, our key risk of failure.  (We could still be wrong - but now we know that there's a possibility of being right.)

We're not trying to succeed, we're trying to rule out predictable failure.

If our counter-experiment succeeds, we just saved all followup effort: Why should we rent a facility, purchase decoration and cutlery, hire a cook and waiters - if we already know that we won't have enough customers? When we learned that we can't deal with known challenges, we need to change our goal and backtrack.

If we succeeded at failing the counter-experiment (yes, that's a double negative!) - we can proceed further.

Move On

In our restaurant example, we know that 90% of restaunts fail, and we'd like to be in the 10% that don't (like everyone opening one of the failing 90% of restaurants.) But: when we can't, we definitely don't want to be lose some $50k+ on the attempt. Hence, we move step by step, keeping the cost of each step low, and accept that everything we invested up to this step is money lost. We're not trying to recoup it - especially not by investing more in order to get some of it back.

"Moving on" means that everything we invested up to this point is "sunk cost" - investments we will never recover. Sunk cost hurts, and it makes us uncomfortable. Yet, there's something worse than sunk cost: "Throwing the good money after the bad."

In order to practice "Move On," we avoid hedging our bets by binding unnecessary assets, so that we have less pain when discarding them.

Moving on

Moving on requires us to let go of what we invested.

The 3 Steps of Fail Fast, Move On

Applying Fail Fast, Move On goes far beyond validating a business idea - it goes for any idea, and thus is all-encompassing for all creative work. Fail Fast, Move On could be considered a 3-step process:

1. Pull risk forward
2. Rigorously inspect and adapt
3. Minimize and write off sunk cost

That, of course, doesn't mean that we either:

• Generate unnecessary risk by negligence or unprofessionalism.
• Act without a prediction to validate.
• Waste our energy on doing things we know we could do smarter. 

To the contrary - "Fail Fast, Move On" is the notion of avoiding these three antipatterns by systematically eliminating failure points.

Proper "Fail Fast, Move On" saves you energy and maximizes your opportunity of success.

You can learn more about succeeding with "Fail Fast, Move On" in my Lean Startup lasses.

Feel free to set up an appointment with me using the PAYL coaching mechanism (on the left) to discover more.

There's always a bigger context!

Have you wondered why so many people, organizations - and even humanity as a whole, constantly find themselves in a mess that's hard to scramble out of?

The reason is quite simple: because we are quite short-term oriented, and we either don't see - or discount - the bigger context we're acting in!

Virtuous Cycles

When we want something that we don't have (or: not enough from), we change something in a way that we predict that we'll get what we're looking for. We then see if that did work, and we'll continue doing more of that until we have enough. And we do the opposite when we don't want something that we do have. 

Feedback loops help us to pause, stop or course correct while we're at it.

A trivial example of a virtuous cycle might be lunch: When we're hungry, we want food. We get our portion, like it, and eat some more. (If we don't like the food, we might get something else instead.) We continue eating until either our portion is gone, or our stomach signals "Full."

Vicious Cycles

A vicious cycle isn't the direct opposite of a virtuous cycle - it's when we do something, and get something we don't want. For example, if we'd really like that wild honey, and put our hand into the beehive: the longer we leave our hand in there, the more we'll get stung.

Short term and long term

In the short term, we complete one action and observe the immediate results. For example, we grab a candy bar, and it satisfies our craving. We can repeat this cycle again and again, and we get predictable and repeatable results (well, until our stomach tells us we had too much candy.)

In the long term, however, we get other results than in the short term: while one candy satisfies our craving, one hundred days of repeated snacking will lead to some weight gain, and two years' worth of snacking will result in a wobbly tummy.

Thus, the virtuous cylce of "craving satisfied" is embedded in a vicious cycle of "gain weight."

Inseparability of cycles

In our simple example, it's impossible to separate the short-term virtuous cycle from the long-term vicious cycle: as the proverb goes, "you can't have your cake and eat it, too." The action that starts the virtuous cycle will also set the vicious cycle in motion. 

The desirable short-term outcomes of the virtuous cycle are immediately visible, so we're tempted to set it in motion. On the flip side, the long-term outcomes of the vicious cycle are invisible at the moment, so we're tempted to discount them in favor of the proven and tangible short-term benefits.

Shocking consequences

We find ourselves continuously repeating the virtuous cycle, with the firm belief that what we're doing is beneficial, until - one day, in our example, we get a Diabetes diagnosis: It's impossible to attribute the diabetes to any single piece of candy we consumed. Even worse: simply stopping the virtuous cycle of meeting our craving isn't going to change the situation we're in, and the process of reverting the vicious cycle will be difficult to impossible. There's no easy "undo" action related to anything we did in the past.

We were caught by the embedded larger context of our visible virtuous cycle: the invisible vicious cycle.

What does our little example imply for a software organization, then?

What you see isn't what you get!

Take a look at this diagram which illustrates the larger systemic context we may find ourselves in:

We always get positive feedback from our immediate action, so we learn that our action is good.

For example, let's say the developer who's always fastest (by skipping tests) learns that they get praise by customers and management, whereas the developers who are always slowest (by building quality in) learn that they'd get more appreciation by cutting short on quality.

The short-term virtuous cycle is that developers learn how to deliver faster and meet tight deadlines.

Unfortunately, by the time we realize the effects of the vicious cycle, our product is probably almost dead: it might take months, possibly years, to trace out and fix all the bugs in the code, and that's not even calculating the effort (and frustration) of adding tests to an unmaintainable codebase.

And worse than that, we only have developers left who have - over the years - learned that building quality in is bad for their careers.

By the time we've come to realize that the vicious circle has taken over, there's no quick fix any more, and the cost of change, at this point in time, is overwhelming.

Scrambling out of the mess

When we realize that we got something that we don't want, we have a myriad of problems to address:

1. We must discover a way to re-wire the outer vicious cycle by disrupting it, and replacing it with a vicious cycle.
   
   
2. We must become conscious that the presumed virtuous cycle did spin off a vicious cycle, and must stop triggering more of the vicious cycle.
   
   
3. We must un-learn and stop the old virtuous cycle, despite the visible short-term benefits.
   This step is very hard, because we must actively reject the benefits we attributed to it.
   
   
4. We must actively pursue the new virtuous cycle, despite it being slow, and the benefits being less visible than the benefits of the old virtuous cycle. This requires strong discipline, because it's easy to lapse into old habits, potentially eliminating months of progress with a single act of carelessness.
   
   

Unfortuntately, since we saw short-term benefits in the past, we tend to look for a new way that undoes all of the damage caused by the vicious cycle in the blink of an eye: instead of actively doing the hard work of behavioural and belief change, we often hunt for a miracle pill. And thus start another vicious cycle.

Let me put it like it is:

If a physical building has collapsed because it was built using poor materials, you can't just swallow a pill to rebuild the entire thing. The only way forward is to clean up the rubble, get better materials, and construct a more stable building.

And that's how you get sustainable change:

1. Become clear what got you into the bigger mess.
2. Stop doing that, even if it gave you results you were looking for.
3. Clean up the shambles.
4. Create something new that avoids the vicious cycle.

Dealing with limiting beliefs

We often encounter that Limiting Beliefs are holding us back from achieving the goals we want to achieve, from doing what is right, from becoming who we want to be. So - if we know this, why aren't we changing our beliefs? Because, very often, our beliefs define who we are, and change is hard. But there is hope. What could we do?

Limiting Beliefs

Let's start by defining limiting beliefs - a belief confining us, or reducing our options in some way. We all hold limiting beliefs, and there are some of them that we shouldn't even change. So - when exactly are limiting beliefs an issue? A simple and quick answer: when we should be doing something that's hard or impossible because of a specific belief we subscribe to.

Let's use an example to illustrate our case:

Say, Tom is a manager and he believes that: "Developers can't test their own software." This belief is limiting, because it stops all beliefs, decisions and actions built on the idea that "developers do test their own software." 

The problem with limiting beliefs

As long as Tom holds this belief, he can't support the ideas of, for example, TDD or Continuous Delivery, because these are in conflict with his belief. And beliefs aren't like clothes - we can't change them at whim. Here's what we're dealing with:

Belief networks

Limiting beliefs don't simply stop one change, they are often part of a complex web of other beliefs that reinforce the limiting belief, and which would be incomplete, incoherent or even inconsistent if that limiting belief was changed - so we can't just replace one belief without examining its context: "Why do you hold this belief?" 

Supporting beliefs

In Tom's example, we might find other supporting beliefs - such as the Theory X idea, "Without being controlled, developers will try to sneak poor quality into Production, and then we have to deal with the mess."

Anchoring

Tom is probably a reasonable person, and his belief was most likely anchored by a past experience - there were major incidents when developers did cut corners, and these incidents forced Tom to adopt a policy of separating out development and test, and that ebbed the tides.

Negative hypothetical

Let's ask Tom, "What would happen without a separation of development and test?" - and he'd most likely refer back to his anchor experience, "We would have major incidents and wouldn't get any more work done because of continuous firefighting." - and it's hard to argue his case, because it's consistent with his experience.

Conjunction Fallacy

Let's ask Tom an inconspicious question to figure out what Tom thinks is more likely: "Which scenario do you think is more probable: that a developer creates a mess, or that a developer who tests their own code creates a mess?" - Tom will probably answer that it's the latter. This, however, is fallacious, because developers testing their own code are a subset of developers, a special case: if that was Tom's answer, he would (probably unknowingly) subscribe to the idea that developer tests increases the probability of poor results!

Confirmation Bias

Now, let's assume that we manage to convince Tom to make an experiment and let developers take control of quality - we're all human, and we all make mistakes. Tom will feel that the first mistake developers make confirms his belief, "See - we can't. I told you so." 

Selection Bias

Of course, not everything an autonomous developer will deliver is going to be 100% completely broken, but Tom will discount or dismiss this, because "what matters is the mess they created and that we didn't prevent that from happening." - Tom will most likely ignore all the defects and incidents that he currently has to deal with despite having a separate Test Department because these aren't affirming his current belief.

Changing limiting beliefs

Given all these issues, we might assume that changing beliefs is impossible.

And indeed, it's impossible to change another person's beliefs. As a coach, we can't and shouldn't even try to do this: it's intrusive, manipulative and most likely not even successful. Instead, what we can do is: support the individual holding a limiting belief in going beyond the limits of their current beliefs.

Here's a process pattern we could use to help Tom get beyond his limiting belief:

1 - Write down the limiting belief

When you spot a critical limiting belief in coaching, write it down. Agree with the coachee that this is indeed the limiting belief they're holding.

2 - Ascertain truth

Truth is a highly subjective thing, it depends on beliefs, experiences and perception. What we want here is not "The truth," but what the coachee themselves asserts to be true: "Do you believe this is certrainly true?" - "What makes you so sure it's true?" - "Could there be cases where this isn't true?"

This isn't about starting an argument, it's about getting the person to reflect on why they're subscribing to this limiting belief.

3 - Clarify the emotional impact

Let's ask Tom, "What does holding this belief do to you?" - and he may answer: "I know what I need to do, that gives me confidence." - but likewise: "I am upset that we can't trust developers on their quality."

We hold onto beliefs both because and despite how they affect us. There's always good and bad, and we often overlook the downsides. Most likely, Tom has never considered that he's carrying around some emotional baggage due to his belief. Until Tom comes to realize that this belief is actually limiting him, and also negatively affecting him, he has no motivation to change it.

4 - Clarify consequences

 Next, we'd like to know from Tom where the limiting belief will put him in the long term: "When we look back, 10 years from now - where will you be if you keep this belief?"

We would like Tom to explore the paths he can't go down because of his limiting belief - for example, "We still won't have a fully automated Continuous Deployment - and I will be held responsible for this." Tom needs to see that his current belief is going to cause him significant discomfort in the future.

5 - Surface the Cost of Not Changing

We're creatures of habit, and not changing is the default. We first and foremost see the cost of change, because that's immediate and discomforting. And we ignore the cost of not changing, so our default would be that we have no reason to change anything.

Tom must see the costs of persevering in his current beliefs, so we ask: "What's the cost - to you - in 10 years, if you don't change this belief?" - a mindful Tom might realize that he'll get passed up for career opportunities, or might even get replaced by someone who will bring new impulses. The more vivid Tom can paint the upcoming pain, the more determined he will be in wanting to change.

And that's the key: As long as Tom himself has no reason to change his belief, he won't. But we can't tell him what his reasons should be. Tom has to see them by himself, and in a way that is consistent with his other beliefs.

6 - Paint a brighter future

Tom may now be depressed, because in his current belief system, he's doomed: there's no hope. So let's change Tom's reality. Let's ask him, "If you change this belief, what would you be and do?" - Tom might be skeptical, but will tell us some ideas on his mind, "I'd give devs permission to test their own code." - "I wouldn't enforce strict controls on developers." - "I wouldn't be known as the only person in this company insisting on stage-gating." 

We can then follow this up with, "How would you feel if this could be you?" - if we get positive responses like, "Less stressed, more appreciated" - we're moving in the right direction. If we get negative responses like, "Stupid, Unprofessional" - then there's another, deeper rooted limiting belief and we have to backtrack.

7 - Redefine the belief by its opposite

Let's ask Tom, "What's the opposite of this belief?" - and Tom would answer, "Developers can test their own code." Tom needs to write this down on a card, and keep it with him all the time.

8 - Reinforce the new belief

Every day, Tom should read this card and look for evidence that this opposite belief is true. For example, Tom can find out which people hold this opposite belief, and how it works for them. 

At a minimum, Tom should just take a minute and sit back in calm, take out the card and read it to himself - and then repeat this new belief to another person.

As coach, we can challenge Tom to repeat the new belief back to us frequently, and to provide small stories and anecdotes about what he has said and done based on this different belief.

9 - Reflection

After one month, reflect with Tom what difference thinking and acting based on this opposite belief has made, and how often he lapsed back into thinking and acting based on his limiting belief. Under ideal circumstances, Tom will have success stories based on his new belief - these are a great basis for reflecting whether this new belief can serve him better than his former, limiting belief.

Even if Tom sees no difference, he already has evidence that his original belief may not be true.

If Tom is still struggling, he may need more time to be convinced. 

Closing remarks

Even with a formal process for belief change, we're not guaranteed to rewire or reeducate others. We respect and enjoy freedom of thought and differences in belief, and the best we can do is highlight consequences, reinforce and provide feedback.

If we see that people choose to cling to old beliefs and habits despite all our attempts at supporting them, we have to ask at a meta level what the difficulties are, and whether our support is even desired. We're not in the business of messing with other people's heads - we're in the business of supporting them in being more successful at achieving what they want, and in coming to realize what that actually is.

Microhabits - small action, big impact

 Let's talk about #microhabits - the small things that don't seem to make a difference at all in the short term, which are setting you on a long-term trajectory.

What are microhabits?

Microhabits are actions that take nearly no time and seem to have a very limited scope, and seem to not be worth mentioning, yet they set you on a compounding trajectory. Many years after adopting a microhabit, people adopting it are worlds apart from others around them.

Here are some examples of software development microhabits:

• Appropriately naming stuff
• Fixing typos
• Refactoring
• Making sure the code is easily testable
• Adding important unit tests
• Generally keeping code readable and workable
• Creating a working build at leasts a few times a day

No excuses

I often hear, "This was an emergency," or "This was just a demo," or "There was time pressure." These are supposedly justifications for not doing the things above. In the working world, there will always be some stress, deadline or emergency lurking behind the next corner. Everything else is cockaigne.

Here's the thing, though: Microhabits become "second nature" and it's more effort to break a habit than to pursue it, so we can't argue that pressure is a reason to do something slower, more complex and less routine than what we'd normally do.

People with good coding microhabits will pursue their habit and keep their code high quality regardless of circumstance. Simply because it's a habit. An important realization about habits: they'll never form if you constantly interrupt them - so consistency is key.

Form the right microhabits habits today!

Which actions, when done consistently over many years, will result in a codebase you'd love to work with? Adopt these, and keep doing them consistently.

And which would result in a codebase you'd loathe? Stop these, and avoid them consistently!

If you want to do a facilitated Retrospective on the topic, you can use this simple template:

U-Curve Optimization doesn't apply to deployments!

Maybe you have seen this model as a suggestion how we should determine optimum batch size for deployments in software development? It's being propagated, among other places, on the official SAFe website - unfortunately, it sets people off on the wrong foot and suggests them to do the wrong thing. Hence, I'd like to correct this model -

In essence, it states is that "if you have high transaction costs for your deployments, you shouldn't deploy too often - wait for the point where the cost of delay is higher than the cost of a deployment." That makes sense, doesn't it?

The cause of Big Batches

Well - what's wrong with the model is the curve. Let's take a look at what it really looks like:

The difference

It's true that holding costs increase over time, but so do transaction costs. And they increase non-linearly. Anyone who has ever worked in IT will confirm that making a huge, massive change isn't faster, easier or cheaper than making a small change. 

The amount of effort in making a deployment is usually unrelated to the amount of new features part of the deployment - the effort is determined by the amount of quality control, governance and operational activity required to put a package into production. Again, experience tells us that bigger batches don't cause less effort for QC, documentation or operations. If anything, this effort is required less often, but bigger batches typically require more tests, more documentation and more operational activity each time - and the probability of Incidents rises astronomically, which we can't exclude from the cost of change if we're halfway honest.

Metaphorically, the U-Curve graph could be interpreted as, "If exercise is tiresome, exercise less often - then you won't get tired so often. The optimum amount of exercise is going to door to receive the pizza order, but rather order half a dozen pizzas at once if the trip to the door is too exhausting, and then just eat cold pizza for a few days." 

Turning back from metaphors to the world of software deployment: It's true that for some organizations, the cost of transaction exceeds the cost of holding. This means that the value produced but unavailable to users is lower than the cost of making that value available. And that means that the company is losing money while IT sits on undeployed, "finished" software. The solution, of course, can't be to wait even longer with not deploying, and losing even more money - even if that's what many IT departments do.

As shown in the model, the optimum batch size isn't achieved when the company is stuck between a rock and a hard place - finding the point where the amount of money lost by not deploying is so big that it's worth to spend a ton of money on making a deployment.

The mess

Let's look at some real world numbers from clients I have worked with. 

As I hinted, some companies have complex, cumbersome deployment processes that require dozens of people weeks of work, easily costing $50000+ for a single new version. It's obvious that due to the sheer amount of time and money involved, this process happens as rarely as possible. Usually, these companies celebrate it as a success when they're able to go from quarterly releases to semiannual releases. But what happens to the value of the software in the meantime? 

Just assuming that the software produced is worth the cost of production (because if it wasn't, why build it to begin with) - if the monthly cost of development is $100k, then a quarterly frequency means that the holding cost is already at $300k, and it goes up to over half a million for semiannual releases. 

Given that calculation, we should assume that the optimal deployment frequency is when the holding cost reaches $50k, which would be two deployments per month. That doesn't make sense, however: when 2 deployments costs $50k each per month, then 100% of the budget would flow into deployment - of nothing. 

Thus, the downward spiral begins: fewer deployments, more value lost, declining business case, pressure to deliver more, more defects, higher cost of failure, more governance, higher cost of deployments, fewer deployments ... race to the bottom!

The solution

So, how do we break free from this death spiral?

Simple: when you're playing a losing game, change the rules.

The mental model that deployments are costly and we should optimize our batch size to only deploy when the cost of deployment outweighs the holding cost is flawed. We are in that situation because we have the wrong processes to begin with. We can't keep these processes. We need to find processes that significantly reduce our deployment costs:

The cost of Continuous Deployment

Again, using real world data from a different client of mine: 

This development organization had a KPI on deployment costs, and they were constantly working on making deployments more reliable, easier and faster. 

Can you guess what their figures were? Given that I have anchored you at $50k before, you might think that they have optimized the process maybe to $5000 or $3000.
No! If you think so, you're off by so many orders of magnitudes that it's already funny. 

I attended one of their feedback events, where they reported that they had brought down the average deployment cost from $0.09 to $0.073. Yes - less than a nickel!

This company made over 1000 deployments per day, so they were spending $73 a day, or $1460 a month, on deployments. If we calculated the accumulated cost of deployments for the whole period, they were still spending over $5000 for three months' worth of software development. But the transaction cost for each single deployment is ridiculously low.

Tell me of anything in software where the holding cost is lower than 7 Cents - and then tell me why we are building that thing? Literally: 7 Cents is mere seconds of developer time!

With a Continuous Deployment process like this, anything that's worth enough for a developer to reach for their keyboard is worth deploying without delay!

And that's the key message why the U-Curve optimization model is flawed:

Anything worth developing is worth deploying immediately.

When the cost of a single deployment is so high that anything developed isn't worth deploying immediately, you need to improve your CI/CD processes, not figure out how big you should make that batch.

If your processes, architecture, infrastructure or practices don't permit for Continuous Deployment, the correct solution is to figure out which changes you need to make so that you can continuously deploy.