“What Is Work?”: Rational and Irrational Clash in ESTj Case
Sep 17, 2025
What do we mean by “work”? For some, it is order: neatly arranged folders, clear regulations, and the ability to restore the logic of a process at any moment. For others, it is flexibility — the capacity to keep control even in chaos, to react quickly, and to move forward without looking back at instructions.
In the reality of modern IT, these two approaches often collide. On one side stand rational specialists, for whom systematization is a condition of productivity. On the other side are irrational managers and developers, whose strength lies in pulling a project through uncertainty without wasting time on structure.
When such worlds intersect, distinctive configurations emerge. They can function for years and generate profit, yet there is always underlying tension: differing ideas of what “well-done work” truly means.
Starting Point
To avoid getting stuck in theory, I deliberately “go into the field.” This time it was an IT team that offered me a position after a series of chaotic interviews. From the tone of communication alone it was clear: decisions were made sharply and reactively.
First Steps
My résumé is fairly standard: an experienced developer, closer to an architect. The search took months, but in June I was finally invited to an interview. The meeting was lively: a charismatic manager plus several people at once. They promised to call back — and then disappeared. For me, this was nothing unusual, I had several such cases every week.
Two months later, already at the airport before vacation, I received a message: “We’re waiting for you. Start working.” I replied that I was heading to the mountains for two weeks. “Okay, then start the day after you return.” That’s exactly what happened. Even then I noted their irrationality: decisions made in emergency mode, with no sequence at all.
Project: 11 Years of Life and 5 Years of Team Inertia
An internal corporate system (CRM) built for a specific business. In its current form, the team has been running it for at least five years. The key duo: a charismatic manager SEE (ESFp) and his long-time ally — the team lead-architect ILI (INTp).
I called them “an old married couple.” But not a peaceful couple — more of a sadomasochistic union: the SEE (ESFp) regularly trashed the ILI (INTp) right in meetings, and he kept justifying himself, while we all listened to it at least five times a week.
The SEE (ESFp) could sing beautifully, charismatically inspire, but at the same time created an atmosphere of a forced labor camp: work twenty hours a day or “you’re out of it.” He admitted himself that he often slept only four hours. The ILI (INTp) in this setup was the eternal underdog, philosophizing among the ruins of code and apologizing for every breakdown.
And then I entered this duet — LSE (ESTj). Putting me into their dynamic was like moving in a pedantic neighbor with a couple that had long lived on shouting and mutual reproaches. It was immediately clear: I would be the next target. It almost looked as if they had hired me just to “spice up the marriage.”
Onboarding as Its Absence
Onboarding here meant: set up the environment — and “close at least one ticket a day.” No protocols, no system map, not a single document you could open to understand the purpose of the subsystems. Everything was oral, fragmented, and constantly shifting.
My introduction to the work lasted two days: they set up the environment — and off I went, “take the tickets.” At least one ticket a day, with no documentation, no explanations, as if I had already been inside for five years.
They immediately told me: “Ask everything from the team lead — ILI (INTp).” But the reality looked like this: he could “chew on ideas” for two hours, drifting into abstractions. Yes, sometimes meaning would flash in his words, but proper documentation would have been far more useful. And it simply did not exist.
Even so, I was not idle: in three weeks I managed to close at least five tickets, with two more in progress at the time of my departure. I was really working hard. That’s why sitting for three hours listening to the tedious ILI (INTp) was exhausting — I think that’s understandable, even if formally I was in the wrong.
Code and Architecture: A House with Propped-Up Walls
When I looked into the code, I realized: it could hardly be called code at all. Inside was pure chaos: confusing terminology, no structure, files thrown together in one heap. In five years, no one had done even the most minimal restructuring: organizing into folders, creating a glossary, or outlining module boundaries.
The team lead ILI (INTp) spent plenty of time philosophizing and building abstractions, but solutions either never made it to working implementation or ended up diverging from the actual system. Maintenance followed the principle of “where it leaks, that’s where we prop it up.”
The closest analogy was a house with leaking pipes and rotting beams, where instead of repairing the structure, they kept jamming in supports and calling it “work.” For the ILI (INTp), this was the norm: fragments of code, scraps of comments, even half-formatted files — and that was “good enough.” For me, LSE (ESTj), it was physically painful. It felt like living in a house where the load-bearing walls are held up by sticks, the floor creaks, the roof leaks, yet the owners insist: “If you fix one part, another will collapse — better to patch things as they are.”
But that hardly explained the mess in the code. Formatting a file in an editor is just three keystrokes. For them, even this minimum was unnecessary. My nature cannot tolerate dirt in the corners, while for them, dirt had become the standard.
What They Call “Work”
In their logic, “work” means:
- jumping into the deep end without a map of the terrain;
- accepting a floating agenda (“today one thing, tomorrow another”);
- patching holes created by the absence of design;
- delivering quick “results” without fixing decisions or responsibility.
Any request for time to research and systematize is treated as an unwillingness to work; later this time is used as an accusation.
Why This Works in a Profitable Company
Because the machine is already running: money flows in, hundreds of people are employed, the “function” for the owner is being fulfilled. Stopping the conveyor and re-engineering the load-bearing structures feels frightening and “expensive right now,” so they choose local props — classic local optimization.
Rationals vs. Irrationals: A Clash of Worldviews
The rational worldview requires artifacts (requirements, ADRs, diagrams), stable regulations, reproducible onboarding.
The irrational worldview lives in the moment: “we give opportunities,” “figure it out in the field,” “the agenda is flexible.”
The rational developer sees “horror” where the team sees “normal”: the house is standing, so it must be working.
Analytical Sketch
In Socionics terms, three different approaches to work converged here.
SEE (ESFp)
Work = movement and involvement.
Strategy: generate energy, sustain dynamics, hold the team’s attention.
Logic: value lies in the process and constant activity.
ILI (INTp)
Work = reflection and building concepts.
Strategy: analyze, discuss, search for connections even in unstructured material.
Logic: value lies in understanding and formulating a model of what is happening.
LSE (ESTj)
Work = order and result.
Strategy: create structure, document, build sequence.
Logic: value lies in measurability and reproducibility of the process.
This triangle illustrates the difference in how the very word “work” is defined. For some, it is movement; for others, the search for meaning; for still others, system and result.
Position of the Hired Gun
The contractor is effectively asked for an entrepreneurial contribution (audit, structuring, documentation), while it is framed as ordinary work hours and at the same time any “time for study” is treated as idleness. The outcome is predictable: after three weeks — “you don’t fit.” In essence, it is incompatibility of operational maps.
What to Do About It
For the Tech Lead:
– Introduce minimal artifacts: README for subsystems, folder tree, glossary of terms, ADR for key decisions.
– Fix the onboarding: first-day checklist, system map, zones of responsibility.
– Separate “firefighting” from “structural renovation,” with distinct budgets and rhythms.
For the Rational Developer:
– Diagnose the setup at entry (artifacts, agenda stability, architecture ownership).
– Secure in the contract paid “research hours,” documentation volume, and “done” criteria.
– Bring a “first aid kit” (repo structure, diagrams, module/owner table) and defend it as a deliverable.
For the SEE (ESFp) Manager and ILI (INTp) Team Lead:
– Preserve flexibility of content but cement the form: synchronization rituals, single place for decisions, shared terminology.
– The ILI (INTp) should translate concepts into concrete ADRs and checklists; the SEE (ESFp) should hold sprint focus and avoid replacing the plan with endless “talk.”
Forecast
In turbulence, the share of firms run by irrationals will grow: they start faster and can more easily “push through” chaos. Which means rationals will either have to accept the cult of patching holes or enter projects with a mandate for order — written into the contract.
Conclusion
This case is not about “who is right,” but about mismatched operational maps. Where “work” is defined as constant patching of inherited holes, rational engineering is perceived as an obstacle. Entering such a setup requires either agreement to play by their rules or a strong mandate to change them. Otherwise, mutual disappointment is inevitable.