Who would win in a fight…

“Who would win in a fight betwen a Moose and a Bison?” says my then-six year old son after our visit to Yellowstone.

Being as this is the 768th question of that type that he’s asked in the last 5 minutes, I’ve had some practice answering.

“Which one is bigger?” I ask.

“The Moose.”

“Yes the moose is definitely taller.   Which one weighs more?”

“The Bison”

“Okay…well then the Bison probably wins the fight.  In animals, the heavier animal almost always wins a 1-on-1 fight.”

30 seconds later:  “Who would win in a fight between a Fox and a Bobcat?”

Rather than subjecting you further to 392 more conversations about animals, I’d like to talk about organizational survival strategies.   Interestingly, they seem to largely match up with animal kingdom survival strategies.

Essentially, animal survival strategies come down to one of the following:

Be big/tough enough that you’re hard to kill.
Be quick enough that the big killer can’t catch you.
Swarm, so that even if some of you die, you still succeed.
Have special skills (poison, shell, etc.)

Making a small nimble rabbit work with a turtle shell just isn’t going to work.

So what about organizations?

Some organizations are like hippos.  They’re just big.  Because they’re big, and strong, and tough…nothing much messes with them.

Other organizations are like rabbits.  They dance and dodge, bob and weave, and move quickly to handle issues.  But they have to, because they’re small.

Other organizations try lots and lots of things.  Most of them fail, and occasionally something works, often very well.

And still other organizations become unreasonably good at one or two things, and focus only on that.

What folks seem to have a big problem with is:   they want organizations to do things that the organization itself isn’t designed to do.   They want rabbit-like fast organizations to be highly resilient.    They want large, hippo-organizations to bob, weave and dance….and implement Agile type speeds.

Have we considered whether if you’ve got a hippo, asking it to dance (on land) is a rather absurd proposition.   If you get the hippo in a tutu, we should probably call that a win, and go home.

Six Sigma versus Business Analysis

Six Sigma Business Analysis
Purpose Remove defects created by a process Discover user needs and align with business objectives
Approach Remove variations in the process Feedback from users
Main Skill Set Statistics Analysis
Objections Forget to ask should we even do this, or is there a different, better approach. Most people are really bad at statistics. Removing all variation inhibits innovation and growth. Too often just an order taker or list maker. Analysis is not a common skill.


What’s your problem?

To Solve a problem, first figure out what problem you’re solving.

If you have a problem that centers around how to get something done fast and efficiently…note that speed is the essence of your problem.  Probably, speed trumps correctness, repeatability, and documentation.  So…do it fast.   The problem you’re solving demands you do it fast.

If you have a problem that centers around solving the same problem repeatedly, then recognize that repetition is the essence of yoru problem.  Don’t build a solution designed to be fast.  Build a solution where repeatability is the essence.

One of the major problems in modern software process is that no one is willing to admit what the central problem is that their process is designed to solve.   Hero is designed to solve small problems.  Commander is designed to solve problems of how to coordinate lots of people.   Agile is designed to solve problems around change.

What’s your problem?   If you can figure that out…you might be able to decide how to solve it.

The Myth of 100% Utilization

I have gone into many a company whose managers brag to me about their 100% utilization of their people. They have all the techniques down pat and know just how to do it. I see opportunity. If they are willing to listen, I can improve their productivity 20-50% by not trying to get 100% utilization.


First, some terms need to be defined. Availability is the amount of time someone is available to do the job you hired them for. If they are a programmer, they are programming. If they are tech support, they are working with customers. If they are a tech writer, they are writing. Utilization is the amount of the available time that the person is actually doing the work. Many companies count utilization as the percent of hours a person bills to a project. That is merely how someone charges their time, not a measure of what they were doing in that time. To improve utilization, you have to improve both availability and utilization.


To know the actual time someone is working at their job requires observation. Many of these studies have been done for knowledge workers of all kinds, where the researcher follows someone around all day, tracking the time they spend on everything they do. They do this for maybe hundreds of people (multiple researchers of course) over an extended time. Companies pay for this research because they are looking for inefficiencies in their processes. Fortunately a lot of this research is published and the results are very consistent. This means you can use averages instead of paying for the research at your company.


