Benoit COUETIL 💫

Posted on Sep 19

🧠 Ego development: Developers by Stage

#productivity #programming #career #beginners

Initial thoughts
How to read these profiles
E3 — The Self-Centric Developer
E4 — The Group-Centric Developer
E5 — The Skill-Centric Developer
E6 — The Principled Developer
E7 — The Systemic Developer
E8 — The Enabling Developer
E9 — The Wise Developer
When the lines don't match
- The Comfortable Optimizer — E5/E3
Silence folds back on itself
Wrapping up
Further reading

Two developers can share a stack, a title, and a sprint board and still not be doing the same job. The difference is the structure through which they construct the work.

Initial thoughts

We already laid out the model in Ego development: The Eight Professional Stages — the eight professional stages and the mechanisms that make them usable (translation versus transformation, regression, recognition asymmetry). Ego development: The Visual Atlas then charts the same structure at work, under stress, and in public. This piece zooms all the way in — to a single developer at their keyboard.

So rather than slicing the topic by theme, this article profiles the developer at each stage, head to toe. On Cook-Greuter's N=4,510 sample (dissertation, Table 3), the adult modal center sits at E5–E6 (~67% combined centers of gravity). The bulk of the industry spans E4 through E8. The arc is bracketed by two profiles worth knowing at the edges: E3 (Self-Centric) at the bottom — the developer who only works when watched — and E9 (Construct-Aware) at the top, easy to mistake for something far more ordinary. Read these as developmental snapshots, not as a ladder of worth.

How to read these profiles

Each profile below describes the same set of dimensions, so you can compare stages directly:

What drives them — the underlying motivation, the thing they're really optimizing for.
Authority & technical decisions — how they relate to the lead, the architect, "the way we do things".
Code review — what reviewing means to them, giving and receiving.
Bugs, errors, and feedback — what happens when something breaks or someone pushes back.
Remote work, unsupervised — how productive they are when nobody is watching and metrics are loose.
Relationship to AI — how they use (or resist) coding assistants and LLMs.
Career trajectory — where their path tends to go over years.
Best-fit consulting engagement — the kind of client assignment where they succeed right now, while growing toward the next stage. Fit is not a verdict: it's the assignment that plays to the current stage's strengths instead of exposing its limits.
What their silence means — when they go quiet in a standup, a design meeting, or a PR thread. A decoder, not a personality trait: the trap is named after the portraits.

Two caveats before you start typing names of colleagues into the margins. First, stage is not a global label: thanks to Wilber's lines of development, someone can be E7 in technical reasoning and E4 in office politics. Second, everyone regresses under stress — an E8 under a brutal incident can behave like an E5. These are centers of gravity, not fixed coordinates.

E3 — The Self-Centric Developer

The system-gamer. Rare on a healthy team, but unmistakable once you've seen it. The governing rule isn't "do good work" — it's don't get caught. Morality has collapsed into a cost/benefit calculation, and other people are tools or obstacles.

What drives them: immediate personal advantage and avoiding consequences. They want to be left alone, or to come out ahead of whoever they're dealing with. Nothing larger than the next transaction is in view.
Authority & technical decisions: obeys out of fear of getting caught, and circumvents the moment the supervisor looks away. The "right" technical decision is whichever one is least likely to be traced back to them.
Code review: experienced as a personal attack. They deflect, downplay, or retaliate — and when reviewing others, comments can become leverage rather than feedback. The review thread is a power game, not a quality conversation.
Bugs, errors, and feedback: the error is never theirs. "It's not me, it's them" — blame is routed to a colleague, the previous dev, the framework, the ticket. Admitting fault is unthinkable because fault means exposure.
Remote work, unsupervised: this is the defining weakness. Without surveillance, output collapses. They exploit the absence of oversight: minimal effort, padded estimates, work that exists mainly as a status update. Managing an E3 remotely is nearly impossible without hard, externally verifiable checkpoints, because their self-discipline is entirely externally enforced.
Relationship to AI: a tool for shortcuts and cover. AI is used to fake output, ghost-write explanations they don't understand, or game metrics — with zero ethical distance. The question "should I?" never arises; only "can I get away with it?"
Career trajectory: opportunistic. Frequent jumps, a purely transactional network, loyalty to nobody. Each move is an arbitrage, not a step in a path.
Best-fit consulting engagement: none that runs unsupervised. If retained at all, only tightly-scoped, co-located teamwork behind externally verifiable checkpoints, with a lead who reviews every output. Never a solo placement at a client, and never a role where trust itself is the deliverable — the remote tell makes both a liability.
What their silence means: concealment. They go quiet to avoid leaving a trail, not because they're deliberating. This is the mutism end of the arc — and the pre/trans trap in its purest form: it can look superficially like the contemplative quiet of an E9, but it's the silence of someone hiding, not someone at peace.

