Startups Trust People, Large Enterprises Trust Processes
Thinking about 'organizational trust costs' through the lens of reviews, middle management, and job security
When moving between startup engineering organizations and projects at consulting firms or large enterprises, I sometimes feel that the same word, 'review,' refers to completely different activities.
For example, suppose you are thinking about the design of a certain system.
In a relatively technology-driven startup, the agreement reached with management or the business side is often at the level of 'what we want to achieve with this feature,' 'what kind of user value we are creating,' and 'by when it is needed.' Technical decisions such as the underlying architecture, data models, API design, and implementation methods are largely delegated to the CTO, Tech Lead, Engineering Manager, or individual engineers.
Of course, the degree varies by company, and it is not always the case just because it is a startup. However, at least in mature product development organizations, the boundary between 'what to build' and 'how to build it' is often organized to some extent, and room is provided for experts to make decisions as experts.
When reading the Scrum Guide, this concept is quite explicit. A Scrum Team is self-managing, and while having different accountabilities as Product Owner, Scrum Master, and Developers, they work toward a single Product Goal. In the Sprint Review, they inspect the outcomes with stakeholders, but at the same time, Scrum events are also designed to 'create the necessary transparency and minimize the need for undefined additional meetings.' In other words, the core purpose of Agile and Scrum is not to 'divide business and engineering.' Rather, it is to clarify the interface for where both parties frequently collaborate, how much they decide together, and from what point onward they delegate to experts.
On the other hand, when entering consulting, especially transformation projects or IT projects at large enterprises, the atmosphere is quite different.
Reviewing requirements definitions. Reviewing designs. Reviewing implementation policies. Reviewing test plans. Before those reviews, there are internal reviews for superiors. You fix what was pointed out there, align expectations in advance with the client-side representative, and then take it to a meeting of decision-makers.
From an engineer's perspective, people in quite high positions sometimes get involved in points that one would feel 'should just be decided by experts.'
Moreover, naturally, not everyone is an expert in that domain.
As a result, the team is required to have not only the ability to create the deliverables themselves but also the 'ability to convert those deliverables into a granularity of information that non-expert decision-makers can judge.'
Being technically correct is not enough.
Why that method? What are the other options? What is the business implication of choosing that method? What is the impact on the schedule? What are the risks? Who decides at what point, and what are the assumptions?
Only after organizing all that does it become ready for review.
I used to view this difference quite simply.
Startups are fast. Large enterprises are slow.
Startups are rational. Consulting firms and large enterprises are inefficient due to many meetings and documents.
However, after thinking about it a little, it seems that cannot be explained by that alone.
Rather, the two differ in 'what they trust' within the organization.
Startups bet on people for a significant part.
Large corporations and consultants bet on processes, not people.
When viewed as a difference, reviews, documentation, middle management, meetings, and even employment systems all start to look connected by a single thread.
Trust compresses information
When working in an organization, it is impossible for everyone to understand everything.
This is simply a matter of the volume of information.
A CEO does not need to understand every library used in the product. A CFO does not need to understand Kubernetes cluster design. A head of sales does not need to review database index design.
The same applies in reverse; engineers do not need to understand every detail of the company's financing terms, sales channels, legal issues, or hiring plans.
An organization is essentially built on the premise of "entrusting someone else with what you do not know."
What is important here is trust.
"If that person checked it, it should be fine."
"If we leave it to this team, they will ensure the quality."
"If the CTO has approved it, management does not need to check the code itself."
Such trust is not merely a matter of human relationships.
It is a mechanism for information compression.
Suppose 100 pieces of information are needed to fully understand a certain technical decision. If those 100 pieces are brought up to the CEO, the CEO must also process those 100 pieces.
However, if a trusted CTO can verify it and summarize it as "No problem. This feature can be released as scheduled," then 100 pieces of information can be compressed into a few signals.
This compression is the economy of delegation.
Economist Luis Garicano models organizational hierarchy from the perspective of "how knowledge is distributed and who solves which problems." The front line solves frequent problems themselves, and only difficult problems are escalated to higher-level experts. If all problems were sent to superiors, communication costs would balloon. In other words, hierarchy is not just a system for placing important people at the top, but also a mechanism for dividing labor regarding "who should know what."
From this perspective, one of the things supporting the speed of a startup is not just the small number of people.
It is the high level of information compression through trust.
“I will leave this area to this person.”
With just that, the amount of information that upper management needs to process can be dramatically reduced.
Interestingly, organizational research also includes empirical studies showing that “higher trust makes it easier to decentralize decision-making.” Bloom et al. used corporate data from multiple countries to report that in high-trust environments, companies tend to delegate more decision-making to the front lines. While one must be cautious about causality, the intuition that “trust enables decentralization” is not merely a spiritual argument from the startup industry.
In other words, trust might be like cash within an organization.
Once the assessment that “this person’s judgment is reliable” is accumulated, there is no longer a need to recalculate everything for every subsequent decision.
A fast organization is sometimes more accurately described not as one with high decision-making ability, but as “an organization with many areas that do not require re-verification.”
Engineering organizations have a path to “advance while remaining a specialist.”
Here, I would like to consider the differences in career structures between consultants and engineers.
In engineering organizations, at least in tech companies, there is a relatively clear career ladder for advancing while deepening expertise as an Individual Contributor, or so-called IC.
Looking just at GitLab’s publicly available career framework, there are IC levels such as Staff, Senior Staff, and Principal beyond Senior Engineer, while a separate career path for Engineering Management exists. In other words, it is not a single path where “if you want to get promoted, you must manage people.”
Of course, once you become a Staff Engineer or Principal Engineer, you are not purely writing code. Cross-organizational technical judgment, mentoring, technical strategy, and coordination with stakeholders increase. Even so, the legitimacy of a career path that “advances based on expertise” is maintained.
The typical consulting career is a bit different.
For example, looking at current job descriptions at McKinsey, an Associate has their own workstream. When one becomes an Engagement Manager, they take on the direction of the entire project, daily execution management, and team mentoring. An Associate Partner is responsible for the delivery of multiple projects while developing new client opportunities, and as a Partner, one is responsible for major client relationships and the firm’s growth as an advisor to management. The structure where the focus of work shifts from “someone who analyzes themselves” to “someone who moves people, clients, projects, and revenue” as one rises in rank is also reflected in official role descriptions.
Of course, this does not mean that “senior consultants lack expertise.”
In reality, many Partners possess strong industry or functional knowledge, and some firms have separate tracks for specialized roles such as technology, data science, and design. Therefore, generalizing that “consultants all become managers before they acquire expertise” is too crude.
Even so, there is a tendency for the profession of generalist consultant to shift its weight toward management, client relations, and sales as one rises in rank.
Then, something interesting happens.
The younger staff on the front lines have the latest, detailed information on specific, narrow issues.
On the other hand, those in higher positions with decision-making authority do not follow those issues down to the details.
However, it is the person in the higher position who makes the decision.
In this structure, even if you pass on field expertise directly to the top, decisions cannot be made.
That is where 'translation' becomes necessary.
Translating technical theory into management theory.
Translating specifications into risks.
Translating complexity into options.
Compressing detailed facts into a single slide.
The skills often mentioned in consulting—such as 'taking the other party's perspective,' 'thinking about what your boss cares about,' and 'breaking things down into a granularity that the client can decide on'—are not necessary simply because it is a customer service industry.
In organizations where those who possess knowledge and those who hold decision-making power are separated, these skills become structurally necessary.
Startups can tolerate 'black boxes'.
When looking at engineering organizations, one begins to have a slightly different impression of the term 'black box'.
Generally, black boxes are spoken of as something bad.
The contents are invisible.
It is dependent on specific individuals.
You don't know what is going on inside.
However, professional division of labor is essentially a form of black-boxing.
People who use an API do not need to know the internal implementation.
People who use cloud services do not need to know the wiring of the data center.
People who ride airplanes do not need to understand the combustion control of jet engines.
Even without knowing the internals, you can use it if you can trust the interface, the SLA, and the output.
Organizations are the same.
The business side does not need to know everything inside the Engineering Team.
What is needed is to understand "what can be requested," "what kind of results will be returned," and "with what degree of probability promises will be kept."
Therefore, in mature professional organizations, clarifying boundaries becomes more important than making the internal workings transparent.
In organizations where this works well, management does not monitor engineering in detail.
This is because it functions as expected without monitoring.
Experts such as the CTO, VP of Engineering, and Tech Lead guarantee internal quality, and only the information necessary for the business is escalated to the management side.
Here, the black box functions not as "concealment" but as "abstraction."
Just like abstraction in software engineering, preventing internal complexity from leaking outward is itself a form of design quality.
From this perspective, the value of a strong CTO is not "making every technical decision themselves."
It lies in creating a state where management can operate the company without knowing the internal technical details.
In other words, the CTO themselves is a massive abstraction layer.
Consulting is close to "organizational zero trust"
Here, I will use a slightly rough but useful metaphor.
If startups are trust-based, consulting and large enterprise projects are close to "organizational zero trust."
Of course, this does not refer to Zero Trust Architecture in cybersecurity itself.
Zero Trust as defined by NIST is a security philosophy that does not implicitly trust users, assets, or resources just because they are inside the network, but instead judges access based on them. Therefore, saying "a company with many meetings = zero trust" is not accurate as a technical term. I am using it here strictly as a metaphor.
Even so, there are similarities.
In startups,
"If that person says it's OK, then it's OK"
is a form of trust inheritance that occurs easily.
On the other hand, in large corporations,
"Who gave the approval?"
is not where it ends.
Why is it okay?
From what perspective was it verified?
Were alternatives considered?
What are the risks?
What happens if the premises change?
Can a third party explain that decision later?
These things are documented in materials and meeting minutes.
It is not so much about losing trust in people, but rather "not allowing decisions to be based solely on trust in people."
This is the key point.
It is not because Person A is excellent, but to ensure that even if Person A resigns, transfers, or fails, the situation remains explainable.
As a result, decision-making shifts from the individual to the process.
In this world, PowerPoint presentations, meeting minutes, decision logs, issue tracking sheets, and review records are not just "documents."
They are the organization's audit logs.
They are logs for reproducing why that decision was made.
In engineering terms, it is increasing observability.
Just as you cannot analyze a failure if you do not know how the system internals operated, you cannot explain what happened when a problem arises if you do not know who decided what and on what basis within the organization.
That is why we keep logs.
The cost of logging that is meetings and document creation.
When you think of it that way, a certain rationality becomes visible in those massive amounts of documentation.
A consensus-based system is slow, but it distributes responsibility.
In a startup, a single strong decision-maker can make the call.
We do it because the CEO said so.
We move forward because the CTO decided to go with this architecture.
We build it because the Product Manager decided to prioritize this feature.
It is fast.
However, naturally, the impact when they get it wrong is also significant.
This is because the entire organization is leveraging that person's judgment ability.
While decentralization through trust has the major benefit of speed, it carries the risk of 'loss when you choose the wrong person to trust'.
Large-company style reviews are the opposite.
Decisions are passed through multiple people.
Legal also reviews it.
Security also reviews it.
The business manager also reviews it.
The IT department also reviews it.
In some cases, it even goes through an executive meeting.
Looking at each step, it is slow.
However, the probability of a massive failure occurring due to one person's arbitrary decision can be lowered.
Also, because a history of decision-making is maintained, it is easier to explain "why it was done that way" later on.
There is also a somewhat raw effect here: the distribution of responsibility.
Decisions made by consensus are harder to pin on any one individual than decisions made arbitrarily by a single person.
This can simply be called "evading responsibility."
However, from another perspective, it can be seen as fault tolerance to ensure that a massive organization is not destroyed by a single person's error in judgment.
Even in distributed systems, redundancy is incorporated to eliminate single points of failure.
Redundancy looks like waste during normal operations.
If one server is enough, but you install two, the cost simply increases.
However, if you want to keep the system running even if one server goes down, that waste becomes necessary.
An organization's consensus system is, in a sense, the same.
If nothing goes wrong, half of the review participants might seem unnecessary.
But the moment you set the goal of "not relying on one person for important decisions," that redundancy gains meaning.
What large enterprises are buying might not be "speed," but "a reduction in the probability of failure."
Here, it is better to break down the assessment that "large enterprises are inefficient."
This is because if what is being optimized is different, the meaning of efficiency also changes.
For a startup, what is the greatest risk?
Typically, it would be running out of funds, failing to capture the market, failing to reach Product-Market Fit, or falling behind competitors.
In other words, the very fact that "time passes without anything happening" can be a fatal wound.
That is why speed has high value.
Learn quickly, even if you make some mistakes.
If you make a mistake, you revert it.
You change the person in charge.
You scrap the product.
Sometimes, the company itself ceases to exist.
In this environment, it is rational to maximize decision-making speed based on the premise of high reversibility.
The situation is different in large corporations.
They hold numerous existing assets and stakeholders, such as services that have been running for decades, a massive customer base, regulatory compliance, legacy systems, business partners, brands, employees, labor unions, audits, and shareholders.
Failure there cannot always be dismissed as just a 'feature that missed the mark'.
I do not mean to say that large corporations should always be cautious.
In reality, there is also a great deal of over-control.
However, if you compare only the decision-making costs and conclude that 'startups are more rational,' you overlook the differences in the assets being protected.
Startups are organizations primarily focused on capturing upside, while large corporations are organizations that capture upside while also managing massive downside.
It is highly likely that this difference is reflected in the density of reviews.
However, reviews are subject to a 'translation tax'.
Up to this point, I have written about the rationality of large-corporate processes.
Even so, the hassle felt on the front lines does not disappear.
This is because when non-experts participate in specialized decision-making, translation costs are inevitably incurred.
If it were between engineers,
'Since this method results in eventual consistency, let's ensure idempotency here so it can be re-executed'
would be enough to settle the matter.
However, when explaining this to management,
You need to translate it into something like, "There is a possibility that data reflection timing may be temporarily offset. However, by designing the process to be safely re-executable, we will limit the impact on users."
or something similar.
Furthermore, if it is necessary for management decisions,
You should take it to the point of saying, "Prioritizing strong consistency will increase development time by approximately X. On the other hand, in this use case, the impact of a few seconds of delay on sales is limited, so we will prioritize availability and development speed this time."
and present it in that form.
It is not just a matter of reducing technical information.
It is necessary to project it into the variables required for decision-making.
This is a highly sophisticated task.
And if this translation is poor, superiors cannot make decisions.
Because they cannot make decisions, the number of questions increases.
Because the number of questions increases, the amount of documentation increases.
Because the amount of documentation increases, the number of pre-reviews increases.
As a result, the front line is chased by "explanations for the sake of explanations."
This is where the significant communication cost of large enterprise projects lies.
Even in Garicano's knowledge hierarchy model, there is a cost to communicating problems to those with knowledge. In organizational studies by Bloom et al., whether to decentralize or escalate decision-making to the center is depicted as a trade-off between "what the front line knows" and "the cost of asking superiors."
In other words, "explaining everything to the boss" is not free.
Rather, it becomes more expensive as the organization grows larger.
That is where middle management becomes an "API Gateway."
When the distance between technology and business becomes too wide, they can no longer communicate directly.
To be precise, they can have conversations, but their contexts are so different that there is not enough bandwidth.
The technical side knows too much about the details.
The management side looks at the business as a whole.
Both are busy.
Connecting these two directly requires a massive context exchange every time.
That is where someone steps in between.
Project Manager.
Engineering Manager.
PMO.
Consultant.
Department Manager.
Section Manager.
These people are often criticized for "not building anything."
They don't write code.
They don't do sales.
They don't make products.
They only do documents and meetings.
However, when you view an organization as an information system, they look like something else.
They are an API Gateway.
They aggregate the massive amount of technical information coming up from the field and convert it into a format that management can understand.
Break down high-level abstract demands coming down from management—such as "we want more growth," "we want to lower risk," or "we want to get this done within the year"—into granular, actionable tasks for the front line.
Translate terminology between different departments.
Adjust priorities.
Handle errors.
Route tasks to the necessary parties.
They are, quite literally, a gateway.
Furthermore, this role is recognized as having a certain significance in research as well.
In Ikujiro Nonaka's theory of knowledge creation, the concept of "middle-up-down management" is presented, where middle managers are positioned between top management and the front line, treated as entities that facilitate knowledge creation while bridging the gap in perception between the two. Subsequent research also discusses the role of middle managers in grasping and resolving the gaps that exist between the interactions of top management and the front line.
Therefore, it is not the case that "middle management is entirely useless."
Rather, the worse the interface design within an organization, the higher the value of the translation layer known as middle management.
The problem starts there.
Does the translation layer exist because it is necessary?
Or does the organization become complex based on the assumption that the translation layer exists?
In long-standing large corporations, this causal relationship is not easily understood.
In Japanese companies, it is difficult to "eliminate work before eliminating people"
I would like to enter the topic of employment from here.
When considering this theme, one is tempted to say, "Japanese large corporations are inefficient because they cannot fire people."
However, one should be a bit more cautious about this as a matter of fact.
According to the 2026 OECD Employment Outlook, the strictness of Employment Protection Legislation for regular workers in Japan is at a level slightly below the OECD average. Therefore, the explanation that "Japan has exceptionally strict dismissal regulations compared to the rest of the world" is not accurate.
On the other hand, Article 16 of Japan's Labor Contract Act stipulates that a dismissal that lacks objectively reasonable grounds and is not considered appropriate under generally accepted social norms is invalid as an abuse of rights. This is also clearly stated in the Ministry of Health, Labour and Welfare's working conditions handbook.
Furthermore, beyond just the laws, Japanese companies have a history of long-term employment and membership-based employment.
Keiichiro Hamaguchi of JILPT contrasts the job-based model as a "system where a job exists first, and a suitable person is placed into it," with the Japanese membership-based model as a "system where a person exists first, and work is assigned to that person." In the latter, the company holds strong personnel authority, including the right to reassign employees, and individuals are not tied one-to-one to specific jobs.
This point aligns very well with the theme of this discussion.
To simplify the job-based philosophy to an extreme,
"Because this work is necessary, we will place someone who can do this work."
is the approach.
It is also highly compatible with the idea that if the work disappears, the position itself disappears.
On the other hand, in the membership-based model,
"Since this person is a member of the company, we will think about what work to have them do."
is the typical order of operations.
Consequently, if the business environment changes and the value of a certain job decreases, the problem of "what to do with that person" remains.
Transfer them to another department.
Create a new role.
Assign them administrative tasks.
Give them a project.
If the organization is to retain people internally, it must continue to redistribute work.
Here, we approach the original hypothesis that "useless work is created to protect employment."
However, there is insufficient data to definitively conclude a causal relationship.
At the very least, within the scope of my research for this piece, I could not find any studies that directly prove that "the massive amount of reviews and PMOs in Japanese companies are generated for the purpose of maintaining employment."
Therefore, everything from this point forward is a hypothesis, not a fact.
However, there is institutional consistency.
Organizations that cannot exit create internal adjustment markets.
In organizations that do not easily let people leave, environmental changes must be absorbed internally.
Work changes.
Technology changes.
Required skills change.
Businesses shrink.
If the organization still retains people, it adjusts through reassignment, retraining, role changes, and transitions to administrative tasks.
This is also an important benefit for workers.
The possibility of losing one's job immediately just because one company project fails is reduced.
The company can also cultivate company-specific knowledge over a long period.
It can accumulate abilities that are difficult to price in the job market, such as tacit knowledge between departments and customer relationships.
On the other hand, there are costs.
If it is difficult to move people outside, a mechanism to continuously match people and work internally is required.
This is where human resources systems, transfers, meetings, and managers exist.
And as the organization grows, just coordinating 'who can do what,' 'where should someone be placed,' and 'which department decides what' becomes a huge job.
Economically speaking, it can be thought of as replacing some of the price adjustments and matching that were done in the external labor market with internal management mechanisms.
In other words, employment stability is not free.
Part of that cost is paid not in unemployment rates or salaries, but in the less visible form of 'internal coordination'.
Only here can we see document creation and middle management from a different angle.
They are not merely redundant personnel.
They might be a coordination layer that has become necessary to keep re-wiring complex organizations internally without letting people go.
Is the "waste" in large corporations a form of insurance premium?
When viewed this way, the meaning of things that seem wasteful in large corporations changes.
Massive amounts of reviews.
Multi-stage approvals.
Detailed division of duties.
Middle management.
PMO.
Explanatory materials.
Meetings.
Each of these looks like a target for reduction when viewed individually.
However, for the organization as a whole, they may be creating qualities such as "not breaking due to one person's error," "continuing to function even if the person in charge leaves," "being able to reassign people without having to fire them easily," and "being able to explain things when problems occur."
If so, this is insurance rather than inefficiency.
Insurance looks like a waste when no accidents have occurred.
If you pay insurance premiums every month and nothing happens, that money is not used as a result.
However, it is strange to evaluate insurance as "waste because nothing happened."
What is important is how much you are paying for which risks.
The governance costs of large corporations might be the same.
The problem is not that "there are reviews."
The problem is that it is unclear which risks are actually being reduced by the reviews.
Reviews that cannot explain that are highly likely to be truly wasteful.
However, it does not necessarily mean that "many reviews" equals "wasteful."
I think this distinction is quite important.
Startups also suffer from the same disease as they grow.
Reading this far, it might look like a binary opposition between startups and large enterprises.
But in reality, I think this is more of an issue of organizational size and the cost of failure than company type.
As startups grow, management layers increase.
Security audits increase.
Legal reviews increase.
Approval flows increase.
Internal systems increase.
Complaints like "In the old days, we could just ask the CEO on Slack and it would be decided" start to emerge.
This is not just because the company has become corrupt.
It is because as the number of people, customers, and assets to protect increases, it becomes necessary to define who is allowed to decide what.
In organizational research as well, decentralization and hierarchy within a company are treated as a trade-off between knowledge distribution and communication costs. In larger organizations, the method of "everyone talking directly to everyone else" does not work.
Therefore, eventually, processes are introduced into startups as well.
Conversely, if large enterprises continue excessive centralization, they become too slow, so they try to create small autonomous teams by introducing delegation, product-based organization, Agile, and DevOps.
The two are not different species.
As a company grows, it gradually shifts from a trust model to a process model.
And when the process becomes too heavy, they try to partially reintroduce a trust model.
Organizations swing back and forth like a pendulum.
And consultants make a living out of that 'friction'.
Here, I would like to pose a slightly provocative question.
For whom is the complexity of large corporations valuable?
For the companies themselves, they naturally want to reduce it.
They want to simplify the organization.
They want to speed up decision-making.
They want to undergo digital transformation.
They want to reform their business operations.
They want to integrate their systems.
They want to eliminate redundant tasks.
They want to improve governance.
Then, work is created to organize that complexity.
Visualize current operations.
Organize stakeholders.
Design the 'To-Be' process.
Create a roadmap.
Establish a PMO.
Design decision-making meetings.
Perform change management.
A significant portion of this work is handled by consulting firms.
There is an irony here.
Consultants are needed because large corporations are complex.
The involvement of consultants can sometimes lead to even more meetings, documentation, and management processes to handle that complexity.
As a result, 'complexity to resolve complexity' is created.
Of course, it would be reckless to say that consultants are the ones creating the complexity.
Large-scale transformations sometimes require external expertise or temporary execution capacity, and there is work that can only be advanced by a third party distanced from internal politics.
However, one can view a part of the consulting industry as a 'service that handles the coordination costs within a massive organization from the outside'.
Consultants sell knowledge to companies.
At the same time, they sell 'translation' that arises from the separation of knowledge and decision-making authority within the company.
PowerPoint is not the product.
Translated decision-making potential is the product.
Thinking of it this way, the reason why consultants are required to have an extraordinary 'boss perspective' or 'client perspective' becomes clear.
Their job is not just to be experts.
It is because they connect different professional worlds.
Then, 'employment stability' and 'consulting value' are in surprisingly close proximity.
Connecting these points brings us back to the original question.
In Japanese-style large corporations, membership-based employment, where people are not tied to specific jobs but are assigned long-term within the company, has historically been strong. As organized by JILPT, it is a structure where 'people come first,' not 'jobs come first'.
Retain people for a long time.
Then, it becomes necessary to absorb environmental changes through internal reallocation.
As internal reallocation increases, the organizational structure becomes complex.
As it becomes complex, interdepartmental coordination increases.
As interdepartmental coordination increases, translators and managers become necessary.
As management layers increase, more documents and meetings are required to push through decision-making.
Even then, when transformation becomes necessary, external consultants are brought in to organize that complexity.
Regardless of how empirically valid this causal chain is, it is quite an interesting organizational hypothesis.
In other words,
employment stability and consulting demand may not be opposites, but rather two sides of the same organizational structure.
Organizations that do not easily lay off people maintain complex internal markets to keep utilizing them.
When the coordination costs of those internal markets rise, they purchase external coordination capabilities in the form of consulting.
To put it a bit provocatively,
part of the organizational friction created by employment stability in large corporations supports the consulting market.
That is what it comes down to.
However, this is currently just a hypothesis and has not proven a direct causal relationship.
And, reality is probably more complex.
Some companies have many reviews because they are in regulated industries.
Some companies have heavy governance because the risk of major accidents is high.
Some companies simply have management that does not trust the front lines.
Some companies have seen approval flows increase due to past accidents, and no one has been able to remove them since.
Sometimes, the number of managers increases due to organizational politics, regardless of hiring needs.
Therefore, one should not explain 'waste in large corporations' solely as a 'job retention mechanism'.
Even so, I think it is certain that including the employment system as one of the variables makes it easier to explain some of the strange behaviors of large corporations.
Instead of saying 'eliminate waste,' think about 'what kind of risk are we buying?'
When looking at large corporations from a startup perspective, there are truly many things that make you think, 'Isn't this unnecessary?'
I don't think that feeling itself is wrong.
In fact, there are documents that no one reads.
There are reviews that do not influence decision-making.
There are approval flows where the approver makes no judgment at all.
There are meetings where the only purpose is to hold the meeting.
There is a massive amount of genuine waste within organizations.
However, recently I have come to think that dismissing it all as 'large corporation disease' is also not quite right.
Startups are fast not just because they are talented.
They are fast because they can afford to fail.
They are fast because they can bet on people.
Because the company is small, the amount of information is low.
Everyone can remember who decided what.
If necessary, those in charge can be replaced.
In the worst case, the company itself ceases to exist.
That instability and speed are a set.
The slowness of large corporations is the same.
They have much to protect.
They retain people for a long time.
They need to explain past decision-making.
They cannot bet the company on a single genius.
That is why they create processes.
They review.
They record.
They deliberate.
They pay the cost for that.
Perhaps these two are not so much a difference between a 'rational company' and an 'irrational company,' but rather a difference in what they are paying insurance premiums for.
Startups pay the cost in arrears by being able to replace failed organizations or people.
Large corporations pay the cost in advance through reviews and governance before failure occurs.
To put it extremely, that is the difference.
Even so, I prefer trust-based organizations.
I have defended the rationality of large corporations quite a bit up to this point.
Even so, personally, I still feel more comfortable in an organization that operates on a trust basis.
I want to leave things to experts as experts.
I do not think everyone needs to understand everything.
As long as the interface is properly defined, the internal implementation can be a black box.
If you can trust the CTO, the entire management team does not need to review the technical design.
If you can trust the engineers, they do not need to explain 'why this implementation was chosen' in a PowerPoint presentation every time.
Trust is fast.
And above all, it makes it easier for people to work as professionals.
However, that speed is not free.
If the person you trusted makes a mistake, you must also accept the loss.
True delegation cannot exist in an organization that cannot say, 'It was my fault for leaving it to that person.'
Organizations that hand over authority but then hold people accountable for every detail when they fail are trying to have both the speed of a trust-based model and the security of a zero-trust model.
Perhaps that is what works the least well.
There are trade-offs in organizational design.
If you want speed, you must accept delegation and failure.
If you want to minimize failure, you must pay the cost of verification.
If you want to stabilize employment, you must pay the adjustment costs to reassign people internally.
If you want to advance professional specialization, you must trust the experts.
And if you don't want to trust anyone, you must create a massive amount of processes instead.
In the end, when thinking about whether a company has 'waste,' I don't think the only question you should really ask is,
'Is this work necessary?'
That is not all.
'When this work is eliminated, who will take on which risks?'
You must think that far as well.
Only after thinking through it to that extent can you tell whether it is a waste or an insurance policy.
Startups trust people.
Large corporations trust processes.
Of course, real-world companies exist somewhere in between.
And perhaps a good organization is not one that chooses one over the other.
They boldly use black boxes in areas where experts can be trusted, while implementing verifiable processes for irreversible decisions that could potentially destroy the company.
In other words, I think it is an organization that can consciously design 'where to trust and where to verify.'
The feeling of thinking 'this review is such a hassle' while attending meetings at a large corporation will probably never go away.
However, I have started to look at that hassle with a slightly different perspective than before.
It might not just be simple inefficiency, but rather the manifestation of the design philosophy regarding how an organization distributes the four risks of employment, responsibility, expertise, and failure.
And the more complex that design becomes, the more it requires people to interpret, translate, and set it in motion.
A part of that work is what we call 'consulting.'
If that is the case, the value generated by consulting is not just the corporate challenges themselves.
Could it be that the friction caused by companies not easily discarding people and attempting to maintain massive organizations for decades is also a source of value for consulting?
When I think about that, 'employment stability' and 'consulting,' which at first glance seem like completely separate topics, start to feel like they are actually connected quite closely.
The 'Startups = Trust, Large Corporations/Consulting = Zero Trust' framework in this article is a metaphor for understanding organizations and is not an empirical classification that applies to all companies. Furthermore, the part about 'employment stability increasing organizational friction, with some of that leading to consulting demand' is not directly proven as a causal relationship by the research referenced here, but is a hypothesis connecting employment system theory, organizational economics, and practical experience. On the other hand, regarding the characteristics of Japanese membership-based employment, legal systems concerning dismissal, the relationship between trust and decentralization, communication costs in knowledge hierarchies, and the career structures of engineers and consultants, I have referenced research from JILPT, the Ministry of Health, Labour and Welfare, the OECD, the Scrum Guide, NIST, McKinsey, GitLab, and organizational economics.