The highest availability anyone has measured was 80%. Your most productive people are available at best 80% of the time to do their jobs. This is actually a good thing! They are not doing nothing in the other 20% of their time. The other time is spent on things such as company town halls, training, meetings with their boss, meetings with their team, and so on. When you think of all the things that pull people away from their work, 20% is a quite reasonable number for those kinds of activities. You want to allow your people time for career development.


You think that the contractors you hire must be at 100% availability. Of course they are 100% available for the hours they bill you. If they are billing you at 40 hours a week, they are almost certainly putting in about another 10 hours a week on their own time (or their staffing company’s time) for these other activities.


If you really had 100% availability, you would have unhappy, burned out employees who quickly leave for better opportunities.


So far, we know we cannot have 100% utilization of people’s time because they need about 20% of their time for activities other than the actual job you hired them to do (programming, writing, tech support, etc.). But what about 100% utilization of the 80%? We can use all our management tricks to get that number; we do it all the time!




Let’s consider all the things that prevent people from working 100% of their available time. Start with task switching. If you assign people to two or more projects at a time, you are losing on average 10% of their time every time they switch between projects due to having to switch their brains from one project to the other. Averaged out, this amounts to about 20% loss of productivity for each project you add (because people don’t usually just switch once between projects). This number is extremely well established based on about 90 years of research. It is real, it is going on, whether you want to admit it or not.


The first step then is to focus your people on one project.


But you say you have specialists and they don’t have that much work to do on one project. Then cross train them. The specialist model has been well studied and shown over and over to be inefficient. It looks appealing on paper, but actual measurement in real life shows that specialists lose most of their time to task switching. You are not getting much actual work out of your specialists anyway, so leave them in one place and teach them new skills.


The second step is help your people gain additional skills so there is more work that they can do.


A final common cause of lack of utilization is the huge number of interruptions due to telephone, e-mail, instant messaging, texting, and so on. For best utilization, you want to focus your people’s time on one project and you want to focus their attention. Get rid of the sources of interruption for some number of hours every day and add practices that help them focus on their work. Since you only have 80% availability, make that 80% as interrupt free as possible. For 6 hours a day, no phone, email, texting, or IM. Seat the whole team together so they do not need to use phone, email, texting, or IM to communicate with each other. Have them work in pairs to stay focused on the job.


The final step is to put people who work together in one place, remove interruptions for 6 hours a day (phone, text, email, IM), and have them work in pairs as much as possible.


There are companies who have taken these steps and watched their productivity soar. Companies who deliver products to market at 1/10th the cost of their competitors. Maybe you don’t get that much lift, but what is the value to you of a modest 10% gain? What if it was 20%? Is that worth changing they way you staff your projects?

Different Ways of Managing Work

Managing Work

Inside your company, many different kinds of work are being done. Rather than examining the work and then deciding how to structure it, most companies take a one size fits all approach. Many companies have decided that everything has to be run as a project, so they hire a lot of PMPs and set up systems to track the progress of a project. Other companies see success using Scrum in software development so they decide that everything has to be run using Scrum teams, and they hire a lot of Scrum Masters, and usually still try to account for the work as projects (though more enlightened companies fund Scrum Teams instead). Other companies fund product teams and all work is accounted to the product.

The fact is that all of these approaches work (as do many others). Where we make a mistake is treating all work the same way. The reason it is a mistake is that when we organize work in a manner not appropriate to the work itself we introduce unnecessary overhead and cost. You can keep doing everything as a project or everything as Scrum, just know that the work of your company is more expensive than it needs to be.

A Fluid company will look for the best way to do work based on the type of the work itself. In this post, I will examine three primary ways of managing work and discuss the kind of work that fits each management technique. These three ways of managing work are: project, product, and workstream.


Many companies structure all their work in the form of projects. What they do not realize is that for most companies, about 10-25% of the work of the company fits a project framework. For everything else, the project framework introduces a lot of unnecessary overhead.

First, what is a project? A project has a beginning, middle, and end. A project is completed and there is no work left over. A project is formed to achieve a specific goal or end state. A project has a schedule and budget. The schedule and budget of a project are measured throughout to show the progress of the project. Companies using an Agile methodology for software development (such as Scrum) add a regular measurement of the progress of the actual product being developed to the project metrics.

To run work as a project, you have to define the goal or purpose of the project, estimate the total cost, assign people to work on it, get everyone up to speed (project kickoff), estimate the tasks to be done to achieve the goal, run the project measuring schedule and budget throughout, and finally deliver the results of the work and close down the project.