Strength: in a genuine crisis with clear, immediate incentives, an E3 can be ruthlessly effective at self-interested survival tasks. Limit: ungovernable without control, and corrosive to trust on any team built on it. The single most reliable tell is the remote one — performance that evaporates the instant nobody is watching.

E4 — The Group-Centric Developer

The good soldier. The team's conventions are not choices to be examined — they are reality. "We've always done it this way" is not laziness; it's an identity statement.

What drives them: belonging and approval. Being seen as a reliable, loyal member of the team is the reward that matters. Shame (the group's gaze) weighs far more than private conviction.
Authority & technical decisions: the lead or architect is right by virtue of position. They won't question the architecture — not because they lack ideas, but because challenging the hierarchy registers as a threat, not an option.
Code review: a fundamentally social act. "LGTM" on anything from a senior; typo and style nitpicks on peers and juniors. Approval flows up the hierarchy; scrutiny flows down.
Bugs, errors, and feedback: an error is exposure — it makes them look bad in front of the group. Feedback is acceptable from the boss but feels like an attack coming from a peer. Default move: follow the procedure, point at the procedure. "That's how it's done here".
Remote work, unsupervised: this is the hardest stage for full remote. The office is the group, and the group is the identity. Strip away the physical room, the shared rhythm, the visible presence of peers, and motivation quietly erodes. They need the standup, the desk, the social scaffolding to stay anchored.
Relationship to AI: mimetic. They adopt Copilot/Cursor if "everyone on the team uses it", or distrust it if the group is wary. No independent stance — the group's posture is their posture.
Career trajectory: linear and loyal. Same company or stack for years. Leaving feels close to betrayal.
Best-fit consulting engagement: an established team at the client — staff augmentation inside a working squad with clear conventions, a present lead, and peers in the room. They shine where the frame already exists and someone else owns it. Avoid solo placements and greenfield builds, where the missing social scaffolding quietly erodes their output.
What their silence means: deference, not agreement. In a meeting they wait to see which way the group leans before committing. Silence here means "I don't dare contradict", not "I've decided".

Strength: dependable execution inside well-defined boundaries. Limit: a poor innovator — the very thing that makes them reliable makes them allergic to questioning the frame.

E5 — The Skill-Centric Developer

The optimizer of personal outcomes. Clean code, yes — but clean code that gets noticed. This is the modal stage of the ambitious modern professional, and the engine of most career ladders.

What drives them: recognition and measurable status — the promotion, the title, the level on the ladder. CV-driven development. They know the trendy tools and talk about them, loudly. Their reference group shifts from "my team" to their craft — the language, the guild, the people who share their specialty — and authority becomes whoever wrote the manual or owns the standard in that field.
Authority & technical decisions: respects the hierarchy but has started to see its limits — and plays the game to climb it. Decisions are weighed partly on technical merit, partly on "how does this look for me?" They look for the right answer from recognized authorities — the RFC, the senior architect, the canonical blog post — and can be genuinely thrown when someone credible says "I don't have the answer; we're here to explore." That moment registers as betrayal, not humility: they came to get truth, not co-discovery.
Code review: competitive. "I would have done this differently" is often a status play. Competence is demonstrated by finding faults. Review is an opportunity to shine — and a hunting ground for one-upmanship: the habitual "yes, but…" that adds another idea without ranking which objections actually matter. All technical opinions weigh equally because they can't yet prioritize by context; the last word in the thread is the win.
Bugs, errors, and feedback: received with discomfort but genuinely heard. The dominant emotion is embarrassment — fear of being seen as less capable. Any "I could have done better" is still about the dented image, not yet the genuine ownership that arrives at E6.
Remote work, unsupervised: highly effective as long as the output is visible. They need dashboards, reporting, a paper trail — some channel through which the work (and the credit) can be seen. Take away visibility and you get anxiety, or performative busyness, rather than disengagement.
Relationship to AI: a personal performance multiplier. Fast adopter when it's a competitive edge — more tickets closed, more visible velocity. The risk is velocity theater: optimizing for the appearance of productivity over systemic value.
Career trajectory: the vertical climb. Titles, salary bands, levels.fyi, a carefully curated LinkedIn. Each level is validation.
Best-fit consulting engagement: a visible expert role on a well-defined scope — owning a named component, a migration, a deliverable with reporting and a client audience that can see the work. Solo placement is fine as long as the output is visible and credited. Struggles where success is ambiguous, invisible, or shared without individual recognition.
What their silence means: ambiguous, and worth decoding. It's either strategic — withholding an opinion to avoid being wrong on record, or saving a contribution for a more visible moment — or checked-out, because nothing is personally at stake.

Strength: a strong individual contributor who ships — often the person who pushes a craft to its limits and keeps raising the bar. Limit: context-blind perfectionism and hard collaboration — they prefer single-contributor ownership, argue when respect feels thin, and optimize their square of the board without questioning the game. They struggle when the org needs a good-enough beta while competitors ship. Releasing something imperfect feels like torture; they'd rather miss the market than violate their standard. In meetings they speak in "the truth is…" (capital T) or "in my opinion…" — both masks for the same need to be the one who knows.

E6 — The Principled Developer

The conscience of the team. On Cook-Greuter's map this is Self-Determining: standards are no longer inherited from the group — they're internalized and self-chosen. Quality is a matter of conviction, not applause. Where the Expert still needs external authority to feel secure, the Achiever can describe their own traits with some precision — they know who they are on the job and can articulate it. Self-reflection is possible here in a way it rarely is at E5; many "senior" programs are really trying to teach Experts to do what Achievers do naturally.

What drives them: integrity and craft. They write good code because mediocre code would violate their own standards, whether or not anyone notices. Linear time lands fully: past mistakes inform future goals, and the drift is forward — always building, always improving something outside themselves. Long-term goals and a real sense of responsibility appear here. Unlike the Skill-Centric contributor who will polish one task forever, they feel time as scarce — prioritize, ship the right things, leave some perfection on the table. They can also truly delegate — trusting others to do good work even when they approach it differently, the inverse of the Skill-Centric contributor who takes the task back.
Authority & technical decisions: respects the function, not the person. Will challenge a senior or a decision when their principles or the data demand it — directly, without it being a status game. They can also make provisional agreements: "You're pragmatic, I'm rigorous — for this release we ship your way; for the next we refactor mine." No shared worldview required for the task at hand; band together, solve, disband, reorganize for the next problem.
Code review: a genuine quality gate with ownership. "This violates the principle of X because Y". They actively seek review on their own work, because the goal is the code being right, not them being right.
Bugs, errors, and feedback: they take responsibility. "That's on me, I'll fix it". An error is a personal lapse to correct, not a threat to deflect. The risk is the opposite of E4: guilt and perfectionism.
Remote work, unsupervised: thrives. Self-disciplined and autonomous, they don't need anyone watching — they hold themselves to a higher bar than any manager would. The real danger is the inverse: without the office boundary, over-responsibility tips into overwork and burnout.
Relationship to AI: adopts with discernment and sincere ethical questioning. "Do I actually understand what this generated? Is this code I can stand behind?" They neither worship nor reject the tool — they hold it to their standards. The scientific temperament shows up as "we'll find out — just not yet": empty slots on the periodic table, confidence that the missing piece will be detected once the instrument is good enough.
Career trajectory: values-driven. Will accept a status or pay sacrifice for mission alignment. The career is an expression of personal values. Later in a career, having to give up independence feels like losing the self — the Achiever's retirement challenge.
Best-fit consulting engagement: the classic solo expert placement — the sole engineer at a client, unsupervised, owning quality and challenging the client's architecture on principle. This is the floor for autonomous solo consulting: they hold their own bar without anyone watching, and the expert the client pays for actually pushes back. They can run a greenfield.
What their silence means: deliberation. They're listening and weighing, and they'll speak when a principle is actually at stake. Silence here is the sound of someone thinking, not someone withdrawing.

Strength: reliability rooted in conviction — the energy that built most of what we call "engineering culture". Limit: standards can harden into rigidity, and reasoning stays rationally bounded: it has to make sense, it has to be provable. They still assume one correct reading of the evidence — the same metrics, the same dashboard, one story — and miss that the observer shapes what gets seen. They also tend to overestimate the control they have — a unilateral, overbearing need that others experience as pressure. Two engineers look at the same incident report and one sees a process failure, the other a people problem; the Achiever treats that as confusion to resolve, not as a clue about the limits of their frame.

E7 — The Systemic Developer

The one who sees the whole board — and sometimes wishes they didn't. On Cook-Greuter's map this is Self-Questioning: roles stop defining the person, paradox becomes thinkable, and the developer starts questioning the problem rather than just the solution. It is also the valley — a developmental milestone, not a mood. For the first time they doubt what culture handed them as given: Who am I, really, when I'm different in every context? The turn is inward: less "what do I know?", more "how do I make sense of things this way and not another?"

What drives them: authenticity, meaning, inner coherence. KPIs feel like "just numbers", promotions feel hollow, technical excellence feels insufficient ("great code in a broken system"). The conventional rewards have stopped working. Other sources of information re-enter the frame — intuition, gut feel, what the body says in a bad architecture review — not instead of reason, but alongside it. That release can unlock real creativity; it can also feel like many voices at once, energizing or paralyzing depending on the day.
Authority & technical decisions: detached from formal roles; they see the person behind the title. They'll question whether the team is even solving the right problem — which is invaluable and, in the wrong context, exhausting for everyone.
Code review: they challenge the frame itself. "This PR is fine, but the real problem is the service boundary". Sometimes that's the most important comment in the thread; sometimes it's far too systemic for a routine change.
Bugs, errors, and feedback: welcomed as a mirror, and given with nuance — occasionally too much nuance. The risk is analysis that turns inward and paralyzes.
Remote work, unsupervised: autonomy is the default mode, so on paper this is ideal. But the valley changes the picture: remote can amplify isolation, and there's no friction to pull a cynical E7 back into engagement. Brilliant when engaged; quietly drifting when not.
Relationship to AI: fascination paired with sharp critical distance. They see the second-order implications — skill atrophy, what it does to the craft, where the org is sleepwalking — and risk paralysis from seeing too far.
Career trajectory: non-linear. Portfolio careers, freelance, bifurcations. They quit the corporate track and explore. Roles don't define them, so they wear them loosely — often preferring the fringe of the org chart: unique self-expression that post-conventional peers admire and conventional ones distrust as unpredictable.
Best-fit consulting engagement: short, high-leverage advisory — audits, architecture reviews, "is the team even solving the right problem?" engagements — where their systemic sight is the product and the assignment renews before cynicism sets in. Risky in long, open-ended staff-augmentation without a holding structure: the valley turns a brilliant hire into a quietly disengaged one.
What their silence means: this is the dangerous silence. It signals withdrawal and cynicism: "Why bother writing clean code if the architecture is wrong?" Going quiet here is disengagement under the weight of seeing dysfunction everywhere without yet having the leverage to fix it. This is the valley made audible — or rather, inaudible.

Strength: a piercing systemic vision nobody else has — and, in their writing and speech, a uniquely self-revealing voice that earlier stages only approximate as "types". Limit: fragile engagement. They can see exactly what's wrong and struggle to act on it without sliding into cynicism or retreat. They also inherit a dangerous cousin of their insight: the post-modern impulse to deconstruct everything because all frameworks are artificial — without noticing that "there is no place to stand" is itself a place to stand. Two survivable exits from the valley look alike from outside but feel different inside: following your own drummer (celebrating uniqueness, conventions be damned) versus nihilistic withdrawal (cynicism as the only map that fits total uncertainty). Neither is necessarily pathological; both can keep a person afloat until the E8 passage.

E8 — The Enabling Developer

The one who makes the team better instead of out-producing it. On Cook-Greuter's map this is Self-Actualizing: they don't code the most lines — every intervention is strategic. To an E5 colleague, they can look like they're "doing nothing".

What drives them: systemic contribution and the growth of the whole. Recognition is welcome but no longer the fuel — it comes from impact, not from the gaze of others.
Authority & technical decisions: a partner, not a subordinate. They collaborate with the hierarchy without dependence or opposition, and they'll change the rules when the context genuinely requires it.
Code review: a developmental tool, not just a quality gate. They calibrate feedback to the receiver's stage — a different style for an E4 junior than for an E6 senior — and develop the reviewer as much as the code.
Bugs, errors, and feedback: treated as data for the system, not just for the individual. "What does this teach us collectively?" A post-mortem is an investment, not a tribunal.
Remote work, unsupervised: they design the question away. Rather than needing supervision, they build the conditions — clear ownership, async documentation, well-placed feedback loops — that make supervision unnecessary by design. The location of the work is irrelevant; the design of the work is everything.
Relationship to AI: they think at the level of the system. Not "should I use it?" but "how should the team use it, and what are the second-order effects on our skills, our codebase, our hiring?" AI becomes part of organizational design.
Career trajectory: the career is a vehicle, not a destination. They'll take a nominal step "down" if it serves the larger contribution. The role is an instrument, never the identity.
Best-fit consulting engagement: ambiguous, multi-team transformation — tech-lead-across-squads, CTO-as-a-service, org-scale architecture and enablement. The value is designing the system others work inside, not producing the most output. Wasted — and often misread as "doing nothing" — on a narrow solo ticket-shop placement.
What their silence means: restraint, the exact opposite of E7 withdrawal. They've identified the single intervention that makes ten others unnecessary, so they wait for the right moment and let the rest go. The discriminating test: an E8's silence coexists with the ability to speak sharply and decisively when it matters. The valley's silence cannot.

Strength: invisible value, maximum impact. Limit: that very invisibility — they are routinely undervalued by anyone who measures contribution in visible activity.

E9 — The Wise Developer

Statistically rare, and the easiest profile in this article to misread. On Cook-Greuter's map this is Construct-Aware: the E9 has reconciled the inner conflicts that drive every other stage — the need to belong, to be recognized, to be right, to be lucid. What remains looks, from the outside, almost ordinary: simplicity. But it's a simplicity loaded with integrated depth, not the naive simplicity of an E4 who never asked the questions. This is the deepest pre/trans trap in the whole arc — an E9 can be mistaken for an E5 precisely because both seem unbothered and uncomplicated.

What drives them: service and the reconciliation of opposites. Wide empathy, toward themselves and others. Learning is accepted as inevitable; what's unreachable is relinquished without bitterness. There's a quiet peace with what they are and what they'll never be.
Authority & technical decisions: beyond formal hierarchy. Their authority is natural — it comes from wisdom and empathy, not from a title or even from systemic cleverness. They act from a deep coherence that transcends the formal frame, so the org chart is almost incidental.
Code review: a form of connection. Feedback is given and received with serenity; there's no status, no defense, no agenda — just two people making the work and each other better.
Bugs, errors, and feedback: an error is part of the flow — neither dramatized nor minimized. "That's what needed to happen for us to move forward". No blame, no guilt, no performance of contrition; just integration and the next step.
Remote work, unsupervised: location is irrelevant; presence is internal. There is no gap between watched and unwatched, because there is no external scaffolding holding the behavior up — the discipline, the care, and the engagement come from within and don't depend on context at all.
Relationship to AI: one tool among many — neither threat nor salvation. Integrated without drama. They neither evangelize nor resist; they use it where it fits and leave it where it doesn't, with no identity invested in the choice either way.
Career trajectory: the very concept of "career" is relativized. The path is the point. Titles, levels, and trajectories are simply not the frame through which they organize their working life.
Best-fit consulting engagement: the notion of "fit" largely dissolves — but where it applies, deep advisory, mentoring across stages, and the rare high-stakes situation where presence and judgment under pressure matter more than any deliverable. They adapt to almost any assignment; the question becomes whether the assignment deserves them.
What their silence means: genuine contemplative presence — the opposite pole of E3 mutism. They're comfortable saying nothing because nothing needs to be added, and equally comfortable saying the one thing that reframes everything. The discriminating test holds: this silence coexists fully with the capacity to act and speak with precision when it serves.

A caution worth stating plainly: real E9 is rare enough that you will meet far more people who perform this serenity than who embody it. The discourse of integration sitting on unintegrated shadow — calm words, E5–E6 reactions under pressure — is spiritual bypass. The genuine article reveals itself not in calm weather but under maximum stress, where the equanimity simply holds.

When the lines don't match

The portraits above are centers of gravity on one line. Some people sit on two at once — cognitively here, pragmatically there — and the mix is easy to misread as a higher stage. This is a shelf: more later. The first is the one most often promoted by mistake.

The Comfortable Optimizer — E5/E3

This developer appears calm, delivers their tickets, and seems unfazed by organizational chaos — much like an E8 who picks their battles deliberately.

The difference is structural. The comfortable optimizer is typically E5 on the cognitive line (perceives nuance, reads the situation) but E3 on the pragmatic line: they work around broken systems rather than improving them. The system is a landscape to navigate, not a material to shape. Ask "What would you change in the team's process?" and they answer: "Nothing, I've found my workarounds". An E8 immediately names a structural lever.

Both look serene — but the E5/E3 has nothing at stake, while the E8 has integrated the complexity. The comfortable optimizer genuinely doesn't understand why a colleague would spend energy improving their environment without a direct financial reward — that motivation sits outside their frame. This isn't a character flaw; it's a developmental limit, and recognizing it lets you calibrate expectations without judgment. It is also why a quiet, unbothered developer is not automatically a wise one.

Silence folds back on itself

Watch the silence dimension especially, because it's the one most often misread. The arc folds back on itself: the quiet of an E3 hiding their tracks and the quiet of an E9 at peace look identical from across the room, just as a checked-out E5 with nothing at stake mirrors an E8 who has integrated everything. That's the pre/trans confusion — the bottom impersonating the top. One test cuts through it: can the person also operate vocally and decisively when it matters? An E8 or E9 holds their fire and can name the problem with surgical clarity on cue; an E7 in the valley, a checked-out E5, or an E3 covering their tracks cannot. Getting this wrong — promoting the checked-out, sidelining the restrained — is how teams quietly lose their best people.

The comfortable optimizer above is the same trap in working clothes: calm is not wisdom.

Wrapping up

The portraits are the point: same keyboard, different structure, and it shows up in everything from what motivates a developer to what their silence means in a meeting.

Two practical levers fall out of all this. Pair developers across a one-stage gap: same-stage pairing is comfortable but flat, a two-stage gap frustrates both sides, and a single stage of difference is the growth corridor — close enough to challenge, far enough to stretch. Pair rotation should be stage-aware, even informally.

And titles measure the job; stages measure who sits in it. A title names demand — autonomy, influence, ambiguity. It does not name the meaning-making that can inhabit that demand. The Skill-Centric contributor looks like the ladder and climbs it. The Systemic developer often leaves. The Enabling developer looks idle.

Title	What the job asks	Who inhabits it	Who climbs anyway
Junior	Follow / belonging	E4, sometimes a young E5	E3 if watched
Mid	Visible craft	E5	E4 loyal + time
Senior	Defined problems, ownership	E5–E6	E5 CV, long-tenured E4
Staff	Ambiguity, influence without authority, find the problem	E7+, solid late E6	E5 fake Staff
Principal	Leverage, conditions, one lever	E8	E5/E6 with paper scope
Distinguished	Presence, judgment	E8, almost never E9	Branding

Cynicism, the checked-out optimizer, the valley — none of these are personal failures. They're developmental transitions, as legible and as patterned as anything in our codebases. Understanding a stage won't change it on its own. But it can change how we navigate the valley, how we read a quiet colleague, and how we avoid mistaking the appearance of a stage for the thing itself.

A companion piece shifts focus to the person standing next to that developer all day — the delivery manager (project manager, Product Owner, Scrum Master — not necessarily the people manager) — profiled stage by stage, with a survival guide for the developer reporting to each.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

DEV Community