Some of the most useful ideas in transformation are old enough to have survived several rebrands of transformation. Which is more than I can say for most of the acronyms. And those acronyms have had a difficult few decades!!!
We keep getting extraordinary new tools. Sensors that reveal what was previously invisible. Software that connects entire operations. AI that can produce an answer before you finish explaining why you need it. I find all of that exciting. Then I think about the organization receiving these capabilities, where changing a maintenance schedule might require four approvals and someone who is currently on vacation.
There is quite an expensive gap there! That gap is what interests me about transformation. Technology expands what a business could do. Getting the business to actually do it involves habits, incentives, relationships, and decisions that rarely disappear because a more impressive tool has arrived. People still protect their budgets. Departments still optimize their own results. A customer problem can travel through five inboxes without getting any closer to a solution. And somehow, everyone involved can be having a productive day.
Imagine a manufacturer introducing predictive maintenance. The model correctly identifies an emerging failure. Maintenance receives the alert, but production postpones the intervention because stopping the line would hurt this month's utilization numbers. Purchasing has its own targets, so the replacement part is not available anyway. The machine breaks. At the review meeting, someone asks whether the company needs a better AI model. I would have a few other questions first…
This is why I keep returning to the eight principles in my From Friction to Flow graphic. They give names to patterns that otherwise get buried under project updates and optimistic presentations. More importantly, they encourage us to examine the conditions surrounding the technology. A prediction creates an opportunity to act; somebody still needs the authority, resources, and incentive to take that opportunity. Otherwise, we have invested in knowing about the problem earlier. Useful, perhaps. Slightly less useful if we then watch it happen.
There is serious research behind the importance of that surrounding work. Erik Brynjolfsson, Daniel Rock, and Chad Syverson’s 2021 paper on the Productivity J-Curve explains how technologies such as AI require complementary investments in areas including processes and human capital. Their analysis shows how poorly measured intangible investments can obscure early productivity gains. That gives leaders a reason to examine what capability is being built before judging an investment solely by its immediate financial return. It also raises an uncomfortable budgeting question: did we fund the organizational changes required to make the technology useful?
The software invoice tends to be quite specific. The budget for changing how people work can be considerably more... aspirational. My concern is how easily activity becomes a substitute for progress. We can count deployments, training sessions, connected assets, and dashboards. Those numbers can tell us something. What I want to understand is whether a decision improved, a recurring problem became less frequent, or a customer experienced less frustration. If the answer requires a long explanation of everything we installed, we may still be describing the inputs.
When do the 8 Principles Become Useful?
One encourages connections. Another warns that our communication structures shape what those connections produce. One favors simplicity; another demands enough flexibility to handle reality. Patience matters, but so does proving that something works before expanding it. Focus helps, until the metric defining that focus starts encouraging behavior nobody intended. These tensions are useful. They force us to make choices about the actual work instead of declaring ourselves universally committed to speed, simplicity, collaboration, agility, and whatever else fits on the wall.
Take standardization as an example. I want common definitions, reliable interfaces, and clear responsibilities. I also want someone facing an unfamiliar equipment failure to have options beyond submitting the wrong form correctly. A system can be simple to use and sophisticated underneath. Knowing where to preserve flexibility requires understanding the work closely enough to distinguish needless variation from a difference that actually matters.
One trap I see often is treating a small starting point as evidence of a small ambition. A narrow project can be very demanding about the outcome it proves. Resolve one recurring customer problem all the way through, including the awkward handoffs and exceptions, and you may learn more than you would from launching ten disconnected pilots. The result should teach the organization something it can reuse. Otherwise, the next project inherits the same unanswered questions. I am also wary of how quickly we explain difficulty as resistance to change. Sometimes people are protecting an outdated habit. Sometimes they are protecting the business from a process that looks wonderful until you try using it on a Tuesday. A workaround, an unanswered alert, or an approval queue deserves investigation. What information is missing? Who carries the consequences? Where does responsibility stop?
Those are leadership questions that should be asked! A newer platform may help answer them, but it cannot make the choices for us.
The principles below are a mixture of research findings, mathematical ideas, and practical heuristics. I use them to investigate, with their limitations in mind. No certification required. Thankfully.
1. Amara’s Law
We expect the pilot to change everything by Thursday. When it doesn’t, we begin wondering whether the entire category was overhyped.
Amara’s Law: We tend to overestimate technology’s short-term effects and underestimate its long-term effects.
The transformation implication is uncomfortable because it asks for patience AND discipline. A first application may solve a narrow problem while building data quality, skills, and confidence that enable much larger improvements later. Those foundations deserve attention. They also need evidence. What has become repeatable? What can the next team now do more easily? Time passing is insufficient. A project can spend three years becoming extremely experienced at being a pilot. Keep the long-term ambition, but insist on visible learning along the way.
2. Metcalfe’s Law
Metcalfe’s Law: The classic formulation suggests a network’s potential value grows roughly with the square of its participants.
For a business, the useful question is which connections make valuable action possible. Maintenance information can improve production planning; customer feedback can improve engineering decisions.
The formula offers no guaranteed return on connecting everything. Shared meaning matters. Five systems with five definitions of the same asset can create five versions of confusion. And adding everyone to the email does not automatically create an ecosystem.
3. Ashby’s Law
Headquarters has designed one process. The business has encountered twelve situations.
Now what?
Ashby’s Law of Requisite Variety: Effective regulation needs enough response variety to handle the disturbances that matter.
My organizational translation: people and systems need suitable ways to respond to meaningful differences. A routine request and a major customer disruption should not be trapped in an identical approval queue. Standardize the ordinary cases. Reduce unnecessary variation. Give people clear authority and escalation routes for exceptions. This is how simplicity survives contact with reality without forcing every decision back to the same overwhelmed executive.
4. Goodhart’s Law
Congratulations. Every KPI is green! Unfortunately, the customer would like to speak to someone about the actual experience.
Goodhart’s Law: Making a measure a target can weaken its relationship to the outcome it was meant to represent.
People adapt. Sometimes deliberately, sometimes quite reasonably, and often while following instructions exactly.
Reward tickets closed, and difficult cases become inconvenient.
Reward sales activity, and calendars fill up regardless of whether opportunities advance.
The behavior makes sense when viewed through the reward. That is what makes this principle so uncomfortable: the organization may be getting precisely what it asked for. Before introducing a target, I would ask the team a (slightly) mischievous question: How could we hit this number while making the business worse? Let them answer honestly. Then examine the trade-offs and pair the metric with evidence of the intended outcome. Faster ticket closure looks different when repeat contacts are rising. A busy sales team looks different when conversion is falling. Keep inspecting that relationship; a measure can become less useful as people learn how to optimize it.
5. Gall’s Law
Gall’s Law: Working complex systems generally evolve from simpler systems that already work.
The operative word is work!
A demo that relies on an engineer repairing the data every evening has a hidden dependency. Scaling may require cloning the engineer. Start with a complete, manageable workflow, prove it repeatedly, and expand from there. Include the unglamorous steps after the impressive prediction.
6. Conway’s Law
Picture three departments designing their parts of an integrated customer experience. They have separate budgets, different definitions of success, and occasional meetings to discuss why the other two departments are causing delays. Eventually, the new platform launches. The customer must still explain the same problem three times.
Conway’s Law: The systems organizations design tend to reflect their communication structures.
Melvin Conway articulated it in his 1968 paper. The software may be brand new; the communication gaps have had years of practice. I find this particularly relevant when companies promise seamless experiences. Follow an actual customer request across functions. Notice where context disappears or ownership becomes negotiable. Then bring the people responsible for those handoffs into the design decisions, with a shared outcome and authority to resolve conflicts. Integration needs an organizational design as well as a technical one. Otherwise, we risk giving the customer a much nicer interface to our internal disagreements.
7. Pareto
Pareto Principle: A relatively small share of causes often accounts for a large share of results, as Joseph Juran explained.
The familiar 80/20 ratio is shorthand; inspect your own distribution. Which failure modes account for most downtime? Which handoffs generate most rework? Concentrate effort where it can change the result, while preserving essential safety and compliance obligations. Revisit the priorities as performance improves.
I get suspicious when every opportunity receives equal attention. Sometimes that reflects careful analysis. Sometimes nobody wanted the conversation about what would wait.
8. Hick’s Law
Twenty-seven options. Six tabs. Three contradictory instructions. We have certainly given the employee choices. Sound familiar?
Hick’s Law: In controlled choice tasks, response time generally increases with the information needed to distinguish among alternatives.
Applying that finding to business decisions requires care, but it suggests a useful design question: how much work must someone do before they can choose? Offer relevant next steps, understandable categories, and sensible defaults. Keep exceptions accessible. Ashby asks for enough possible responses; Hick reminds us to make choosing manageable. Both can be true.
None of this requires walking into your next meeting and announcing that everyone has violated the Law of Requisite Variety. Please consider the people who already sat through the quarterly acronym update. Pick one pattern. Ask a better question. Change something specific and see what happens. The tool may be new. The organizational behavior may be painfully familiar. Recognizing it early gives us a chance to spend our transformation budget moving forward, with fewer expensive detours through lessons somebody already learned.
References:
Ashby, W. R. (1956). An introduction to cybernetics. Chapman & Hall. Access source
Brynjolfsson, E., Rock, D., & Syverson, C. (2021). The productivity J-curve: How intangibles complement general purpose technologies. American Economic Journal: Macroeconomics, 13(1), 333–372. https://doi.org/10.1257/mac.20180386
Conway, M. E. (1968, April). How do committees invent? Datamation, 14(4), 28–31. Access source
Gall, J. (1977). Systemantics: How systems work and especially how they fail. Quadrangle/The New York Times Book Company. Access source
Hick, W. E. (1952). On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4(1), 11–26. https://doi.org/10.1080/17470215208416600
Institute for the Future. (2025, November). IFTF ten-year forecast 2025—Urgent futures forecasts. Access source
Juran, J. M. (1974). The non-Pareto principle; mea culpa. Juran Institute. Access source
Metcalfe, B. (2013). Metcalfe’s law after 40 years of Ethernet. Computer, 46(12), 26–31. https://doi.org/10.1109/MC.2013.374
Strathern, M. (1997). “Improving ratings”: Audit in the British university system. European Review, 5(3), 305–321. Access source
