Corporate Infantilization

"Hey Riddler: How DID you make those disciplined teams?"

That’s impossible. So, I didn’t. I only gave them a chance to make themselves.

The term "infantilization" is widely used in politics, organization development, and family therapy. In political science, the references are to dictatorships where people don’t even attempt to control their own destiny. For example, russian social contract with their people: stay out of our way and your life won’t get worse. So, when it DOES get worse, people can’t explain why their Wildberries inventory is on fire — very few connect it to russia’s invasion of Ukraine in 2014. Similarly, in some middle class American families where one spouse doesn’t work, the couple lose connection with one another, eventually living in different contexts. And finally in workplace when a company has a very hard time restructuring stagnant practices to survive. The mechanism is the same in all three: someone else absorbs your agency, quietly, until you stop exercising it — and then nobody remembers whose it was.

That workplace variant has a name. Corporate Infantilization: treating competent employees as if they lack autonomy or maturity — micromanagement, permission-seeking for basic needs, gamification and corporate swag masking structural issues. A parent-child dynamic that stagnates innovation and erodes trust, even as the organization claims to value intellectual capital.

Most importantly, the workplace example seldom manifests itself in vivid immediately obvious ways. Here is a great example — I was asked:

"You get too much data in your React single page application. How to load it?"

The person really DOES attempt to handle the loading. And the thought that this scenario is manifestation of Corporate IT Discipline Failure is not immediately obvious. For one, there are tricks in modern day React that can help with large DOM. But that is not offered to solve "too much data" scenario by React — the scenario is always wrong from the architectural domain.
React offers better functionality to improve its limitations and service levels — different reason.

The real root cause is engineering discipline failure. And it manifests itself as an architectural mistake allowed to stand. While such things are easily fixed by an intermediate service — that service doesn’t remedy the root cause thus "this problem will keep happening."
Someone told me yesterday:

"But there are legacy services that we cannot change sending too much data."

Yes, common indeed. But still the same discipline problem.
A mature team has core values as follows:

1. You touch it — you own it;

2. Leave it better than you found it;

3. And, "it’s never someone else’s fault."

Here is a little bit of what can be done if you are a UX engineer.

Figure 1. If your React Read Model can’t hoot, as this Owl can’t — it’s not the Owl’s fault.

 

Architecture Tells All!

So, how does ONE architecture quirk expose the entire place culture?

Well, this has to do with what "Architecture" really is:
It’s a STORY well-told and narrated to explain THE PLACE to all!

Take a look at the story a rising unicorn tells itself:

Competent Diagram: See Vulnerability Story (ArchiMate® 3.2)

