Múcuaverse

Explore

Múcua Guide

Work Structures

How to structure people in the Múcua Model

Introduction

In the section

Múcuaverse⁠

we discussed, among many things, the thinking behind the structures of the Múcua Model. We talked about small clusters that we referred to as “Cells”; and we talked about bigger clusters “of Cells” that represent “zones of influence”.

In this Chapter, the nesting of clusters becomes more precise and concrete. Structures have names and they also have rules on what makes them what they need to be. It’s a very simple model, really, backed by the principles and the thinking of The Múcuaverse.

In this section, we provide guidelines on how to surface those gravitational goals and thereby give shape to specific Cells. We will also sort out how that is done without a Hierarchy and without bureaucratic centralization.

Note: the Outline on the right sidebar (browser version) is a table of contents of this entire document. Use it to jump to the sections you’re most interested in or simply to give you some idea of where you are. Note that the Outline is scrollable (there may be more sections at the top or bottom than what you are seeing).

Remember...

Múcua is concerned with structuring the work people do in a Digital Enterprise. As described in the Múcuaverse, the Múcua model follows a strategy of the world of humans moving to the world of computers - Cyberspace - where there is freedom from physical constraints.

As you read through this document, always remember: when we talk about people being in a network, we are referring to individuals communicating with each other inside Cyberspace.

People working together means people communicating; but the communicating here is done through social networks or through VR/AR Metaverses. Thus:

Nowhere is it assumed that people are in a physical location.

Everything is done in Now Mode. As such, there are no “periods” and there are no frequencies. Nothing is assumed to be done Weekly or Monthly or...

There are no meetings - meetings are similar to frequencies in that meetings require that the world waits for everybody to be available for the meeting to occur. This is contrary to Now Mode.

The Múcua Model

The basic constructs of the Múcua Model are, essentially, nesting arrangements of cells and clusters of cells. To get an overview of these constructs, please look at the following video:

⁠

Nests

As you move through this section of the Guide, keep bringing your mind to these key notions:

An Enterprise is a multitude of individuals working and communicating with each other.

Individuals + communication = a Network

Networking is spontaneous [Spontaneous Association]. Some forms of communication are prescribed but the communication that happens while people are working is spontaneous - even in old-style organizations.

Clusters occur when people work; they are a natural phenomenon. Thus, the entire Enterprise is a Network - a continuous, connected space.

In Múcua, when we identify Clusters and give them names, we are not clipping the network; we are not snipping lines; we are not raising walls. All we are doing is recognizing what occurs and simply equating clustering to results.

Whether one takes an existing Network and recognizes its clusters; or one designs top-down what the clusters should be (and guide the network), we never constrain the links throughout the network.

Keep the network picture in your mind; tell yourself “I am not creating enclosed boxes”.

⁠

Screen Shot 2021-11-08 at 3.02.21 PM.png

⁠

Pods

The ‘cells’ we referred to earlier are called Pods.

⁠

What’s important about Pods is how they are defined, i.e., how you carve them within the Enterprise Network.

Any business enterprise operates through basic standard practices. If an organization is producing engineering designs, engineers don’t do structural analysis in a random way; they follow established methodologies which are part of the engineering profession. The same can be said of accounting, logistics, supply chain management, loan administration, investment account administration, etc.

These standard practies are not followed just once. They are typically repeated for multiple instances over time. If you manufacture a batch of a product, you will manufacture many batches. Hence, the manufacturing process is being repeated over and over. If you approve a loan, you follow a practice; you will approve many loans. Producing financial statements each month - same thing.

Thus, we can see a company’s operations as a collection of cycles - sets of activities that are repeated over and over.

In the Múcua model, we look specifically at End to End cycles. What defines an E2E cycle, in this model, is the result of the cycle - what is produced or delivered.

Our definition of an E2E cycle requires that what is delivered has meaning to a Customer; i.e., the Customer finds value in that Deliverable.

For example: let’s say a manufacturer has produced an item (an instance of the item) but the item hasn’t been released by quality control. The item at that stage is not a result that is meaningful to a Customer because the Customer couldn’t do anything with it. So, the activities that end with manufactured goods uncertified by quality control cannot be considered an E2E Cycle, for purposes of Múcua.

If an Architect is designing a house and she came up with a sketch of the house. That sketch may be interesting for her Customer and the latter may appreciate providing input at that early stage; but the Customer can’t do anything with a sketch. Hence, the sketch is not something of value to the customer and can’t be associated with an E2E cycle.