Work that is “one and done” fits the project model very well. Things such as buying and installing third party software, upgrading all the workstations in the company to the newest version, converting a 40 year old system to new technology, and building a new company cafeteria are all examples of things that fit a project model.

Work that is repetitive and demand driven, or planned and ongoing, does not fit a project model very well. This is for two reasons. First, each repetition of the work requires defining, estimating, setting up and tearing down the project. That is a lot of overhead over time. Second, by dividing the work up into projects, you lose the long term vision of the work and almost always this results in suboptimal short term decisions leading to long term inefficiencies and cost.

Things that are repetitive and demand driven include customer support, setting up a work area for a new employee, releasing a product, or emergency response. These things should have standardized procedures and be managed as workstreams.

Things that are planned and ongoing include adding features or fixing non-critical bugs in an existing product, initiating a new product that you expect to have a lifetime longer than a few months, creating and regularly delivering training, doing competitor research, and any ongoing work that is not demand driven in nature. This kind of work should be organized around products or systems

Products and Systems

Products and systems are things that your company is responsible for maintaining over some lifetime. Systems are inside your company and generally exist to support the work of the employees. Products are things that you provide (or could provide) to customers, partners, or vendors outside your company. The important thing is not whether something is a product or system, but rather is this something that your company has to maintain over time.

Products and systems can be things such as computer hardware, computer software, business processes, training, and reports for a few examples. While products and systems do have a beginning, middle, and end, the lifetime is generally measured in decades, not months. There are products in the market today whose lifetimes are measured in centuries. When managing products and systems, the important measurement is the lifetime cost of ownership. Projects focus on the short term cost, often leading to decisions that make the product or system more expensive to maintain over time. Products and systems should not be maintained as a series of projects; over time that is far too expensive.

To manage work as a product or system, you form a product or system team. This is a small number of people whose job it is to create, maintain, and manage the product or system over time. This could be as small as 2 people (never one – you do not want to depend on one single person knowing the product or system), or for large products being actively maintained you may have 20 or 30 people on the team (or more). The product or system team is responsible for the long term vision of the product or system, the architecture or design of the product or system, the development of the product or system, the maintenance of the product or system, and the release plan for the product or system. The cost of the work is in the size of the team; team members are paid full time to work on the product or system team.

Work comes in continuously in the form of defect reports and feature requests from users, product managers, and company goals and directives. This work is organized into releases by the product or system team. The releases may be monthly or quarterly, or the team may decide on continuous releases, as we see with many mobile apps. The release schedule will be driven by market demand and the ability of the users to consume the changes.

The measurement of success is did we deliver the right product at the right time for the right cost. This will be measured every time a release is made and the team sees how the users react to any new features or fixes.

A lot of “run the company” work is associated with a product, but may not fit as part of the product team. If you are an insurance company and have a life insurance product, then creating actuarial tables is part of creating the product and so the actuary is part of the product team. On the other hand, handling claims is not part of creating or maintaining the life insurance product. It could be considered a product (or service) in its own right, and since it is repetitive and demand driven, it is a better fit for a workstream model.

Alternatively, legal work is often directly associated with a product. For some companies in highly regulated industries, a lawyer should be part of the product team, as well as possibly a compliance officer. For small, stable products these people may not be full time on the product team, but are rather a resource to be called upon as needed.


A workstream is a way of structuring work that is repetitive and on demand. The repetitive work should be described by standard processes and procedures. Work comes into a queue which may be “first come first served” or may have some other prioritization scheme applied. Work is managed by tracking the current work in progress to be sure it is not too large. There are typically service level agreements (SLA) which describe how quickly requests are processed.

The processes and procedures themselves are likely maintained by a system team who creates and maintains the processes and procedures, and maintains the software and systems to support those processes and procedures.

The cost is in the number of people staffed to handle the work in the workstream. People work full time handling the work in the workstream. For many people, the continuous pace of work can be very wearying over time, so rotating people between the workstream and the system team may be a way to balance the work across all the people involved.

Success is measured by the quality of the results, by staying under the work in progress limit, and by meeting or bettering the SLA.

The Common Mistake

