Prioritization isn't what it used to be.

"Prioritization" once meant finding the one, single most important thing. In the Latin root, prior was a singular absolute. There could be only one. But the world accelerated. Hence, the concept fragmented: we started juggling "priorities."

In this post, we'll explore how the historic concept of prioritization breaks down in complex, high-velocity systems, and what a modern, systemic view of "prioritization" looks like.

Where "Prioritization" Came From

For centuries, the term "priority" made perfect sense: Every monastery had one Prior - the one who led the monastery, coordinated its logistics, and gave meaning to the work of the monks. Rulers dealt with events in succession, because information changed slowly: During a public audience, there might have been interrupts, but other than that, everything was coordinated and arranged in a clear sequence. The "Kölner Dom" was built over centuries, and the decision how much labor and funding to allocate to the construction was made many times, across many generations. The world itself moved at a human pace.

The industrial age changed that, and the Internet completely broke us. Communication became instant; execution, however, did not accelerate at the same pace. Suddenly, multiple "first things" competed for limited time and attention.

The POTUS Dilemma

Imagine for a minute, you're the President of the United States. You look at your phone. There are 3 messages:

• China has declared war.
• A rioting mob is storming the Capitol.
• Someone threatens to kidnap your daughter.

You can't ignore any of these issues, but you can only make one call at a time. Which number do you dial first?

That is prioritization!

The Collapse of Time

In 1875, if China had declared war, the message would take weeks to arrive. Today, it would hit every device on Earth within seconds — but the machinery of response still moves at human speed.

The result: information travels faster than action. Decisions are always chasing relevance. “Prioritization” becomes less about choosing and more about adapting.

The Decision Loop

When people at operational level claim "prioritization failure," they usually mean, "management failed to decide what not to do." But that's just passing the buck. It fails to acknowledge that there's a much deeper, systemic design issue: it's not that easy.

Every organization today runs through the same cyclical funnel:

• Information: What do we notice?
• Decision: Which trade-offs do we accept?
• Action: Who acts, when, and with what resources?
• Result: Which outcomes count as meaningful?

Prioritization doesn’t happen once inside this loop. it happens continuously, at every stage.
And whereas in the past, it was quite easy to run this cycle maybe once a quarter at board level, today, even a day hardly cuts it.

Where Prioritization Really Lives

We must get beyond the concept that "Prioritization" is the management activity of deciding which work gets done and what doesn't get done. While not totally wrong, it misses the mark. Practically, "Prioritiztation" is not a management-only act. All the cognitive filters we apply to our environment are acts of prioritization - do we pay attention first to our own area, or to the system? Do we pay attention to the short term, how much attention do we pay to the long term?

When organizations struggle with "prioritization," it's rarely because "management doesn't decide properly." It’s because the system is designed in a way where prioritization flow naturally across the loop in an effective manner.

The task of leadership, then, is not to pick individual projects, tasks or activities from a pre-defined list of options - but to design how prioritization happens.

Conclusion

"Prioritization" is a concept from times gone by, where the speed of information was measured in days, and the world's information could be measured in books. Today, we're dealing with information arriving within seconds, and every day, the Internet is flooded with more new information than the world's biggest library could contain. The context is no longer one where we can easily sequence our activities, without loss of outcome quality.

The core issue is an inability to sense, interpret, and adapt quickly enough to retain focused on what truly matters.

As information accelerates, and as AI begins to process it at near-light speed, the meaning of "prioritization" will shift from choosing actions to defining value systems which enable full-automating not only the decision of which information is important, but also determining the impact: What needs to change, and who needs to be informed.

The real question we need to answer in prioritization is not about work packages. It's about the information we need to send, and to process.

The challenge is not coming up with an ordered task list. It's how we keep it relevant in real time.

Organisational GRIT

Many people wonder, "What's the difference between a successful organisation, and one that struggles?"
Throughout my decades of consulting and observation, I have observed four factors that I call "GRIT."
Take heed of these, and you're most likely in good shape. On the other hand, ignore these at your own risk.

The GRIT Factors

When analysing what's going on in a company, there are four factors at play that create GRIT - in healthy organisations, these are naturally tended to and require little effort.

However, unhealthy systems of work neglect one or more of these, with dire consequences:

Goals

The first factor of a healthy system of work is that people have clear goals: things we want to achieve in the future. That can be the personal goals, team goals, business goals.

Best case, everyone has all of these - and all of them align.

Worst case, people have no goals, in which case they will show up just to get paid.

The worst case scenario lends itself to all kind of doomsday scenarios for a business owner: nothing getting done, people wasting their time with unfruitful conflict, or people leaving to make more from their life.

Relationships

The second factor of a healthy system of work is that people have positive relationships with the people around them. That includes their team, other departments, business partners and customers.

Best case, everyone has sustainable, sufficiently close relationships that make their network resilient.

Worst case, people's relationships are toxic or adversarial.

I don't think it requires further explanation what happens when the customer is treated like an enemy - but many organisations seem to be entirely oblivious to the cost in time, effort - and ultimately money - that is wasted with infighting.

Improvement

The third factor of a healthy system of work is that people continuously pursue improvement at all levels: make work faster, easier, better. Reduce risk, friction, cost. Make customers happier. Go home with less stress and more happiness.

Best case, the system of work makes that a natural part of the work, and everyone actively contributes.

Worst case, processes and tools deteriorate and everyone is looking the other way.

It's easy to figure out what happens when improvement is not part of people's thoughts or actions, but that's the reality in many organisations: The tyranny of the Urgent makes improvement fall over the edge until the cost of fixing things has reached frightening levels, and people are scared to even get started.