With this in mind, we identify Pods with two attributes:

They encompass sets of activities that end with a result that is meaningful - i.e., of value - to a Customer;

They include individuals with all the skills needed to deliver that result.

That’s a Pod. The scale of a Pod is in the order of a dozen people. An Enterprise Network, then, has many Pods.

People in Pods

Once Pods have been identified, it’s easy to figure who goes into a Pod.

A Pod is always identified by the E2E cycle it performs - always. That E2E cycle comprises tasks that must be done by qualified individuals. So, then: every skill needed to perform those tasks, such that the Pod is self-sufficient, will have to be included in the Pod team.

Now: remember that this is Cyberspace, a free zone without artificial, unnecessary boundaries or walls. For that reason, when Pods are carved or emerge, we are not limited to people from one Company or Enterprise. For instance, a Servicing Pod could contain people from a “Customer” entity. A Supply Pod could have people from a “Supplier” entity.

Huts

While a Pod may produce a result that is of Value to a Customer, it doesn’t necessarily deliver a promise to the market - not by itself.

⁠

As an example, look at a manufacturer of pharmaceutical drugs. It’s a long way to get a batch of medication into a Pharmacy. Along that path, there are various points that may be meaningful to a Customer:

An inventory of raw materials has been acquired and released by Quality Assurance (QA). Thus, it can be used to produce medication.

Finished Goods have been relased by QA.

Finished Goods have been shiped to the Customer.

Each of these 3 points of value delivery corresponds to a Pod. However, if the promise to the market is that goods ordered will be delivered on time, then it takes all 3 Pods, working in a network, to deliver on that promise.

There can be other promises to the market. For instance, one promise pharmaceutical manufacturers make is to certify recipes of new drugs in a market - so that those drugs can be manufactured and consumed.

A Hut is a big cluster made of multiple Pods which corresponds to the delivery of a major promise to the market. The scale of a Hut is in the order of a 100 people.

Villages

A nest of many Huts is called a Village. What does it equate to? Why are the Huts nested into a bigger cluster?

Villages have the same attributes as Huts do. A Village is associated to multiple promises to the market, within a broad domain.

⁠

Hence, a Village may equate to any of the following:

A major product class. In the example above, we may have a village for cancer drugs; or one for mRNA based therapeutics; and another for CRISPR-based therapeutics.

A Village may represent a broad domain of the industry. For instance, it’s pertinent to consider a Village for Generic Drugs; and another for Innovative drugs.

Worlds

A World is an Enterprise. In a large multi-national, there may be multiple operating entities as Villages; and then the full network of all the Villages would be a World.

⁠

Universe

Finally, many Worlds networked amongst themselves make up a Universe.

⁠

A Universe will typically correspond to an entire Supply Chain where many supply chain partners work together in servicing a particular market.

As an example, in the Pharmaceutical industry, there are manufacturers of active ingredients, others for packaging components; there are manufacturers of finished goods, distributors and retailers.

One can foresee, in the Digital world, a Universe being supported by a blockchain capturing all the transactions across that supply chain.

In a large country like the US, the federal government is so large that it could easily be conceived as a Universe. You could have major distinct areas of government - like Defence and Education - as Worlds.

The Video at the onset of this section provides a simple illustration of this model, with imagery that may help the reader create a mental map of the model.

All the Levels?...

As described, there are 5 possible levels of Nesting in Múcua. Are all these levels present in all cases?

No. The Model doesn’t assume, let alone impose, all Nesting levels.

In a small Enterprise, one may need a few Pods in one Hut. Nothing else. A case that justifies a Universe will be rare, in today’s environment. It may become more frequent as the world migrates out of the legacy of the 20th century but at the moment, this won’t be the main preoccupation with missions of people working together.

Depending on scale, you may find few Huts, many Huts, one Village or multiple Villages.

Nothing in Múcua expects the network of human activity in the scope of the Enterprise concern to be of any specific scale or within a maximum or minimum scale.

Leadership

The Network of human activity that constitue an operation - business, government, NGO... - in Múcua, is ‘made of’ Pods that are self-sufficient and self-managed. Big enough Networks have several levels of Nesting - Huts, Villages, etc.

But if everything is self-managed, where does Leadership fit - or does it?

Yes, it does - but it’s not the same concept as in hierarchical structures. In a hierarchical structure, Leadership = Authority and Power. Not in Múcua.

