
Maintenance
Part of Management foundations: a complete practical guide for 2027
Management foundations trends 2027: facts and context
Management foundations tested against whatever is new: the six problems every practice answers, where to look for real change, and how to adopt without a program.
Management ideas arrive in waves, and each wave is presented as a break with everything before it. Most are a rediscovery of one of about six standing problems that have no permanent solution, dressed for the current decade.
That is not a reason to ignore them. It is a reason to have a method, because the cost of adopting the wrong one is not the license fee. It is a year of your team's attention and a set of habits that are hard to reverse.
What to take away
- Ask what problem a practice was invented to solve, then ask whether you have that problem. Most adoption failures are a correct answer applied to the wrong constraint.
- Any claim about what leading organizations do is a claim about a selected sample. The ones that tried the same thing and closed do not publish.
- Adopt the smallest testable piece with a date on it. Whole-method adoption removes your ability to tell which part helped.
The six problems everything is a response to
New management practice is nearly always an attempt on one of these, and knowing which one tells you immediately whether it is aimed at you.
- Coordination cost. Getting a decision made across people who do not report to each other.
- Attention scarcity. More work than anyone can hold in their head, and no agreed order.
- Distance. Deciding about work you cannot see, whether the distance is geographic, hierarchical or technical.
- Measurement distortion. Any measure with consequences attached gets pursued instead of the thing it was standing in for.
- Knowledge concentration. One person holds something nobody else can do, and every fix costs their time.
- Change resistance. People who have watched three previous initiatives arrive and lapse behave rationally toward the fourth.
Read any current practice against that list. If it addresses coordination cost and your actual limit is knowledge concentration, it will produce activity and no improvement, and the failure will be blamed on the rollout.
Testing a claim before you act on it
Four questions, in order. Most claims fail at the second.
Who is the sample? A practice described as widespread among successful teams tells you about the survivors. The teams that adopted the same thing and disappeared were never counted, so the association you are being shown would look the same whether the practice helped, did nothing, or hurt.
Compared with what? An improvement quoted without an alternative is not evidence. Compared with doing nothing, compared with fixing the obvious thing first, compared with the same effort spent elsewhere: these give different answers and only one of them is usually reported.
What context is doing the work? Practices carry hidden requirements: a particular size, a type of work, a level of existing trust, a tolerance for slack. Something that works where people can be pulled off delivery for a week does not transfer to a place where they cannot, and the requirement is rarely stated.
What does it cost to reverse? A change to a meeting is cheap to undo. A change to how people are measured, paid or grouped is not, because it moves what people optimize for, and the old behavior does not return when you withdraw the policy.
Where to look for what is actually changing
Published trend material is written by people who need something to be new this year. More reliable signals are dull and local.
- What your own exception rate is doing. Rising exceptions on a stable process means the world moved and the process has not. That is a genuine trend, in the only sense that affects you.
- What new joiners are surprised by. They arrive with the current normal from somewhere else. Their confusion is free information about how your practice has drifted.
- Which questions reach you repeatedly. A question asked four times is a structural gap, not four incidents.
- What people work around. Any widely used unofficial spreadsheet, side channel or private checklist is a design flaw that has been patched privately. Those patches are where the next official change should come from.
- Where standards bodies and regulators in your own sector have changed their published guidance. Read the source document, on its own site, rather than a summary of it.
The shapes that keep coming back
Without claiming anything about volume or adoption, three arguments recur under new names every few years, and knowing the shape saves you the debate.
Centralize, then decentralize. Consolidation buys consistency and costs local speed. Distribution buys speed and costs consistency. Neither is a solution; each is a correction to the other's accumulated cost, which is why organizations oscillate. The useful question is which cost is currently hurting more.
More measurement, then less. Adding measures makes work visible and distorts it. Removing them restores judgment and hides problems. Both directions are correct at different points, and the trigger is whether your current measures are being gamed or ignored.
More process, then less. After an incident, process is added. After the process becomes slow, it is stripped. The half that should have been kept is the half tied to a risk somebody can still name. The rest is sediment. The distinction between a process, a rule and a decision, set out in operating processes, is what tells them apart.
How to adopt something without a program
If a practice passes the tests, the way in matters more than the choice.
Take the smallest piece that could work on its own and run it in one team for a fixed period, with a date and a stated result that would end it. Do not rename anything, and do not announce a method. Naming an initiative creates a constituency for its survival, which is exactly what stops you from stopping. How a practice actually spreads through a group, as opposed to how it is announced, is the subject of the research on diffusion of innovations.
Change one thing at a time. Two simultaneous changes give you an outcome and no way to attribute it, and the change management cost of both is paid whether or not either helped.
Write down what you expect to see and by when, before you start. After the fact, ambiguous results get read favorably by the people who ran the pilot, and that is not dishonesty, it is ordinary.
Watch for the tool version of adoption. A practice bought as software arrives configured to somebody else's version of it, and the configuration outlasts the enthusiasm. Copying the visible form of something that worked elsewhere while leaving out the mechanism that made it work is the pattern that gave cargo cult its second meaning. There is a fuller treatment of that decision in the tools for management foundations page.
What does not change
The parts of the job that survive every wave are unglamorous and are the reason management foundations is a short list rather than a long one. Somebody has to decide, and hold it when it is unpopular. Somebody has to say the difficult thing early enough for it to be useful. Somebody has to notice the person whose work leaves no trace. No practice removes those, and any that claims to is describing an organization with no scarcity in it.
What genuinely does move over time is the ratio of coordination to production in most jobs, which raises the value of clear boundaries and written decisions, and lowers the value of presence. That is a slow change, and it has been slow for a long time. It does not need a name.
The related question of whether your working methods should change with it belongs to productivity systems, where the same test applies: adopt the smallest piece, and be able to say what would make you drop it.
Common questions
How do I tell a fashion from a real shift?
A fashion answers the question "what should we call what we do?" A real shift changes what is possible or what is cheap. If adopting it requires no change to who decides what, or to how work reaches people, it is probably vocabulary.
Our leadership wants us to adopt something I think is wrong for us. What can I do?
Argue about the problem rather than the practice. Being against a named method sounds like resistance; showing that your binding constraint is elsewhere is a technical argument and much harder to wave off. Then offer the smallest honest pilot, with the result that would change your mind stated in advance.
Is there any harm in trying several things at once?
Yes, and it is the standard error. You lose attribution, you spend the team's tolerance for change all at once, and when the results are mixed nobody can say which part to keep. Sequence them, and let each one finish.