Tomorrow

The fourth factor of a healthy system of work sounds very abstract - "tomorrow" - so let me make it a bit more tangible: Tomorrow, a competitor may arrive on the market. Your business model may get disrupted. A key player in your team may move on. Are you prepared?

Best case, the company is constantly and persistently putting efforts into being prepared for the uncertainties and inevitabilities of tomorrow, and people are not scared to look into the future.

Worst case, everyone knows that the business is heading downhill, but people close their eyes to this uncomfortable reality. And with every day, the looming specter of Tomorrow becomes more threatening.

It doesn't take a lot of imagination where a company is headed when they have no plans for Tomorrow. And yet, few can articulate a clear plan.

Building GRIT

Building a company with GRIT is easy if that's how you've always done it. But if you've never done it, it's staggeringly hard. In fact, it seems insurmountable. So I'll give you a few pointers for getting started on the journey of building GRIT.

1. Itemize the most important Challenges, Opportunities and ongoing Activities in each sector.
2. If a sector has few or no items in it, it's a blind spot. Take some time to think!
3. Ask yourself, "How can we improve our situation?"
4. Take action on the first item and see where it leads you.

Now, that wasn't hard, isn't it?

From now, you may frequently revisit your GRIT matrix, see what pops up and whether you're making progress.

By taking GRIT building serious, you will see a significant reduction in risk, stress and fear - and significant boosts in sustainability, employee satisfaction and business outcomes.

Give it a try!

Flush the System for Agility!

A key activity that needs to stand at the beginning of every Agile Journey: "Flush the System." What that does? Well - it lays the groundwork so that working in an agile way is even possible.

Areas of investigation

The following areas can be considered "the usual suspects" where flushing activities may be necessary. Please be aware that terminating something is often the easy part - the challenging, and time-consuming part, is obtaining stakeholder support (and potentially: permission) to do so.

Work

Often, at the beginning of an agile journey, people are highly overburdened and it's not even clear who is working on what for how long. That makes it difficult to get anything done - so we need to clean up!

	Itemize ongoing work and complete or cancel tasks accordingly.
	Hand over tasks and responsibilities outside the scope of the Agile team.
	Terminate processes that aren't aligned with Agile ways of working.

Calendar

In many organizations, meetings are so rampant that there's no time left to do any work. And the more knowledge a person has, the more likely they're in this dilemma. Without sufficient focus time for getting any meaningful, valuable work - there's not going to be much "Agile" delivery.

	Cancel unnecessary meetings, such as status or reporting meetings, Jour Fixes, and others.
	Cancel meetings with intended outcomes that should be achieved during Agile events (e.g., Planning, Refinement, Review).
	Cancel meetings with unclear or irrelevant outcomes.

Roles and Responsibilities

Roles and responsibilities need to be clarified and aligned with Agile principles and be made consistent with the new way of working. Unnecessary or counterproductive responsibilities lead to confusion, overhead and conflict.

	Hand over responsibilities that aren't in the scope of the newly coming Agile team.
	Remove unnecessary or counterproductive responsibilities.
	Eliminate "telephone games" in roles and responsibilities that impede information and decision flow.

Incentives and Measurement

Incentives and KPI's often surface as an impediment for collaboration and a focus on value. Historically, these are often founded on beliefs that don't coincide well with Agile Values and Principles, hence cleaning these out will become critical to shaping a better system of work.

	Eliminate KPI's and management metrics distracting from value creation.
	Cancel irrelevant or counterproductive goals.
	Minimize the impact of (or preferably eliminate) incentive schemes and bonuses.

Take action!

As you embark on your Agile journey, "Flushing the System" creates a supportive environment that helps Agile teams to thrive. The above checklist is a powerful guide to streamline work, optimize their calendars, clarify roles, and align outcomes.
This list isn't exhaustive - merely a starting point, and you may find a lot more items you can flush as you look around in your organization.
Remember: "Flushing the System" isn't a one-time event, but part of the greater process of continuous improvement. Regularly assess and refine your system of work to ensure you're not missing "flushing" potential that will lead to better flow.

Navigating Hidden Agendas

We are constantly striving to create thriving organizations where collaboration, productivity, and innovation flourish. However, one of the most challenging aspects in organizations is the presence of personal agendas - both overt and hidden. Oftentimes, people say that if we could just eliminate those personal agendas and focus everyone on the overall goal and mission, we would have a lot fewer problems. But that "just" is a major problem - let's explore.

How are the pieces and the Big Picture connected?

The problem with hidden agendas

Hidden agendas arise when an individuals' have personal interests, motivations, or goals don't align with their environment. Such hidden agendas are often considered to be impediments to decision-making, execution and teamwork. They also erode trust within the organization. 

Acknowleding and understanding the existence of hidden agendas is crucial for effective leadership and organizational success.

The Impact of Personal Agendas

Personal agendas significantly influence the dynamics, communication, decision-making processes. When individuals prioritize their own motives over organizational goals, this can spark conflicts, damage collaboration, and hinder progress. Hidden agendas pose a particular challenge here as they aren't openly acknowledged and addressed, so everyone besides the agenda's owner is kept guessing. This can undermine trust, transparency, and alignment within the organization.

The presence of personal agendas can indeed have a substantial impact on organizational success by affecting alignment, transparency and collaboration. Acknowledging and managing personal agendas thus becomes essential for fostering a positive and productive work environment.

Why are there Personal Agendas?