Eagles

All the individuals in Pods are working ‘close to the ground’ and human beings at ground level are not capable of visualizing more than a small portion of the ‘big picture’. You can’t be inside the forest - where your visibility is limited by the trees - and be above the forest, where you can see all the trees.

A network of human activity isn’t just a network; it’s not something that’s moving in some random direction. It could be but then, how would an Enterprise accomplish a mission? How would the boat travel to the intended or promised destination?

Hence, just as individuals working at ground level are needed, individuals hovering ‘in the clouds’ are also needed.

In more concrete terms, imagine a supply chain in some industry - food and beverage, energy, pharmaceuticals, retail banking, personal transportation, etc. - that delivers some form of finished product or service to customers. Along that supply chain, there will be many Pods and probably several Huts, even if one considers a single Enterprise.

Huts exist because it takes a network of multiple Pods to achieve that one thing that was promised to the market.

Eagles are individuals that look at all the Pods and guide them to ensure that the flow of activities ends in the right place.

Eagles help monitor whether the network of Pods is working harmoniously; and whether new Pods are emerging and need to be recognized.

If the market shifts - either customers, competitors, products and services or general conditions - what will happen is that Pods interacting with the outside world will be compelled to shift; new clustering will occur; there will be new networking circuits emerging as new activities are necessary.

Eagles help with the efficiency of the arrangement of Pods and guide people in those Pods maintain their respective focus.

In Múcua, there are the following types of Eagles:

Hut Eagles

Village Eagles

One or More per...

Classical managers are accustomed to the practice of one Leader per area of responsibility. It’s quite common to hear questions such as “who’s accountable”; “if there’s a problem, who’s accountable”; “I only want to call one person”. These perspectives are artificial fabrications of hierarchical thinking - and they actually don’t work.

In Múcua - and in Teal in general - accountability is not the attribute of a single individual. From a humanity viewpoint, it actually makes little sense that a single person be accountable for the actions of many people; and it causes all sorts of problems.

Instead, consistent with spontaneous association and self-sufficient Pods, we recognize the perfectly plausible notion of collective accountability. That’s why Pods don’t have ‘Pod Leaders’ and ‘single points of contact’. The same goes for all other levels of nesting.

For that reason, to think (let alone impose) one Eagle per Hut or Village is a limiting factor that is completely unnecessary.

It is perfectly acceptable to have more than one Eagle in the same nest - Hut or Village.

Eagle Pods

⁠

We may think that an Eagle works alone, monitoring the activity in one Hut or Village. That, however, is hierarchical thinking. Remember that the entire Enterprise - what we called a World - is networked.

Thus, Eagles need to work together. The Eagle of a Service Hut can’t work separately from the Eagle of a Production Hut.

All the Hut Eagles of a Village work in a special Pod called an Eagle Pod and collaborate in the monitoring of the networking in the Village.

In a large Enterprise, where Villages have significant level of nertworking amongst themselves, Village Eagles also work together in an Eagle Pod to monitor the Enterprise.

Monitoring by Hut Eagles

Eagles aren’t just different from hierarchical management because they ‘hover’ and they cluster in Eagle Pods. There’s another, substantial difference.

What does it mean to “monitor from the clouds”.

It may easily appear that the way Eagles monitor the movemement of Huts is separate from the work in regular Pods of the network. That is not correct.

Eagles work with the people in regular Pods. They don’t call review meetings and they don’t intervene at regular intervals. In classical management, there would be weekly or monthly reviews of KPI’s pertaining to, say, a Hut, and the Eagle would lead said meeting. This doesn’t work in Múcua.

Eagles mingle within the activities of regular Pods. They, however, have a different focus. The role of a Hut Eagle is to constantly map progress and conditions on the ground to the promise of the Hut. They are fed by the same information and the same reality as regular Pods. They just look at that information differently.

Eagles intervene by making recommendations to Pods. If an Eagle detects a shift in the flow of work of the Pods within a Hut, the Eagle immediately works with the Pods to find the best way to make adjustments needed to adapt to new conditions. The interventions by Hut Eagles is not at the level of the activities inside Pods. Usually, Eagles will identify 2 types of things:

The E2E Cycle that is the focus of a (or several) Pod(s) is changing or needs ot change;

New arrangements of Pods are emerging and need to be recognized.

The criteria that drives a Hut Eagle is always the success of the promise of a Hut. Eagles aren’t interested in how the work inside Pods is done. Eagles work on direction and patterns of networking; not on activities and events.