When considering a company as a whole, structuring the work in different ways makes sense. The common mistake is to categorize all work within a department or division the same way. We see this often in IT where everything is a project. All the systems, metrics, and reporting are designed around projects. And yet, the emergency bug fix team should be a workstream. There should be product teams for each product. And there will be projects as well. But management wants everything reported the same way on one dashboard, and so we are back to everything is a project. (Why projects instead of products? Because PMI and Business Schools train people to manage projects not products, so management picks what they know as the default.)

By forcing everything to be measured the same way and accounted for the same way using the same systems, we are forcing inefficiency and greater cost into our work. These are not small inefficiencies. The unnecessary costs could be as low as 10%, but for most companies, these additional costs may be 30-50% of the IT budget. Just so we can have everything on one dashboard.

Think about it.

The Myth of Software Complexity

To claim that software is complex and that therefore we must create large teams to manage that complexity (as SAFe asserts (1)) is missing the point entirely. In this article, I’ll examine the fundamental flaw in that perspective and explain what we really need to do to manage software development in the modern world.


Software is complex. I have heard this a lot in my career. It is typically said by either people who do not actually understand software development or by practitioners who want to maintain the mystique of the discipline. Good software engineers know that the best software is a simple as possible.


The statement “software is complex” implies that complexity is a fundamental characteristic of software. This is quite obviously not true. If complexity is a fundamental characteristic of software, then we would not have all these clever iPhone apps being developed by individuals, even children, in time frames measured in days. The vast majority of software running things such as your clock, thermostat, and parts of your car is extremely simple. Even the software running robots is relatively simple. The math is complex, the software is not.


I’m sure the counter argument is, “OK, all software is not complex. But the software running our businesses and systems, that is complex.” If it is true, then that software is almost certainly unnecessarily complex. Think about most business applications. At its most fundamental, you have a user interface, some business rules, and a database. While the business rules may be complex, the software to implement them should not be. There may be a lot of features, but that does not mean the software behind the features is complex. Many is not the same as complex. Large is not the same as complex.


The discipline of software engineering (not coding, engineering) is filled with techniques and practices to remove complexity from software. This is because complexity in software is bad. Complex software is hard to understand, and therefore prone to error, difficult to change, and often full of defects. Good software is as simple as it can be, easy to understand, easy to maintain. Practices such as service oriented architecture, domain specific languages, object oriented design, test first development, refactoring, and minimum viable product all speak to the push away from complexity.


As my buddy Kyle points out, you have to ask the right questions. The question is not “How do we manage the development of complex software”, the question is “How do we remove complexity from our software”? Hint: you do not remove complexity by creating teams of 70-100 people running under the structure of a program (2). The Fluid Approach is based on removing complexity in software by using the eXtreme Programming (XP) practices along with good Voice of the User teams made up of Analysts and UI Designers who are skilled at Solution Anthropology.


I’m sure someone will bring up this argument “OK, software does not need to be complex, but the process of developing software is complex”. My answer to that is it does not need to be. If your software development process is complex, you have made it unnecessarily so. I have worked for extremely large companies creating big software using a very straight forward, simple development process. You really can create large percentage of the software needed today with teams of no more than 20 people with broad skill sets.


If your company has many different programmer roles, tester roles, analyst roles, etc., then you have created an unnecessarily complex process. If you have many layers of people involved in your software projects, then you have made the projects unnecessarily complex. The question is not “How do we manage a complex software development process”, the question is “How do we lean out our software development process”? The Fluid Approach has the answer: cross training, dedication and co-location of the development team with the Voice of the User team, management of the queue, and development of the tribe. These things have been proven to simplify the process of software development.


The question is not “How do we manage complexity”?


The question is “How do we remove unnecessary complexity”?


The Fluid Approach shows you how.


(1) “Our modern world runs on software. In order to keep pace, we practitioners must build increasingly complex and sophisticated software systems. Doing so requires larger teams…” http://scaledagileframework.com/ , Why it Matters, accessed 11 May 2014


(2) “Trains work best with about 50-100 people dedicated to a primary value stream.” http://scaledagileframework.com/agile-release-train, accessed 11 May 2014.

What Metrics Should We Have?

I am sometimes asked “What metrics can we put in place to know that our people are doing a good job?”

They never like my answer. I just want three metrics to start:

1. Are our end users happy?
2. Are our customers (the people paying the bill) happy?
3. Does our team have joy?

They look at me like I am insane.

“That is not nearly enough.” They reply emphatically, “We measure 100s of things. You can’t manage it if your can’t measure it!”