As soon as you have more than just a handful of people, the diversity of individuals' motivations, aspirations, and goals becomes more apparent. We see the difficulties this brings even in marriages where only two people need to align their needs and desires with each other. And with growing organizational size, the problem of alignment grows.

While some agendas may be openly expressed, others are hidden or not immediately apparent. In some cases, this happens on purpose. In many cases, though, it happens because people themselves are either unaware of the impact of their goals on overall goals, don't know how to communicate their own goals, or there's no forum where they could address the discrepancies. 

Complex organizational structure with multiple stakeholders and diverse roles are thus a fertile ground for the emergence of personal agendas. 

Can't we eliminate Personal Agendas?

In short: No. Eliminating personal agendas from individuals within an organization is practically impossible. Humans naturally have their own motivations, interests, and aspirations, based on their needs, expectations, assumptions and reasons. If we were to successfully remove all of these, it would turn people into soulless drones without. Autonomy, creativity and engagement would be massively constrained.

Minimizing the negative impact of personal agendas requires effort into aligning people's objectives with one another and the overall organization. We can achieve this by fostering open communication and respecting the individuals' motivations.

The consequences of suppressing Personal Agendas

When individuals are unable to express their personal agendas openly, they will develop hidden agendas instead. Lack of a forum for discussion and transparency creates an environment of mistrust, where individuals resort to covertly pursuing their own interests. It could take a long time until the impact of the resulting actions on communication and collaboration becomes tangible. The gap between overall desired actions and executed actions in this case is "communication debt."

Communication Debt: The conversations we should have had, but failed to have.

Similar to other forms of debt, this communication debt comes with an interest attached, and will grow exponentially over time when unattended.

Permitting Personal Agendas

Should we then make a space for personal agendas? Yes.

While we might believe that systems permitting personal agendas would perform worse in the long term, that doesn't match the evidence. Even people like Steve Jobs famously said, "We don't hire smart people and tell them what to do - we hire them so they can tell us what to do." Books like Dan Pink's "Drive" have collected overwhelming evidence that systems giving people the autonomy to decide the best course of action by themselves create superior outcomes.

Creating a space for personal agendas within a structured framework harnesses every individual's talents and creativity. Systems recognizing and accommodating personal agendas fare better on engagement, ownership, and innovation. The challenge is striking a proper balance between personal agendas and their potential to override collective objectives or causing conflicts.

When managed effectively, such systems can leverage the diversity of individual perspectives to drive organizational success.

The Growth of Hidden Agendas

Without a platform to openly express their personal agendas, hidden agendas tend to proliferate. The absence of open communication channels will foster resentment, lack of trust, and covert pursuit of individual interests. Over time, the resulting hidden agendas may undermine communication, collaboration and organizational cohesion.

Whereas providing a forum for sharing personal agendas is no guarantee for the absence of hidden agenda, without such a forum, hidden agendas are likely to grow. Opportunities for open dialogue and transparent communication are essential in mitigating this risk.

The effect of Hidden Agendas on decision-making

There are two kinds of decisions: those that the individual makes, and those that the organization makes in their official channels and processes. Organizational decisions are based on various factors, such as goals, collective input, expertise, and external considerations. 

In some organizations, hidden agendas dominate daily operations. Official decision-making processes in such environments are mostly a show: "the real decisions" were already made, in different forums, with different actors, before anything is openly brought to the table: The hidden agendas determine the course of action. Strategy and organizational goals are reduced to being the pretext for the predetermined decision. 

In the grand scheme of things, this may go unnoticed - but it may also lead to massive failures. as the source of the discrepancy often can't be traced, this creates confusion as to why decisions were ineffective. Many organizations respond by introducing additional checks and balances which leave even less room for personal agendas, while also slowing down future decision making and incurring extra costs, which renders the organization even less effective. Instead of solving the problem, they exacerbate it!

Repairing Systems Dominated by Hidden Agendas

We have explored that one of the main reasons for the emergence of strong hidden agendas is a discrepancy between an individual's motivations and the constraints of the system. The absence of a forum that respectfully enables people to reveal their personal agendas and address agenda conflicts openly and constructively gave rise to the need for hidden agendas.

The consequence is "organizational debt," which consists of all the communication and collaboration structures and learnings that led people to form hidden agendas.

Organizational debt: The entirety of all communication and collaboration structures, processes, rules and learnings that impede organizations from effectively reaching their goals.

Repairing the system isn't as easy as creating a forum for open communication. Hidden agendas often involve unaddressed motives, intransparency, and conflicts of interest. Building a more effective system requires a comprehensive approach involving open communication, trust-building, active problem-solving and reestablishing a shared sense of purpose by offering meaningful organizational values with which individuals can identify.

Conclusion

Recognizing and addressing personal agendas is crucial for building a healthy organizational culture where collaboration, innovation, and productivity thrive. Instead of trying to eliminate personal agendas, we need to create an environment that encourages open communication, transparency, and alignment. This will mitigate the negative impacts of hidden agendas. A culture that values diverse perspectives and aligns individual aspirations with organizational goals, will be more resilient and cultivate an empowered workforce that drives long-term success.

Navigating the complexities of hidden agendas and proactively working towards building an environment that enables transparent and collaborative organizations is everyone's job. Enabling individuals to contribute their best while advancing the collective goals requires them to pursue their own agenda in line with the organization's agenda. Transparency and alignment of everyone's goals are keys to unlock the true potential of our teams and organizations.

The TOP Structure is one specific approach that can be applied at any level, in any organization, independent of state or size, to actively reduce organizational debt and build a better organizational system.

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.