Work and Monitoring are simultaneous

In Múcua, we are in Cyberspace. We are not limited in how we work by physical constraints.

As mentioned in the Múcuaverse overview, we take advantage of Cyberspace to work in real time - what we called “Now Mode”.

In classical management, work and the review of work progress are done in sequence. People do their daily work; then, at certain intervals (say weekly or monthly), information is gathered and reviewed by “management”; and there may be several stages of management review - first at a departmental level; then at an executive level. Generally, the concept of hierarchical management is that one level of review waits for the previous level.

In Múcua, we function in now mode. Thus, doing the work that Pods do and monitoring shifts in the network and in the performance of the network - are done at the same time.

Let’s use an example: imagine a Village that is delivering custom furniture to a customer’s doorstep. And in this village, there are Huts for Furniture Manufacturing and for Furniture Supply and Service. Inside each Hut there are multiple Pods and they work together.

Let’s say that in the Manufacturing Hut, they are having trouble with a certain type of wood in manufacturing a table design; and let’s say that the customer demographic is changing and the tastes and needs of those customers is shifting - at the same time.

These issues don’t appear all at once at the end of the month or quarter. They emerge randomly, anytime, sometimes suddenly, sometimes gradually. In our example, the Eagles in Manufacturing picked up on the issue with the source of wood and the Eagles in Supply and Service noticed the shift in demographics. Those Eagles are part of the same Eagle Pod for the Village. They have been working with the regular Pods but they also work with one another.

When these issues pop, Eagles discuss impacts on the Village - not just on individual Huts - right away; and that conversation is not concealed inside the Eagle Pod; they are open to everyone and so people in the concerned Pods will participate. Those conversations are not directed; they occur through spontaneous association and so, quickly, solution paths emerge, decisions are made and action is taken - all in real time and in parallel with regular Pods’ activities.

In the meantime, when the wood issue popped, Pods in Manufacturing started working on the issue itself immediately; and the shift in demographics surfaced through customer orders, which Supply and Service worked on right away. Acting on an operational event occurs at the same time as acting on trends and shifts in patterns.

What do Village Eagles do?

In any business or enterprise, Strategy is a normal practice. But it’s a practice, it’s something we do - it is not the attribute of someone's title.

While Hut Eagles are focused on what we need to do now to accomplish a mission, a different thought process is that of formulating that mission. It requires taking a look at what might happen and to anticipate the smartest ways of leveraging new conditions.

But who knows about “new conditions”? Who is naturally thinking about movements in the conditions that surround the Enterprise?

In Múcua, those people are Village Eagles.

⁠

In very simple terms, Strategy is what an Eagle Pod with the Village Eagles of the Enterprise does.

Contrary to the monitoring by Hut Eagles, as described above, Strategy is indeed separate from operational activity. It becomes criteria for what Pods and Huts pursue but it’s a separate ‘thing’.

Note that while the Strategy Pod is the focus of Village Eagles this does not exclude anyone from those conversations. As was the case of ‘shape shifting’ with Pods and Huts, changes in strategy are also approached through spontaneous association.

Village Eagles raise the issue as a conversation and any Eagles or Pods in the operation will participate as appropriate. Through the dynamic of Múcua, solution pathways to strategic challenges are arrived at and implemented as they are decided.

Note as well that in Múcua, Strategy is not something that you do at certain periods. In the Now Mode environment of Múcua, everything is event-driven. Things are done when they need to be done. Just as Hut Eagles monitor current operational activity, Village Eagles are interested in shifts in a broader perspective - specifically market conditions and innovation conditions.

This kind of monitoring and thinking happens simultaneously with all other activity. It happens every day and strategy rethink can be triggered anytime - whenever something happens that questions the current strategy or raises opportunities for strategy revision.

Shaping Múcua

There are two basic approaches to structure a Múcua network:

Theoretical

Practical

And you may find that both are useful.

Theoretical Approach

We can try to figure out the constituent parts of a Múcua from theory. This approach should be taken with a grain of salt. Whatever you do in this approach, keep in mind always that reality will override your thinking. Don’t structure an Enterprise as a bureaucratic design of any kind. It’s useless and defeats the purpose of the model.

If you are not familiar with network models and Agile models, this is the approach that will be easiest to start with - but you must consider it as a starting point. You’re not designing an organization as you would in a hierarchical model.