“I agree.” I reply.

“Stop managing and start leading.”

Complexity, Simplified

With additional attention comes additional clarity.

Complexity is the core question, as discussed recently.  But what are the choices?   Turns out there are three basic answers.  One I already discussed, but the other two are better understood in a different way.

How complex is your system?

Is it a simple system?  Handle things with simple answers.  Individual experts, working largely independently, with bucket lists and goal targeting.

Is it a stable system?  Handle things with stability reinforcing answers.  Plan your projects. Manage to the plan.  Work by schedule.  Define processes and tasks.

But what if it’s a changing system?   Then handle things with answers that leverage change. You can’t manage the group, you need to rely on natural social systems (tribes).   You can’t guide with plans, you must use feedback.  You can’t schedule, you have to prioritize.   You can’t define processes and tasks, you have to build ceremonies.

Simple, Stable, or Changing?  That’s your question.  Use the right system for the right problem.

Earned Value Management (EVM) and Agile

Recently I was asked about EVM, specifically CPI and SPI, for Agile projects.  The question stopped me in my tracks because …. it makes no sense.  Why would I collect metrics that estimate my progress when I can prove actual progress by delivering working software every iteration (sprint)? I’ll outline my thoughts in this post to show why EVM makes no sense for Agile.

First, EVM was developed by the US Government in the 1960′s to solve a particular problem. They had many large, multi-year Waterfall projects with outside vendors and no visibility into progress.  Because there was no way to measure how much of the product was complete (Waterfall meant they got everything at the end), if they stayed with Waterfall, the only thing they could measure was the progress of the project.  EVM is based on a fundamental assumption that we can plan everything up front, and therefore if the project progresses as expected, then we will get the product we paid for.

Let me be very clear. EVM treats the project as the deliverable and measures progress of the project.  EVM in no way measures completion of the product, which is what we are actually delivering to the customer.

The fundamental assumption on which EVM is based is (in many cases) not a valid assumption. In many cases we cannot plan all the work up front. Also, we all know of projects that progressed exactly as planned, but the delivered product was a failure. The project succeeded, the product did not.

But let’s be fair. As long as the choice for software development is Waterfall, there really is no other way to measure progress.

Agile gives us a fundamentally different approach. We can still measure plan versus actual, but we measure a different plan against a different actual. We measure the user stories selected for the iteration (sprint) against the actual software we completed. Does the delivered software do what the user stories said it must do? We measure the actual benefit received by real users using the real software against the cost of developing the software. Do the actual benefits match what we expected? Is the cost reasonable compared to the benefit? Should we continue investing in this product?

Agile answers the question the customer really cares about:

Did I receive the right product at the right time for the right cost?

Our customers do not care about how well the project went. They don’t see projects. They see products. They see what the product does, they see what the product costs. They want the product when they need it, not 6 months from now.

I’ll close this by illustrating with a scenario.  I have 2 projects with 10 people each, with an average labor charge of $100 an hour. Each project is expected to cost $1,000,000 and complete in 6 months.

Project 1 is Waterfall. The project plans calls for the requirements phase to be completed after 2 months for a cost of $330,000.

Project 2 is Agile (of some flavor). They are doing 2 week iterations (sprints). Each iteration (sprint) should cost $80,000 if everyone is billing full time to the project. The first two iterations (sprints), the team expects to complete work that has an estimated benefit of $400,000 a year by saving 80 hours a week of labor time on a task performed by 40 people in the company (2 hours per person).

Project 1 completes the requirements phase in 7 weeks for a cost of $280,000. Everyone is happy. We are ahead of schedule and spend, so the project continues.

Project 2 completes the two sprints. The software matches what the user stories described. The team spent $90,000 (they had to call in a specialist to fix a weird problem). The software is given to 10 of the people who will be using it. The users save on average 1 hour per week using the new software. The cost was $90,000, the benefit is only $200,000, but still a good ratio and the users are happy. The new software is released to all 40 users. Based on lessons learned, the team reviews the cost and benefits of the next user stories to see if there is value in continuing.

If I look at EVM for Project 2, we completed what we planned, but we have overspent. The users are already using the software and receiving enough benefit that it was worth the cost. We have this information 1 month into a 6 month project. We can choose whether or not to continue spending money.