TOP Structure - the Organizational Domain

 It sounds tautological that every organization needs organization - and yet, most companies are really bad at keeping themselves organized, and it hasn't gotten better with the advent of Remote Work.

Although it's technically correct that organization is non-value adding, it is essential to get organization right:

The Organizational Domain is the second core pillar in the TOP Structure

People

Do we have the right people in the right places, are they equipped and do they have the necessary support to succeed? People aren't just chess pieces we can freely move around on an org chart - they're individuals with needs and desires, and if we don't take care of our people, performance will decline.

Collaboration

Can our people collaborate efficiently and effectively? Are the right people in touch with each other? How much "telephone game" are we playing? Do we have policies that cause us to block one another? Do we optimize for utilization of individuals, or getting stuff done?

Learning

Do we get genuine learning from events, or are we continuously repeating the same mistakes? Do we have functioning feedback loops? Are we figuring out the levers for meaningful change, and do we turn all of this into action? And do we only focus on how we execute, or also what we work on, and how we think?

Why Organization often doesn't work

Especially project organizations and large "Programs" commonly neglect investing into working with people, improving collaboration or creating a learning environment.

Even "Agile" environments often delegate the responsibility for organization to the Scrum Master, although none of the items mentioned above can be done by a single person on a team - they're everybody's job: team members, support roles and management alike.

When the Organizational pillar isn't adequately represented, we quickly accumulate "organizational debt" - an unsustainable organization that becomes more and more complex, costly, slow, cumbersome and unable to deliver satisfactory outcomes.

Check your own team - on a scale from 1 to 10, how well are the above mentioned organizational aspects tended to?

TOP Structure - the domain of Architecture

In software, there's a critical intersect between technology, that is - how we turn ideas into working software - and our organization - that is, who is part of development and how they interact.

Architecture is at the crossover point of Technology and Organization

This domain is Architecture, and it exists one way or another - if we don't manage it wisely, the outcome is haphazard architecture, most likely resulting in an inefficient organization delivering a complex, low value solutions in a long time and at a high cost.

Am I trying to advocate for a separate architecture team? No. Take a moment and think about Conway's Law: If we have the wrong organization, the consequence is the wrong architecture, the consequence is the wrong technology - and the consequence of that is a failing business.

Architecture is bi-directional. The right organization depends as much on technical choices as vice versa. We need a closed feedback loop between how we develop, and how we organize ourselves.
In many companies, the architectural feedback loop is utterly broken, hence they're doing with 50 people what could be done with 10.

One of the key organizational failures which lead to the need for "Scaling Agile" is that architecture is either disconnected from workplace reality, or not even considered to be important. By architecting both our organizational system and our technology to minimize handovers, communication chains and process complexity, many of the questions which cause managers to ponder the need for "Scaling Frameworks" are answered - without adding more roles, events or cadences.

This form of architecture doesn't happen in ivory towers, and it doesn't require fancy tools - it happens every day, in every team, and it either brings the organisation in a better direction, or a worse direction.

When was the last time you actively pondered how technical and organizational choices affect one another, and used that to make better choices in the other domain?

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.

Ten things eerily close to Scrum that you may misunderstand

 There are some ideas around Scrum that sound a whole lot like they're based on the Scrum Guide - when, indeed, they aren't. Even worse: you might be doing them in a way that could cause problems. Let's dig in.

1 - Scrum Roles

If I ask you what the Scrum roles based on the Scrum Guide are, you're probably very quick to answer: "Scrum Master, Product Owner, Developer."

Wrong.

What? How can that be wrong?

Well, because the Scrum Guide doesn't mention any roles. Indeed, it doesn't even use the term, "role" any more. Scrum Master, Product Owner and Developer are merely accountabilities. That means, someone has to be accountable.

2 - Dedicated Scrum Master

The concept of a "dedicated Scrum Master" isn't mandatory based on the Scrum Guide. Neither is the concept that "a Scrum Master shouldn't be technical, so they don't dump their own bias on the team."

These ideas are often marketed in an attempt to provide job safety for the myriads of people who can do nothing else. You can do Scrum very effectively even if Scrum Mastery is an accountability that rotates among developers, for example, on a per-Sprint basis.

Caveat - they need to know what they need to do, and have enough time for doing it.

3 - Product Owners aren't developers

Neither is the concept of a "Product Owner who isn't a developer, so they don't interfere in the work" prescribed by Scrum. It's entirely possible that, for example, a senior developer assumes the PO accountability. As long as the Product Goal is clear, the Product Backlog well-maintained, Sprints deliver high value and stakeholders know what to expect, there's not going to be much of an issue.

4 - Team autonomy

Are Scrum teams really autonomous? Doesn't Scrum rely on team autonomy?

Try searching for the term "autonom" in the current Scrum Guide - you'll be surprised! Team autonomy isn't mandatory for Scrum. In fact, in larger organizations, it can't be - because if you have larger products, multiple teams need to collaborate.

Before proceeding, let that sink in:
Scrum teams are not free radicals.

5 - Each team has their own Product Owner and Product Backlog

Certain "scaling" approaches suggest that each team has their own Product Owner and Backlog. Well - for a Sprint backlog, that's true. But having a separate Product Backlog for each team adds problems rather than solving them. The Scrum Guide states that multiple teams working on the same product, "should share the same Product Goal, Product Backlog, and Product Owner."

Note that this isn't a Scrum rule, only a suggestion. I will leave it as an exercise to the reader to figure out why that is a good suggestion though. And if the answer is too difficult, try the book "Scaling Lean and Agile Development" by Larman and Vodde.

6 - Teams have their own Definition of Done