A Teal enterprise is, first and foremost, a network of people; a network that is a living organism - and we mean that literally. You can’t freeze a Múcua. If you spend a lot of time defining Pods and Huts, discussing their meaning, documenting the various parts and then ‘teaching’ the people in the company what the structure is - you are going in the wrong direction - catch yourself; stop; move in the opposite direction.

Who

And who does this theoretical thing? Village Eagles may be the initiators but everybody can contribute. Again - spontaneous association.

The basic ideas are posted in Cyberspace and then, through public conversations, the model is validated and finalized.

There isn’t a lot of confidentiality in Múcua. It’s an environment of open collaboration where the people who can address a topic will spontaneously gravitate to the conversation; and those who can’t, will skip the topic.

How

So, what you do is this:

Start by defining the main things the company does; what are the promises to the market. This should be a simple question to answer. E.g.:

We design products and services for Customers;

We produce them;

We deliver them to Customers and provide great service.

You may want to separate major categories of Products and Services. E.g.:

In Financial Services, you may separate Lending Services from Investment or Insurance.

In Pharmaceuticals, you may want to separate small molecules from large molecules.

Thus, you may identify a Village for each major product/service category (note: if you only have one, you only have one 😊).

And then, within each, you would identify a Hut for each of those main things: in the example above, there would be 3.

For each of those main promises, you then look at standard methodologies or practices.

How you design or manufacture a pharmaceutical product follows standard practices that are part of pharmaceutical science and constrained by health regulations.

In order to design a Mutual Fund or a Mortgage, you must also follow standard professional practices from the world of Finance, which are also constrained by regulations.

The same can be said of Automobiles, Software, Lodging, Consumer Goods, Food and Beverages, etc.

Evidently, within each Enterprise, standard professional practices are adapted and embedded with unique features and innovations. The point here is that, invariably, practices exist.

Along the path of a standard practice or methodology, there are Deliverables. For instance,

In the design of products and services, there may be a sketch, a prototype, a pre-production specimen, a specimen for submission to regulatory entities, etc., before the design and specification of the product or service is ready for ongoing delivery to and consumption by Customers.

With few exceptions, those practices are repeated multiple times for multiple occurrences.

Each of those deliverables, then, can be considered a Cycle - because it repeats.

However, not all deliverables are considered of value by Customers. It’s not difficult to decide which ones are and aren’t. You involve people with experience dealing with Customers of that subject matter; and you involve Customers themselves. Ask the Customer; she’ll tell you!

Hence, the following might be Deliverables of meaning for Customers, even if they aren’t the last deliverable to be consumed by the latter:

A product recipe that is stable and ready to scale;

A pre-production prototype that has met all required test results;

A product specimen and specification that has been submitted to regulatory authorities for approval;

And, of course, the final product specification.

Thus, the criteria of what’s “of value” is not that the deliverable is what the Customer will consume. A Customer will consider a Deliverable as being “of Value” if she can recognize what was promised in that Deliverable; or if it represents a high likelihood that the promise of the Hut will be met.

Example: in the Pharmaceutical industry, in small molecule products (tablets and capsules), the most important raw material of a product is what is called an Active Pharmaceutical Ingredient or API. It is the API that equates to the good the product will do to a patient.

An API is an absolutely necessary condition for a pharmaceutical recipe to be viable. Customers - particularly Health Professionals, if not Consumers - will relate strongly to the value of having determined or acquired or established the manufacturing of the API for a Product. Even if the entire Recipe is not yet ready, that critical step may well be considered of value for most Customers.

Each Deliverable of Value, in the path towards the final promise of the Hut, emerges at the end of a Cycle; and that Cycle is called an End to End Cycle (or E2E for short).

Each E2E Cycle represents a Pod.

Practical Approach

The Practical Approach could also be called “let reality tell you what to do”.

If you consider any live operation - a Factory, a Hospital, a Government Department - that Network that we are trying to ‘zone’ already exists.

Network Mapping

We can (read:should) use network mapping software to map a network where the nodes are individuals working in the Enterprise and the links are exchanges between individuals. The data that expresses those exchanges is contained in emails or social networking conversations.

If you create a map of what’s going on in the Enterprise, in terms of people ‘talking’ to people, you can analyze that map and highlight clusters.

As mentioned earlier, there are small clusters with a high density of communication going on. Invariably, you will see these clusters centred on one or more individuals. Let’s see our sample network as a refresher:

⁠

