In the world of management, the ideology of generic, domain-agnostic expertise first made its appearance in the late 19th century under the name of “scientific management”, or “Taylorism” after its godfather Frederick Winslow Taylor. Taylor’s insight was that the same engineering principles used to design a more economical or efficient product could just as well be applied to the shop floor itself. In his view, the workers, overseers, and production processes of a factory all combined to form a great living machine, and that machine could be optimized and made more efficient by an application of scientific attitudes.
Taylor was unpopular in his own day and is even less popular today, because his particular brand of optimization of the great living machine was all about stripping autonomy (or as Marx would say, “control and conscious direction“) from workers. But the particular kind of optimization he advocated is less important than the conceptual breakthrough that while a nail factory and a car factory might look very different on the surface, they are both governed by the same set of abstract laws: laws of time and motion, concurrency, bottlenecks, worker motivation and so on. A master of those laws could optimize a nail factory, and then go on to optimize a car factory, and could do both without knowing very much at all about nails or cars.
Who could have a problem with that? Even I don’t think it’s entirely wrong — I may have misgivings about the sheer volume of people going into fields like management consulting, but I’ll admit that there remains alpha in asking a smart and incisive outsider to take a look at your operation and tell you what seems crazy. The trouble comes with confusing that sporadic, occasional sanity-check with the actual business of leading a team of people who are working together to achieve an objective. Because, get this, it’s impossible to lead such a team without a deep understanding of the details of every person’s tasks.
It’s surreal to me that this point has to be made, yet somehow it does. If the team you lead makes nails, you need to know everything there is to know about making nails. If the team you lead operates a restaurant, you need to be an expert, not in “management”, but in restaurants. If the team you lead sells mortgage-backed derivatives, you better know a heck of a lot about finance in general, mortgages in particular, the art of sales, and the specific world of selling financial instruments. There are a thousand reasons why this is true, but consider just one: a subordinate is failing at a task, and tells you that it isn’t because he’s lazy or unqualified but because the task is unexpectedly difficult. How on earth can a manager evaluate this claim without being able to do the job himself?
There’s another, very different reason managers need to be experts in whatever it is their team is doing, and it has to do with morale. A subordinate in any sort of hierarchical organization needs to see that his superior can do his own job as well or better than he can. Almost everybody gets this. In a high-pressure commercial kitchen, if a chef or sous-chef doesn’t like the performance of one of their line cooks, they will often leap in, take over that cook’s station, and begin “expediting.” This has a dual purpose: it both relieves a genuine production bottleneck, and also acts as a showy demonstration of prowess, reminding everybody that they got to be the boss through excellence. At the better tech companies, those managing software engineers are always former engineers themselves, and often the very best of the lot. Just like a chef would do, an engineering manager needs to be able to seize a computer and begin expediting under pressure, both to solve a real problem and as a dominance display. But it’s not just about keeping the troops in line, it’s about inspiring them. Nothing motivates a soldier like seeing his commander leading the charge, weapon in hand.1
John Psmith, “REVIEW: Scaling People by Claire Hughes Johnson”, Mr. and Mrs. Psmith’s Bookshelf, 2023-08-28.
- This shows up in places you wouldn’t expect to. I was once cast in a show, and quickly came to understand that our director could (and often did) leap onto the stage, snatch a script out of somebody’s hand, and play their part better than they could. For any part. Before he did this to me, I found him annoying and bossy. Afterwards, I would follow him into the Somme.
Update, 7 April: Welcome, Instapundit readers! Have a look around at some of my other posts you may find of interest. I send out a daily summary of posts here through my Substack – https://substack.com/@nicholasrusson that you can subscribe to if you’d like to be informed of new posts in the future.
[…] OR “THE PROBLEM WITH MBAs”: Taylorism. […]
Pingback by Instapundit » Blog Archive » OR “THE PROBLEM WITH MBAs”: Taylorism. — April 7, 2026 @ 01:01
I studied both Taylor and Gilbreth in college as part of the industrial engineering curriculum, and later in real live I studied the Toyota adaptation of many of the methods in their kaizen approach. It does require a detailed knowledge of both process and product to optimize your production, and the entire Toyota Production System relies on people who do know the process and product. It works, and works well, but it requires commitment from management and associates. A partnership, and an open book policy makes it a lot easier for people to understand why it is necessary.
Comment by Tim McDonald — April 7, 2026 @ 07:52
Pure-quill Taylorism is like a textbook interpretation of Marx’s claims about worker alienation … it explicitly tries to reduce the worker to a biological machine. Luddism is the natural human response to a Taylorized workplace.
Comment by Nicholas — April 7, 2026 @ 11:50
As a retired software developer, I take exception to description of the managers of software developers. Yes, they are usually former software developers, but hardly the best of the bunch they’re usually the worst and they recognize that they are and therefore they try to move into another field, namely, managing software developers.
Comment by Chris C — April 7, 2026 @ 09:08
I worked in the software field myself, so I’ve seen many examples of developers promoted because they were really good coders and also many examples of developers promoted because they really weren’t good coders and this was the only way to get them out of the way of the good coders.
Comment by Nicholas — April 7, 2026 @ 11:52
I don’t think a restaurant chef/cook is an analogy for management/managers where the distinction falls on a technical skillset versus managing the enterprise. IOW, the chef who overseas line cooks has advanced past that of merely being a line cook. Managers in a business are, in large part, managers of people, not necessarily technical experts of the tasks performed by the personnel who are managed. A reverse analogy might be apt: the best salesman is not necessarily a good candidate to be a sales manager–the manager of other salespersons. The job tasks involved are different, the necessary skills are different, and the appeal-motivation is different.
In many different occupations there is a great difference in the scope and scale which requires a vastly different perspective on the solution of problems encountered. It’s what’s often called a trees and forest dilemma. Many task-specific personnel can’t see past the detail of the trees to grasp the overall forest.
Comment by Forbes — April 7, 2026 @ 15:15