One of the first exercises Scrum masters typically do with a new team is to draft up their own Definition of Done. That's not necessary in larger organizations, because the organization could already provide a DoD. "But that's not Agile..." - no! On the contrary, it ensures that the term "Done" has a consistent meaning anywhere in the organization. It reduces complexity and misunderstanding. It's quite irritating when a stakeholder has to ask in every Sprint Review, "What ... exactly ... does 'Done' mean, when you say that?" 

Teams are encouraged to add details to the organizational Definition of Done. If they deviate from the organization-wide DoD, though, they invite trouble. Caveat - an organizational DoD should be absolutely minimal, lest it slows down teams with pointless busywork.

7 - Refinement meetings

"In order to prepare for the upcoming Sprint, the Product Owner invites the team for at least one Refinement meeting during the ongoing Sprint." That's a really common practice - but it's not what Refinement is!

Refinement is no Scrum event, for a good reason. Taking a peek at the top couple backlog items, maybe doing a small spike, or creating a wireframe, are all activities that can't really be done very effectively in a centralized meeting. They're better done by brooding over the items from your desk. And sometimes, reaching out to a user has a delay, and we really need the answer before moving forward. The asynchronity of refinement also ensures we don't disrupt the flow of work by having yet another meeting on our calendar.

8 - PO acceptance

During the Review, the team demos their work to the Product Owner, who then accepts it.

Search for anything even remotely resembling this concept in the Scrum Guide. It just isn't there. This sentence contains so many flawed concepts that if you practice this, I wholeheartedly advise a Scrum refresher training. 

The Review is about stakeholder alignment, and it's a working session, not an approval meeting.

The Product Owner also doesn't supervise any work done by developers - together with all the stakeholders, they inspect the outcomes of the Sprint, regardless of how much work was done or not done. 

Nobody "accepts" individual work items of the team. Developers meet their DoD, and that's it. If the DoD isn't adequate or the backlog items not sufficiently valuable, that's not a problem we fix by adding an approval step to the Review. We fix it by improving our DoD, refinement and planning approaches.

9 - One Increment per Sprint

This is probably one of the oldest misunderstandings of Scrum - that at the end of each Sprint, the team delivers one Product Increment which contains all the changes made to the product for the duration of the Sprint.

An increment is produced whenever a modification has been made to the product, and it's in a usable state. Scrum and MinimumCD are not at odds. Scrum teams can - and actually should - produce as many increments as possible during a Sprint, and also deploy and/or release them as early as possible.

During the Sprint Review, the sum of all increments produced since the last Sprint Review is inspected, as these are the outcomes of the Sprint. This sum could be anywhere from zero to infinity. A team which only works towards a single, integrated Increment at the end of a Sprint, will be much more likely to find themselves empty-handed, so that's a bad strategy to begin with.

10 - Backwards-facing Retrospectives

"The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved."

That's a literal quote from the Scrum Guide, so isn't isn't the Retrospective pattern of "What went well, what didn't go well, what we could improve?" - the best way to conduct a Retrospective? No.

"The Scrum Team identifies the most helpful changes to improve its effectiveness." - that's also a quote. Of course, we need to have consider what happened in the last Sprint. The purpose of our Retrospective, however, is looking forward, identifying the most helpful changes. If all you do in your Retrospectives is dwell on the past and make miniscule adjustments so that the same old problems don't constantly haunt you, you're not future-proofing your team.

The most helpful change you can make is that which will make you most successful in the future - which may not necessarily be fixing a problem you had in the past.

Bonus - Ceremonies

It sounds like an innocent mistake, but there's a huge issue hidden behind this label. Scrum events are called "event" instead of "ceremony" for a reason.

An event is, literally, "when something notable happens."
A ceremony is, literally, "doing what we always do in the way we always do it." 

Organizations implementing Scrum "ceremonies" usually find themselves getting very low value from these, not understanding why they're important - and not thinking about better ways to achieve better outcomes. 

As a consequence, we see purely mechanical Scrum which helps nobody, gets on developers' nerves, and the one thing that makes agility tick - Double Loop Learning - is overboarded before it ever started.

Decision-making in an agile organization

A challenging question in Agile organizations is: "Which decisions should be made where?" - we quickly end up in a heated debate of "team autonomy versus command and control." A red herring - and a false dichotomy that misses the big picture. There is a better way.

Making decisions

Let us first discuss briefly about the three ways that decisions can be made in companies:

Top-Down

Traditional organizations may be most familiar with this type of decision. When something needs to be decided, a manager needs to be informed about what is to be decided, preferably also with some information on the consequences of various decision types. At a convenient moment in time, the manager will decide, and the affected parties will act based on the decision.

Depending on how information is presented to the manager, the manager may decide based on an unknown bias. Managers are often unable to fully understand the consequences of their choices. In turn, teams have to deal with consequences that may not even make sense to them, but they lack the power to change things. The system encourages currying favor over full transparency, and a "making things look good" is worth more than "doing what is right." 

A lot of time is lost in presenting information to management in order to prepare the decision, even when the decision is seemingly obivous. Revising the decision requires significant evidence as well, even after the negative repercissions are already visible. Hence, top-down decision on the work are rarely efficient, effective or even helpful. And that's why they are avoided in leaner organizations wherever possible.

Autonomy

Agile organizations, especially those centered around Scrum, emphasize team autonomy - and thereby, autonomous decision making. Many developers don't like managers interfering with their work, and prefer this way of making decisions. Some get very religious on the "autonomy" part, and will insist on teams getting their way.