E2E Cycles

Just by looking at each of these small clusters, you start identifying Cells. If clusters are centred on specific individuals, by knowing who the individuals are it is easy to identify what’s happening in that cluster.

Out of that analysis, you can identify discrete Cycles, based on standard practices.

And of the Cycles that you identify, you then go through the same “value to Customer” exercise as in the theoretical approach to arrive at the selection of E2E Cycles. As before, each E2E Cycle is a Pod.

Huts

Mapping software can also colour code each node and link, based on user-specified classifications. Use classifications that have to do with Deliverables, rather than Functional domain. For instance:

Colour coding “Quality Assurance” or “Manufacturing” or “Packaging” or “Customer Service” or “Marketing” - for purposes of Múcua modelling, is not a good classification strategy.

But if you colour code “Manufacturing and Release of finished goods”; or “Design and Specification of pre-production prototypes”; or “Ship and deliver on time” - these are useful classifications.

You will likely notice a lot of activity around each colour code. If you don’t, revise your classification until everything in same colour zone looks connected and compact; and until you see few interactions that cross two Zones. [Don’t look for precision in this exercise. ‘Eye ball’ the map and if an area is mostly of one colour, that’s good enough.]

Each of these Zones can be identified as a Hut. You must validate, though, that each Zone matches an end-deliverable - the meeting of a “key thing” that the Enterprise does for Customers.

Which Approach is better?

The Theoretical Approach is very useful as a starting point, particularly in cases where an Agile Model doesn’t exist.

If you’re starting or if you are migrating from a Hierarchical Model to a Múcua, you should begin here. However, as mentioned earlier, we can’t emphasize enough that you must avoid falling in the bureaucratic trap.

At best, a theoretical model can be useful as a frame of reference, something that helps sort out a messy reality. But don’t-turn-it-into-a-procedure.

The Practical Approach is what should be used all the time.

When Hut Eagles monitor the operation, a network map is the ideal tool to monitor shifts in the operation and detect the need to recognize new Pods or even Huts.

When Village Eagles examine the operation and look for signs that a Strategy needs revisiting, the map of the live network is an excellent tool for that purpose as well.

We repeat that shapping a Múcua, whether it’s about Pods, Huts or Villages, is not a centralized process. It is not the “privilege” of Village Eagles.

Hut Eagles have a different focus than regular Pods. However, as outlined earlier;

They operate as a Pod in each Village;

What they see and identify as issues to address (new Pods, new Huts, changes in the existing structure, etc.) are not addressed separately; they are posted publicly and everyone can participate in addressing those types of opportunities.

The same can be said for Strategy. Village Eagles are focused on Strategy but:

They don’t operate in isolation; they are part of an Eagle Pod focused on Strategy.

The opportunities they raise as part of their unique focus, are also posted and discussed publicly.

Shapping a Múcua is not a bureaucratic exercise, neither is it an exercise in Power. It’s an activity that benefits from spontaneous association to arrive at a great result very fast.

Example of Múcua in Pharma

A Village in a Pharmaceutical Enterprise:

⁠

A Pharmaceutical Company does three main things for customers:

Develop new products

Make those products

Align the supply chain with the needs of customers

Thus, we identified three Huts.

Inside the New Product Hut, we find 4 E2E cycles, qualified as delivering something of value to customers; thus, 3 Pods:

New Technologies - Innovative companies that research new technologies - such as the use of CRISPR-Cas9, different methods to explore RNA mechanisms (mRNA, tRNA) in the manufacturing of proteins, etc. - utilize practices that lead to determine the feasibility and applicability of technologies to a therapeutic field.

New Recipes, which is the cycle from initial formulation design to the filing of new recipes with regulatory authorities.

Market launch, the cycle of introduction of new products into the market.

Configuration management, which is the management of the integrity of a product recipe throughout its lifecycle.

The Manufacturing Hut is quite straightforward:

The Raw Materials Pod entails the work to acquire raw materials and release them for consumption by production batches.

The Manufacturing Pod encompasses the complete cycle of transformation of raw materials into finished goods and final release for sale to the market.

Finally, the Supply and Services Hut contains three Pods:

Relationship Management includes all the activities aimed at understanding customer needs and formulating solutions to those needs, as well as the monitoring of customer satisfaction.

Supply Management consists of all the processes in the discipline of demand and supply chain management.

Delivery Service consists of the delivery of products and services ordered by customers, on time and to their satisfaction.