EVM for Project 1 looks better. We are on schedule and budget. But we have no idea if we are doing the right thing or if the benefit will be worth the cost. We will not know this for another 4 months. We have no basis for deciding if the cost is worth the benefit or if we should continue spending money.


We’ve run through a couple models of analysis on the nature of Agile/fluid systems.  Specifically, we’ve looked at that Method Grid, and then recently, we were trying to address which question needed asked.  I think we’ve made a breakthrough in our analysis.

Question:  Why is it that Hero and Director are more natural states than Messiah and Wedding Planner?

It seems as if there’s some natural synchronicity between Independent work and Individual responsibility, and also a natural synchronicity between planning and management.

Perhaps calling them out as separate axes is not the right thing to do…maybe there’s a deeper, underlying question, which is being answered in the same way on different axes that leads to this synchronicity.  And once we looked, we did indeed find that to be true.

The new claim:   There is one question at the heart of Agile.  The Agile manifesto gropes blindly for the question, but seems clearly to be looking for it.  The fluid principles are each a manifestation of the Agile question, in a different domain.  What is the question?

Q:  How do you handle complexity?

And at that same deep level, there are three basic paradigmatic responses.

Paradigm 1:  Simplicity.
A:  We don’t.  Our problem isn’t that complex.
Why do startups run in a profoundly different fashion than large companies?  Because their problems aren’t big enough yet.  They’re applying simple solutions (frequently from a brilliant insight) to simple problems.  In applying simple solutions to simple problems, they don’t address complexity at all.  And that’s wonderful.  For the domains that it works in.

Paradigm 2:  Control.  (aka Mechanical, Resisting, Rigid, Structured, Design, Managed)
A:  In the face of complexity, we attempt to control it.
Once problems become difficult enough, the Simplicity paradigm is insufficient to handle the problem.  We design a complexity management system.  More than a couple dozen people in an organization, and the group dynamics need management.  More than a couple dozen modules in your code, and you need to start doing design.  More than a couple dozen weeks in your project, and you need to lay out a plan.  More than a couple priorities, and you need a schedule.  More than a couple risks, and you need a process.   Everyone knows this system, as every large business we’ve seen has followed this mode.

Paradigm 3:  Fluid (aka Biological, Accepting, Organic, Nudge)
A:  In the face of complexity, we travel with it.
At some point after problems become difficult enough that the Simplicity paradigm is insufficient to handle the problem, so too is the Control paradigm unable to handle the complexity of the system.  Nature is complex enough we cannot direct it.  Rather, we need to work with nature, rather than against it.  In the southwest USA, build from brick and adobe to handle the heat.  In California, build flexible, wooden structures to handle the earthquakes.  In Galveston, build on stilts, to handle the Surges.  Nature will not be commanded…but in flowing with nature, we can get some of what we want.

In the face of hundreds of people in an organization, we need to abolish the formal organizational structure that fights nature, and instead allow natural social systems to emerge.  Tribes sit at the 150-person level.  Hunting parties are near 10.  Pairs work together naturally as well.  Natural social systems don’t sit well with authority.

In the face of thousands of components in a system, and fluid requirements, we need to abandon the notion that a design will capture what we need.  Rather, we need test-driven design and an aggressively maintainable system in order to build good enough architectures to survive the natural change cycle.

In the face of hundreds of competing priorities, we need to abolish the formal method of scheduling, and focus instead.  Biological systems like human beings and human organizations have limited bandwidth.  Scheduling 6 things at once doesn’t get 6 things done faster.  Rather, it usually means that at least 5 things get done slower than they would have,  and usually aggressive prioritization/queuing/focus gets 9 things done faster than 6 things in a scheduled fashion.

In the face of innumerable risks, process cannot save us.  We need a better answer.  A natural, flowing with human patterns instead of against them answer.  The answer that gets us there is ceremony.

In the face of more than a couple encounters with changing reality, planning systems crumble under the weight of replanning.  Instead, we need fluid, biological responses to changing conditions.  We need the ur-mechanism for responding to reality.  Feedback systems are the only answer.

There is only one question:

How complex is your problem?

If you have easy problems, a simple paradigm can solve them.
For mildly difficult problems, the control paradigm is standard because it handles them.
But for the actually hard problems, fluid systems are the only answer.

It’s interesting also to consider how many problems fall into the moderately difficult category…and how much overlap there is between the problem-solving capacity of control vs. fluid systems?  How many problems can control solve (well) that fluid can’t?