Autonomous decisions are both feasible and efficient when the team operates in isolation: As long as it works for the team, we're good. When the team isn't happy with a choice, they can quickly revise it and improve.

Team autonomy sounds great, but isn't a feasible approach when multiple teams interact.

Let's say that team A would like to define a customer as firstName and lastName referenced by customerID, and team B would like to define the customer as fullName and title referenced by customerRefID: Who is right?

If A and B decide autonomously, the system won't integrate, so everyone is "wrong."

Should management decide?

That brings us to the third option, which requires willingness to compromise:

Federation

Let us redefine team boundaries to objective boundaries. People contributing to the same goal, working in the same context, or on the same products, need to collaborate, lest they get stuck dealing with friction rather than making progress.

In larger organizations, we have multiple teams. They might be planning, working and delivering independently - yet, at some level of abstraction, they share the same goal.

As an example, if we're working on an Online Shop, we benefit little if our checkout process is optimized at the expense of user registration: our total revenue might go down if we force people to provide payment data upon registration already. Neither the "Checkout," the "Payment," nor the "Registration" teams can autonomously decide which approach is the best - they need to collaborate!

Thus, a "federation" is born: People whose work overlaps for one reason or another can federate. A federation compromizes on local autonomy to optimize globally. We have some centralization, and some decentralization, and we apply a higher-ordered decision framework to determine both how, and what, we need to centralize.

A federation offers us fast and efficient team-level decisions, as well as sustainable and effective overarching decisions.

Guardrails of federated decision-making

A number of common pitfalls can render a federation ineffective:

1. Not involving people who are affected by outcomes.
2. Involving people in the discussion who aren't involved in the outcome.
3. Forming decision queues.

This happens when we violate the general rule of thumb that any federation should decide as little as possible, and as much as necessary. 

The following decision-making flow can assist us in determining which decisions we would like to keep autonomous, and which are better to federate.

In sequence, we can ask three questions to determine whether we require a central federated decision session:

1. Will the decision affect others?
• We only need to involve those who are affected.
• If we affect nobody outside the team, we don't need others to agree.
2. Will the decision have long-term impact?
• Easily reversible choices can be subjected to experiment, and inspecting outcomes.
  
• Decisions that have a high cost of change require deeper discussions.
  
3. Is the decision highly time-critical?
• If there is a high cost of delay, "it's easier to ask for forgiveness than get permission."
• If cost of delay is lower than cost of change, the decision should be made centrally.

As we know from governments, federation has a cost attached and easily leads to bureaucracy. Hence, with every centralized decision, we should inspect and adapt on, "What are the costs and benefits of centralizing this?" - and, "Are there things we could change so that we could do this autonomously?"

The "Planning Tetris" Antipattern

 "We need to utilize all of our Story Points" - that's a common dysfunction in many Scrum teams, and especially in SAFe's Agile Release Trains where teams operate on a Planning horizon of 3-5 Sprints. It results in an antipattern often called "Planning Tetris." It's extremely harmful, and here's why.

Although the above feature plan appears to be perfectly optimized, reality often looks different: all items generate value later than they potentially could - at a higher cost, in longer time and with lower efficiency!

Accumulating Work in Process

Planning Tetris often leads to people starting work on multiple topics in one Sprint, and then finishing it in a later Sprint. It is resource-efficient (i.e. maximizing the utilization of available time), not throughput-efficient (i.e., maximizing the rate at which value is generated.)

That leads to increased Work in Process, which is a problem for multiple reasons:

Value Denial

Just like in the sample diagram above, "Feature 1" and "Feature 2" could each be finished in a single Sprint. And still, Feature 1 doesn't provide any value in Sprint 1, and Feature 2 has no value in Sprint 2. So, we lose 1 Sprint of marketability on Feature 1 (our highest priority) - and on Feature 2 as well:

A perfect example how utilizing the team makes the value come later!

Loss of money

Imagine now that every feature costs less than it's worth (which it should, otherwise it wouldn't be worth developing) - and you see that the "saved" efficiency of having worked on features 3 and 4 before finishing feature 1 costs the company more money than the added benefit .

Efficiency loss

You may argue, "different people are working on the features, so there's no multitasking."

Yes - and no. What is happening?

Sprint Planning for Sprint 1 has to discuss 3 features: 1,3 and 4. This means that the whole team is discussing three different topics, (none of which will be delivered in that Sprint.) The same happens in Dailies and Review. And, potentially at a source code level as well. The feature interference may also bloat up the complexity of technical configuration, deployment processes and the like.

The team becomes slower, hence less efficient.

Adding needless risk

In statistics, there's a phenomenon called "the high probability of low probability events." Let me explain briefly:  There's an infinite amount of almost infinitely-unlikely events, but unfortunately, high infinity divided by low infinitiy is still a number close to one: Something will happen. You just don't know what, and when, so you can't prepare or mitigate. Since you don't know which aspect of your plan will be affected when a risk hits, you'll always be caught by surprise.

How is that a bigger problem in Planning Tetris than in sequentialized delivery?

Massive ripple effect

When you're working on one topic, and an event hits that affects your entire team, you have one problem to communicate. When the same happens as you're working on multiple topics, all of them are impacted, and you're generating a much stronger ripple effect.

Complex mitigation

As multiple topics are in process, you suddenly find yourself mitigating multiple topics. And that means multiplicative mitigation effort - less time to work, and at the same time a higher risk that not all mitigations are successful. You end up with a higher probability of not being able to get back on track!

Chaotic consequences