Instances

The short example above describes a Village. A company can have many Villages that look like this one, each limited to a product class or a technology. For instance, there can be a Village for Small Molecule therapeutics, Large Molecule Biologics, Gene-Cell Therapies, etc. They can all have the structure of this example but each is limited in scope.

In more complex arrangements, you may have Villages with multiple like-Huts. Imagine a Pharmaceutical company with 1 New Product Hut; 3 Manufacturing Huts - because they have 3 Plants; and 4 Supply and Service Huts, one for each of 4 Markets.

You may also have Huts with multiple like-Pods. A New Product Hut may have multiple “New Technology” Pods - for instance: AI Drug Discovery, mRNA, tRNA, etc.

Thus, when we spoke of identifying Huts and Pods as described thus far in this Chapter, we were actually defining Types of Structures. The diagram in the above example is a very simple picture but it’s not reality (unless it’s a very small operation). Each Type of Structure - type of Pod, type of Hut, Type of Village - is going to be instantiated by area of focus.

We call these instances. A real-life Pod is a type of Pod focused on a narrow scope. Same for Huts. You can have a Hut of the Type “Supply and Service” for the European Market and then another with the same Type but for South Asia.

When you identify specific Instances of the structure, you will arrive at asymmetrical nests. One Village can have more Huts of one Type and less Huts of another Type. There is no rigid restriction in the Model as to how instances are multiplied and how they are nested.

As we said earlier, though, you let the network of people doing the work surface discrete Pods and Huts, as a matter of course. As people do their work, network analysis, included in the role of Hut Eagles, will show where the clusters of activity are.

Examples of Instantiation

When we're thinking of Types of structures - Pods or Huts - the image remains fairly simple. When we go into Reality, we realize that the various Pods in a Hut aren't necessarily in a 1:1 relationships. The same may happen in the relationship between Huts.

It's impoirtant not to get caught in a theoretical distribution of structures and then force that into reality.

Following is a concrete example of a manufacturer of Pharmaceutical Products where you may see how many of each type of Pod appear; and how different Huts approach instantiation differently.

⁠

This company has two Plants, one for Small Molecule products (capsules and tablets) and another for Biologic products. In each of their Huts, Pods are subdivided by what we call Corridors - groups of products that are manufactured together.

In the Supply and Service Hut, you will notice that the Supply Pods are also by major category of products; however, the Customer Relationship Management (CRM) Pods, are instatiated by market; and only one Procurement Pod in the Hut.

The Product Development Huts are split as the manufacturing Huts, however the New Product Launch Pods are subdivided by Market, in a parallel Hut.

Keep in mind, now, that all these Pods can communicate freely with one another. The predominant frequency of communications are within the Pods - each of them designed to be self-sufficient - but there are exchanges across Pods and indeed across Huts.

As explained earlier, the outlines of Pods and Huts are not silos and they are not rigid structures. They are structures of Focus, they are not organization structures, in the classical sense. There are no bosses or leaders of Authority. The entire population is one big Hive where everybody collaborates.

You may envisage that each Hut in the picture above has at least one Eagle and those Eagles work together always (as part of the Eagle Pod). Every discussion - strategic or tactical - in the Eagle Pod - as in all other Pods - happen in social networks and are visible to everybody. Eagle Pods don't make decisions on direction or strategy on their own. Eagles work with the Pods to arrive at the best conclusions and implement them very rapidly.

The span of this example corresponds to a Village. A Company like J&J or P&G may have various Villages similar to this one. J&J, for instance, may have one Village for Pharma and another for Consumer Goods.

This example illustrates well the advantage of human communication networks without a hierarchy interfering with communication lines and slowing down actions.

Support Huts

The types of activities that we have been talking about in the context of crafting Múcua structures, relate to the direct work to deliver things of value to customers.

However, there are other types of activities that don't directly create deliverables for customers, but without which the value delivery activities would not be possible.

We recognize these essential services that support the operation with Support Huts. In most organizations, there are two categories of Support Huts:

Infrastructure

And Business Administration

Following, we provide some guidelines on how to structure these types of Huts.

Infrastructure

Infrastructure huts are quite straightforward to identify. They typically correspond to some form of facility and entail the work to create those facilities and maintain them. Here are some examples of infrastructure Huts.

Buildings and environmental systems

Equipment

Manufacturing Equipment

Lab Equipment

Office Equipment

Warehouse Equipment

Virtual Office Equipment