%%{init: {'themeVariables': {'edgeLabelBackground': '#FFFDE7'}}}%%
graph TB

    subgraph Business ["Business Layer"]
        BusinessProcess["Business Process:
 Vulnerability Information
ACCESS"]
        BusinessActor["Business Actor:
 Vulnerability Scan
 Customer"]

        BusinessServiceVulnerabilitiesInformationService["Business Service:
 Software Vulnerabilities
View Provider"]

        subgraph BusinessImpact ["Cost of Vulnerability"]
            BusinessObjectVulnerability["Business Object:
 Vulnerability Information"]
            BusinessRepresentation["Business Representation:
 Incurred Vulnerability
IMPACT"]
            BusinessRepresentation -.->| Realization | BusinessObjectVulnerability
        end

    end

    subgraph Application ["Application Layer"]

        ReadModel["Read Model
Presented Projection
(In Full - Always)"]
        Vulnerability["Vulnerability Object
Instance Of"]
        VulnerabilityCollection["Vulnerability Aggregation
Behavior-Specific
Command Response"]
        VulnerabilityService["Vulnerability Aggregate Service
"]
    end

    subgraph ApplicationACL["Application Layer
Anti-corruption"]
        VulnerabilityACLService["Vulnerability ACL
Service"]
    end

    subgraph ApplicationExternalSystem["Application Layer
External System"]
        VulnerabilityDataService["Database
Service"]
    end


    VulnerabilityService -.->| Access RW | Vulnerability
    Vulnerability --o| Aggregation | VulnerabilityCollection
    VulnerabilityService -.->| Access W | ReadModel

    VulnerabilityDataService -->| Serving | VulnerabilityACLService
    VulnerabilityACLService -->| Serving | VulnerabilityService

    BusinessServiceVulnerabilitiesInformationService -->| Serving | BusinessActor
    BusinessServiceVulnerabilitiesInformationService -.->| Access-R | BusinessObjectVulnerability
    ReadModel -.->| Realization | BusinessServiceVulnerabilitiesInformationService

    CurrentTask["🎯 CURRENT TASK:
Serve the customer
a shaped view"]
    CurrentTask -.- ReadModel
    CurrentTask -.- BusinessServiceVulnerabilitiesInformationService

    classDef BusinessStyle fill:#FFFDE780,stroke:orange,stroke-width:2px,color:black
    classDef BusinessComponentStyle fill:#FFECB3E6,stroke:orange,stroke-width:4px,color:black

    class Business,BusinessImpact BusinessStyle
    class BusinessProcess,BusinessActor,BusinessObjectVulnerability,BusinessRepresentation BusinessComponentStyle

    classDef ApplicationStyle fill:#E3F2FD80,stroke:#1565C0,stroke-width:2px,color:black
    classDef ApplicationComponentStyle fill:#BBDEFBE6,stroke:#1565C0,stroke-width:4px,color:black
    classDef ACLStyle fill:#ECEFF180,stroke:#546E7A,stroke-width:2px,color:black
    classDef ExternalStyle fill:#ECEFF180,stroke:#546E7A,stroke-width:2px,stroke-dasharray:6 4,color:black

    class Application ApplicationStyle
    class Vulnerability,VulnerabilityCollection,VulnerabilityService ApplicationComponentStyle

    classDef TaskCallout fill:#E8F5E9CC,stroke:#2E7D32,stroke-width:3px,color:black
    classDef TaskBlue fill:#BBDEFBE6,stroke:#2E7D32,stroke-width:5px,color:black
    classDef TaskYellow fill:#FFECB3E6,stroke:#2E7D32,stroke-width:5px,color:black
    class CurrentTask TaskCallout
    class ReadModel TaskBlue
    class BusinessServiceVulnerabilitiesInformationService TaskYellow
    class ApplicationACL,VulnerabilityACLService ACLStyle
    class ApplicationExternalSystem,VulnerabilityDataService ExternalStyle

    linkStyle default stroke:black,stroke-width:2px,color:black

What is TOLD in this Adult architecture story:
The Aggregate owns the behavior, including the value concern for the effect the Read Model has on the actor (the user). That effect is the only thing that matters — value comes from changing the state of the user. And the Read Model we implement right now has one and only one job — faithfully, and accurately, represent aggregate’s behavior: its defined data produces expected influence on the actor! Obviously, the Read Model does no thinking or massaging, or fitting. The presentation-effect is factored into the job of the aggregate owning "Vulnerability Records" functions — the User Experience (UX) — clear as day. And the quality of the User Interface (UI) is to be judged on how faithfully it presents that effect.
The Aggregate decides HOW MUCH to show and that is all it will send!

Infantile IT Diagram: The 'Read Model' Problem

%%{init: {'themeVariables': {'edgeLabelBackground': '#FFEBEE'}}}%%
graph TB

    subgraph LegacyExternalSystem ["Somewhere"]
        LegacyDatabase["Database"]
    end

    subgraph LegacyServices ["Legacy
(can't change it)"]
        LegacyService["Some Service
sends everything"]
    end

    ReactApp["React Application
Single Page 'Read Model'"]

    LegacyDatabase --> LegacyService
    LegacyService ==>|"ALL of it -- every time"| ReactApp

    CommentFilter["📌 filter it
on the client"]
    CommentDedupe["📌 dedupe
in the browser"]
    CommentPaginate["📌 paginate
somehow"]
    CommentTooMuch["📌 handle
'too much data'"]

    CommentFilter -.- ReactApp
    CommentDedupe -.- ReactApp
    CommentPaginate -.- ReactApp
    CommentTooMuch -.- ReactApp

    classDef UIStyle fill:#BBDEFBE6,stroke:#1565C0,stroke-width:4px,color:black
    classDef ExternalStyle fill:#ECEFF180,stroke:#546E7A,stroke-width:2px,stroke-dasharray:6 4,color:black
    classDef CommentStyle fill:#FFEBEECC,stroke:#C62828,stroke-width:3px,color:black

    class ReactApp UIStyle
    class LegacyExternalSystem,LegacyDatabase,LegacyServices,LegacyService ExternalStyle
    class CommentFilter,CommentDedupe,CommentPaginate,CommentTooMuch CommentStyle

    linkStyle default stroke:black,stroke-width:2px,color:black

What is TOLD in this Infantile architecture story:
Nobody owns the behavior. The data comes from "Somewhere," through a service nobody will touch, and lands on the UI with a note pinned to it: "you deal with it." There is no actor in this picture — no one asked what effect this data is supposed to have on the user, so no one can say what "correct" even looks like. The Read Model is ordered to think: filter, dedupe, paginate, cope. But a projection that thinks is not a projection anymore — it’s an unaccountable little service running in somebody’s browser, rewriting the story on every render. Untested. Unknown. And the pinned comments are the tell: this organization writes its architecture on sticky notes attached to the one component that can’t refuse them. The UI can’t push back — that’s why it got the job!

Now put the two stories side by side. Same industry, same data, same React on the screen. One place tells itself: we decide what effect the user gets, and we send exactly that. The other tells itself: stuff arrives, the browser copes. The first story has an author. The second has only victims.

Perspective is important! A young engineer may have only experienced a couple of web frameworks. In interview, they see a mechanical question: "How to do in React." They haven’t mastered software patterns yet, and none of the people patterns. An engineer with dozens of platform teams under their belt won’t care to remember what’s new in React, they’d mastered dozens of Reacts, UX, and people patterns. Besides, there’s Claude Code to look that trivial stuff up. Instead, they’ll immediately jump to the whole context: "How does this happen?!"

And here is the maturity test hidden in it: in the Adult story, "too much data in React" cannot be asked in a competent world — the question has no meaning there. The Aggregate decides HOW MUCH, based on the real business value this domain is after, and that is all it will send.

• In the Infantile story, the same question is Tuesday. "How to do in React, or JS, or IDE."

• When a healthy-culture engineer hears "how do you load too much data?" — Wait one minute! They are not asking you about React.
  They are reading you their architecture diagram out loud.
  Sticky notes, reactive planning environment, mechanical competence problems, and all.

Do you remember when I told you that "an intermediate service fixes this?"
What is that intermediate service? Is it something that paginates and stops stuffing the React Owl mad? NO! It’s a lot more than that, it IS the missing behavior owner. And if I were implementing it, I’d likely not extract it fully into the domain and the ACL. I’d use Strangler Fig pattern and create a minimalistic domain to own minimalistic behaviors, i.e., a Job Description we’re missing all along. And then I’d iterate over that domain every chance I get to touch its behavior, improve, and expand.

Naive DON’T touch "working components."

The naive will worry about the mechanical problem they have — can’t load all the data.
And miss the actual sin!

Interview: Is a TWO-way Street! What does the candidate read?

So, can one tell enough about institutional IT maturity from a single interview question? You bet one can! When the team is solving for the core values problem they should never have — conclude it’s the norm.

Let me give you a closer to home example. When translated to people, not React, this conversation is then really something like this:

• Question: What do you do if you learn your spouse is dishonest?

• Answer: Um…​ Nothing. This scenario is not a possibility.

• Question: No, no. I am saying it is a possibility — it happened! What do you do?

The conflict here is not about the spousal honesty — it’s about Institutional Core Values. In one person’s world the institution of marriage is based on mutual honesty: no honesty — no institution. In the other’s — that’s an occurrence.

Do you see how much you can extrapolate from a question?

Fixing Accountability Problems

So what does one do about it?
Fortunately, fixing these problems is actually as easy as creating them.
We just need to understand how accountability works:

Accountability cannot be given or bestowed — it must be taken.

What I do is the opposite of the infantilizing parent-child dynamic:

A) Let the people claim the concrete value they will deliver;
B) And I commit to meet contributor’s needs through delivery.

Both A and B are contracts, they consist of spelled-out "what," "when," and measuring criteria.
This way there is zero perceptions-based judging.
Both my teammate and I are objectively, openly, and unambiguously "seen"
either meeting or failing to meet our commitments. This reduces stress and tensions on the team and frees up the atmosphere for a much more positive interaction style.
In fact, these are the standards of conduct on the scene in the Hacker Culture:

1. Talk positively, casually, humorously — as if you were a happy 5-year-old: hackers speak ONLY in plain words, the only ones left when vanity is off the table; a register with an adult’s content — the child’s grammar is the proof of mastery, not its absence.
   The words your kids misspeak are fine and appreciated: 'compooper' means box.

2. Work diligently, seriously, effectively, and honestly (multitasking is not work);

3. Mind the real value attained, costs paid, and timeline met (late means failed).

Notice "language of hackers"! That demeanor cannot be faked. Infantilization is imposed smallness dressed in grand words — permission-seeking wrapped in "alignment" and "stakeholders." The happy-5-year-old rule is the inverse: chosen plainness from full competence. If you can explain tail-recursion translation in one child’s sentence — then you REALLY understand it. And the awesome game of the other is to pick up on your tailrec! It’s the highest form of intelligence that cannot be faked by anyone. Best of all, your business experts in the room need no translation.

Every rising unicorn I’ve been inside had a core team that behaved exactly this way. I can’t name them — their lawyers are better than mine — but the pattern never failed consistency. It doesn’t mean it’s easy. And just knowing about it is not enough — applying such conduct well can be difficult sometimes. I, too, have made regretful mistakes bottlenecking a team in the past.

Hackers say:

I’d like a walk with one cheerful humble hacker;
Please, spare me a pompous-serious dilettante!

Every team I nurtured in Corporate America learned to mind its core values. Self-discipline! Thinking back at these teams, having heard this exact question, what would their answer be? Would it be: "it’s not an expected occurrence for us — not worth the thinking time." Or would it be: "oh, we do this when it happens." The 11 teams I still keep in touch with are solid option one!
And when the poop happens once (it can) — they don’t build coping machinery for it.
They repair the value that let it in. Firing a lifer is not excluded! But understanding comes first.