Both the ripple effect into the organization and the mitigating actions could lead to unpredicted consequences which are even harder to predict than the triggering event. In many cases, the only feasible solution is to surrender and mark all started topics as delayed, and try to clean up the shards from there.

Prepare to Fail

There's Parkinson's Law - "work always extends to fill the amount of time available." That's often used as an argument to start another topic, because it stops gold-plating and keeps people focused.

But there's also the (F)Law of Averages: "Plans based on averages fail half the time."

The latter makes planning tetris a suicidal approach from a business perspective: it starts a vicious circle.

Predictable failure

Because there's no slack built into planned tetris, the mid-term plan will automatically fail as soon as a single feature turns out more complex than planned. The more features are part of our tetris stack, the more likely at least one of them will fail. And the team will usually get blamed for it. Because of that, we end up with

Conservative estimates

Teams must allocate the slack buffers into their feature estimates to reduce the probability of failure. When a Tetris plan spans multiple Sprints, some feature content may not be "Ready" for implementation during the Sprint when slack would be available - so we end up with Parkinson's Law, the buffered estimates don't reduce failure probabilities. 

Declining throughput

At this point, Parkinson's Law tag-teams with the Flaw of Averages to KO the team: Regardless of how conservative the estimates, the team will still end up failing half the time. The consequence is that business throughput continues to decline (there's an interesting bottom: when a Sprint only contains one feature!) 

Strangulating the team

Let's take a look at the psychological impact of Planning Tetris now as well:

No space for Creativity

I have never seen an organization where Product Management was happy that developers would add "creative spaces" into a Tetris Plan. It's all about churning out feature, after feature, after feature, without a pause, without a break. When one feature is done, another is already in progress. There is no room to be creative.

No space for Growth

The only relevant business outcome in Tetris Plans is usually business value delivered. It ignores that developers are the human capital of the organization, and growing them is growing the organization's ability to deliver value. Especially in the rapidly changing tech industry, not growing equals falling back until eventually, the team is no longer competitive.

No space for Improvement

I often advise that developers should take some time to look at "Done" work to reflect how it could have been done better, and turning that better way into action. With Planning Tetris, that opportunity doesn't exist - another feature is waiting, and improving something that exists is always less important than delivering the next big thing. That often ends in terrible products which are no joy to deal with - for developers and customers alike!

Now ... what then?

The point that Planning Tetris is a terrible idea should be blatantly obvious.

"Now what's the better way then?" - you may ask.

It sounds incredibly simplistic, because it is actually that simple.

1.  Reduce the amount of features the team is working on in parallel to an absolute minimum. This minimizes blast radius.
2.  Instead of having people parallelize multiple topics, let "inefficient", "not-skilled" people take easier parts of the work to step up their game. That reduces the impact of low-probability events and gives everyone air to breathe.
3.  Put slack into the Sprints. The gained resilience can absorb impact. It also reduces the need for buffered estimates, countering Parkinson's Law and the Flaw of Averages. It also gives people air to breathe.
4.  Agree on Pull-Forward. When the team feels idle, they can always pull future topics into unused idle time. Nobody complains when a topic is finished ahead of time, everyone complains when something turns late. Pull Forward has no ripple effects or chaotic consequences.

Ok, too many words, so TL;DR:

1. Sequentialize.
2. Slack.
3. Pull.

All problems mentioned in this article = solved.

The Product Owner Role

What concerns me in regards to the Product Owner role: it's so horribly diluted by many organizations that sometimes, practitioners ask me "What's the meaning of my work, and what should I do in order to my job well?"

There's so much garbage out there on the Internet regarding the Product Owner Role that it's very difficult for someone without significant experience to discern what's a proper definition that would help both companies define proper job descriptions, and provide guidance to PO practitioners how to improve. So - let me give you my perspective.

Great Product Ownership

I would classify great Product Ownership into four key domains:

While one of the core responsibilities of the Product Owner is the Product Backlog, it should be nothing more than the expression of the Product Owner's intent. And this intent should be defined by acting on these four domains.

Product Leadership

The Product Owner should be providing vision and clarity to the team, the product's stakeholders, customers and users alike.

Product Vision

Who is better than the Product Owner at understanding what the product is, which problem it solves, why it's needed and where it's going? Great Product Owners build this vision, own it and inspire others to follow them in their pursuit of making it happen.

This vision then needs to be made specific by elaborating long-term, mid-term and short-term objectives - a guiding visionary goal, an actionable product goal and the immediate sprint goal.

Clarity of Purpose

While the Vision is often a bit lofty, developers need substantial clarity on "what happens now, what happens next?" - and customers will want to know "what's in it - for me?" The Product Owner must be crystal clear on where the product currently is, and where it's going next. They must be able to clearly articulate what the next steps are - and what the next steps are not. They need to be able to state at any given point in time what the highest priority is, and why that is so.

The Product Backlog is then the place where the PO maintains and communicates the order of upcoming objectives and content.

Communication

The Product Owner must communicate their product with both internal and external stakeholders. Life is never easy, so they must rally supporters, build rapport with sponsors, and resolve the inevitable conflicts amongst the various groups of interest.

Networking

The product can only be as successful as the support it receives. As such, the Product Owner must build a broad network of supporters, and continuously maintain and grow their influence in their organization - and for the product's market. Keeping a close eye on stakeholder satisfaction and interest, continuously re-kindling the fire of attention drawn to the product is essential in sustaining and fostering the product.

Diplomacy

As soon as multiple people are involved, there tend to be conflicts of interest. Even if there is only one single stakeholder, that stakeholder has choices to make, and may need to resolve between conflicting priorities themselves.