Digital Technologies

Big Data and AI Platforms

Digital Ecosystem Platforms

Blockchain Infrastructure

Business Systems

It’s important to distinguish between a support service and a skill set. Here’s two examples that may help illustrate this distinction:

In Pharma companies, it’s quite standard to have Departments of Regulatory Affairs with individuals who specialize in the language and bureaucracy of regulatory entities.

It’s easy to come to the Múcua context and ‘resurrect’ Reg Affairs as a Service Hut or Pod. This would be incorrect.

In Múcua, at best, Reg Affairs are activities that are part of regular value Pods; and the specialists that focus on regulatory requirements are professionals with that role, inside those Pods. Reg Affairs activities and people would contribute to such Pods as Configuration Management and Market Launches.

It’s quite possible that some people will see Quality Assurance as a support service justifying a Quality Hut. This view would be incorrect.

Quality Assurance, in fact, is an activity that is carried out in the context of manufacturing a product. Those activities, by themselves, are of no value to a Customer (quality is, of course, of value to customers; but QA in isolation doesn’t make product). They are part of a Pod called “manufacturing” and contribute to the release of product to market.

A word of caution: one can get carried away in establishing what is the meaning of support infrastructure. If you are accustomed to working in a hierarchical organization, it's quite possible that your thinking will drift towards functional groupings. If it does then stop and turn in the opposite direction.

Business Administration

Any organization that would entertain applying Múcua will be limited by legal constraints that will force it into practices aimed exclusively at satisfying those constraints.

Business Administration is a ‘necessary evil’ and it’s an area where there will be a strong tendency towards functional decomposition. Let’s see how we tackle this challenge.

Financial Management

Accounting is 4,000 years old. The practices entailed in Financial Management are well known and tried and the Múcua perspective doesn’t require that you change anything in standard Business Finance.

What we do recommend is that you keep it very simple and limited.

The Financial Management Hut should only include the activities necessary to satisfy legal/regulatory requirements and shareholder requirements.

A good rule of thumb is that if you include in the Financial Management Hut things of an operational nature, you are probably doing it wrong. We’ve seen activities included in the scope of Finance Departments in functional hierarchies that shouldn’t be in a Financial Management Hut in Múcua.

Here are some dos and don’ts:

Things that belong in the Financial Management Hut:

Financial Statements

Financial Audits

Taxation

Payroll

Profitability Monitoring

Cash Flow Management

Funding

Corporate Counsel

Things that shouldn’t be in the Financial Management Hut:

Sales Planning ➡️ Customer Relationship Pod

Invoicing and Collections ➡️ Delivery Service Pod

Supplier Invoices and Payments ➡️ Supply Management Pod

Cost Control ➡️ the value delivery Huts; or Infrastructure Huts

Indirect Procurement ➡️ Infrastructure Huts

These lists are not exhaustive. They are meant as illustrations to help understand the points made above.

Remember: in Múcua, we don’t think Functionally. In many organizations, the word “Finance” means “anything to do with money” - that’s functional thinking.

In Múcua, Financial Management has a narrower and more strict meaning: to protect the investments of shareholders and the return on those investments. Operational transactions, in our view, are part of what needs to be done to deliver value to Customers through operational Pods.

Human Resources

There is no Human Resources Hut or Pod in a Múcua model. Instead, the general concern of caring for the people of the organization is handled in a completely different way that has nothing to do with the traditional HR bureaucracies of 20th century organizations.

The Múcua approach to People is described in the

Learning Structures⁠

Chapter of this Guide.

⁠
`Learning Structures`⁠

⁠
`Operating Digital Technologies`⁠
⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Work Structures

Introduction

Remember...

The Múcua Model

Nests

Pods

People in Pods

Huts

Villages

Worlds

Universe

All the Levels?...

Leadership

Eagles

One or More per...

Eagle Pods

Monitoring by Hut Eagles

Work and Monitoring are simultaneous

What do Village Eagles do?

Shaping Múcua

Theoretical Approach

Who

How

Practical Approach

Network Mapping

E2E Cycles

Huts

Which Approach is better?

Example of Múcua in Pharma

Instances

Examples of Instantiation

Support Huts

Infrastructure

Business Administration

Financial Management

Human Resources

⁠Learning Structures⁠

⁠Operating Digital Technologies⁠⁠

⁠
`Learning Structures`⁠

⁠
`Operating Digital Technologies`⁠
⁠