In peace times, the Product Owner builds common ground with stakeholders, so that they are more likely to speak positively of the product.

In times of crisis, the Product Owner understands the sources of conflict, ebbs the waves, reconciles differences, brings people together to work out positive solutions, and mends wounds.

Insight

The Product Owner is the go-to source for both the team and the product's stakeholders when they want to know something about the product's purpose or intent. The Product Owner has both factual knowledge and inspiring stories to share.

Product Knowledge

Caution - the Product Owner isn't a personified Product Instruction Manual, and they don't need to be. Much rather, they should be the people to be able to explain why the product currently is the way it is, and why it's going to be the way it's going to be. They must be able to fully understand the product's capabilities and purpose - and they must be able to convey why these are good choices. 

From a more negative take, the Product Owner must understand the weaknesses of the current product and have ideas how to leverage or compensate these.

And for all of this, the Product Owner should have the domain expertise, market information and hard data to back up their statements.

Storytelling

"Facts tell, stories sell." - the Product Owner's role is to sell the product, both to the team, and to the customers. They should be able to tell a relatable, realistic story of what users want to and/or are doing with the product, what their current pains are, and what their future benefits will be.

"Speaking to pain and pleasure" is the game - touch hearts and minds alike. The Product Owner should be NEAR their users, and bring developers NEAR as well.

Business Acument

The Product Owner's primary responsibility is to maximize the value of the product, by prioritizing the highest value first, and by making economically sensible choices both in terms of obtaining funding and spending.

Value Decisions

There are three key value decisions a Product Owner faces every day:

1. What is our value proposal - and what isn't?
2. What value will we deliver now, and what later?
3. What is not part of our value proposal, and will therefore not be delivered at all?

The question oftentimes isn't whether the customer needs something, but whether they need it so urgently that other things have to be deferred or be ditched.

When anyone, customer or developer alike, asks the Product Owner what is on the agenda today, this week, or this month - the Product Owner must be able to answer in a way that the underlying value statements are clear to all.

Economics

With infinite money and infinite time, you could build everything - but since we don't have that luxury, the Product Owner must make investment decisions - what is a positive business case, what is a negative business case, what can we afford to do - and what can we afford to not do?

The Product Owner should be able to understand the economical impact of any choices they make: More people can do more work, but burn the budget faster. Every feature has an opportunity cost - all other features that get deferred because of it. Fines could be cheaper than implementations, so not everything "mandatory" must be done. These are just a few.

There is often no straightforward answer to "What should we spend our money on this month?" - and considering all of the trade-offs from every potential economic angle before bringing product related decisions to the team or towards stakeholders is quite a complex endeavour.

Economic decisions need to then be transported transparently towards the relevant organizational stakeholders - to team members, who may not understand where priorities come from, to customers who may not understand why they don't get their request served - to managers, who may not understand why yesterday's plan is already invalid.

Given all of these Product Owner responsibilities above, it should be quite clear that the Product Owner must focus and has little time to take care of things that are ...

---

Not the Product Owner's concern

Three domains are often seen as expectations on the Product Owner, which are actually a distraction from their responsibilities, and putting them onto the PO's shoulders actually steals the time they need in order to do the things that make them a good Product Owner:

Project Management

The Product Owner is not responsible for creating a project plan, tracking its progress or reporting status.

Let's briefly describe how this is supposed to happen:

Planning is a collaborative whole-team exercise, and while the Product Owner participates and provides context, a goal and a sorted backlog as input, they are merely contributing as the team creates their plan.

Developers are autonomous in their work, and the Product Owner should rely on being requested for feedback whenever there's visible progress or any impediments hinder the planned outcomes. If the team can't bear the responsibility of their autonomy properly, that would be a problem for the Scrum Master to tackle. The PO should entirely keep out of the work.

Since Sprint Reviews are the perfect opportunity to inspect and adapt both outcomes and progress, no status reporting should be required. A "gemba mindset" would indicate that if stakeholders are concerned about progress, they need to attend the Reviews, and should not rely on hearsay, that is, report documents. 

Team Organization

The Product Owner is not reponsible for how the team works, when they have meetings or who does what.

When Scrum is desired as a way of working, the team should have a Scrum Master. The worst thing a Product Owner can do with their time is bother with introducing, maintaining or optimizing Scrum - they should be able to rely on having proper Scrum in place.

Team events, such as Plannings or Reviews, help the team do their work, and as such, should be organized by the developers themselves, because only they know when and how they need these. The Scrum Master can support, and the Product Owner should attend - but the PO shouldn't be bothered with setting these up, and most definitely shouldn't run the entire show.

If anyone assigns tasks on a Scrum team, it's the team members self-organizing to do this. Having the Product Owner (or Scrum Master) do this job is an antipattern that will hurt the team's performance. The Product Owner should not even need to know who does what, or when.

Development Work

The Product Owner develops the product's position, not a technical solution. They have a team of experts to do this, and these experts (should) know better than the PO how to do this. That means the PO should be able to keep entirely out of design, implementation and testing.

Product Owners actively designing solutions often fall into the "premature optimization" trap, resulting in poor solutions. The best approach is to have the Product Owner collaborate with developers as needed to get sufficient clarity on how developers would proceed, but to focus fully on the "What" and keep entirely out of the "How."

When Product Owners have time for implementation, the product is most likely going to fail: while they're paying attention to the development, they aren't focusing on what's happening to the product and its customers out in the market.

Product Owners have a team of professionals around them who are supposed to deliver a high quality "Done" Increment. If their team has no quality assurance, the solution is to bring testers in, not to delegate testing to the Product Owner.