A 5-level maturity model for Mixer Mode (use it on yourself first)

A maturity model isn't a closed prescription. It's a conversation with yourself, in a structured form, that helps you locate where you are on a transition you're already going through. Here is mine: five levels for placing yourself in Mixer Mode. I use it on myself first, then with the team. Posture up front — this is how I think about the problem; if you have a better cut, I'm more interested in the better cut than in a like.

Why a Maturity Model and Why With Caution

The canonical flaw of every maturity model is that it flattens what's actually continuous and suggests a linear progress arrow that may not exist. The CMMI critiques have made this point for thirty years, and they're right. Levels imply ordering, ordering implies progress, progress implies judgment, judgment turns into ranking, and ranking turns into performance reviews. That whole chain is the failure mode.

So I want to draw the line before we start: the correct use of this model is shared language to locate yourself and your team, not a value judgment to be applied to a person. Saying "I'm at Level 2 on the architecture channel this quarter" is useful information. Saying "Maria is a Level 2" is the move that turns a diagnostic tool into a weapon.

This isn't a closed derivation — it's a first cut. I expect the second version of this model to come from someone who applies it for six months in their own organization and finds the holes in mine. If you do that, please send me what you find.

The 5-Level Model

The table below is the spine of the model. Five levels, each described by how it shows up in three observable settings: the daily standup, the code review, and the end-of-day fatigue signature. The settings are deliberately specific so the levels are recognizable, not abstract.

Let me unpack each row briefly so the table isn't doing all the work alone.

Level 1 — Hat-locked. The practitioner is running exactly one channel and actively suppressing the others. "I'm coding right now" means architecture, product, and QA are explicitly out of frame. The standup is a one-channel recital. The code review focuses on bugs because the other dimensions aren't in scope when the hat is on. End-of-day fatigue is low because, structurally, less is happening upstairs.

Level 2 — Hat-rotating. The practitioner alternates between two or three hats with visible switching cost. The standup is serial — "in product mode this morning, in code mode this afternoon" — and you can hear the gap where they're re-orienting. Code reviews start to cover multiple dimensions, but in sequence rather than integrated.

Level 3 — Hat-aware. This is the transition level, and it's the one most people get stuck at. The practitioner recognizes other channels are running in the background but doesn't report them. There are awkward pauses. Code reviews include hedging language — "I'm not sure if this is the right place to say it, but...". The cognitive load of holding the unreported channels is real and visible.

Level 4 — Mixer-emergent. The practitioner runs three or four modulated channels in parallel. They can articulate the simultaneity, but it takes work. "While I was implementing this, I was also thinking about how it would land in QA, and I'm not sure the product team realized this would shift the timing." The articulation is real and useful, and you can see the effort in their face. Fatigue is visible by end of day.

Level 5 — Mixer-fluent. The practitioner integrates the channels in the first sentence, without the switch being visible to the listener. They sustain the mode through deliberate recovery — they protect their evenings, they take real breaks, they don't try to operate at L5 sixteen hours a day. And critically, they can model the mode for juniors under preceptorship, which is the only durable way the capability gets transmitted.

How to Use the Model on Yourself First

Before you take this anywhere near the team, run it on yourself. Walk through the five levels describing your last actual workday — not a hypothetical good day, not the day you wish you'd had. The Tuesday before last.

Resist the temptation to self-assign as Level 5. Almost everyone reading this will want to. The fluent self-image is more flattering than the rotating self-image, and it's also almost always wrong. The honest mark is your modal level — what you operated at most of the time — not the peak level you reached on the best meeting of the week.

Then do one more pass: identify one specific channel where you're hat-locked even though the rest of you is mixer-emergent. Most people have one. It's usually the channel where they have least confidence — the product channel for a deep-tech engineer, the architecture channel for a recent IC promotion to lead, the QA channel for someone who came up through pure product work. Naming that one channel is more useful than the overall level.

How to Use the Model on the Team (With Care)

The team application is where this model can go wrong fastest, so the rules are stricter.

Do not use it for ranking. Do not use it as a row in a performance review template. Do not let it leak into compensation conversations. If it does any of those things, it stops being a diagnostic and starts being a punishment, and you've broken the only thing it was good for.

Do use it as the structure for a one-on-one conversation. "What level would you put yourself at right now? Which channel feels stuck?" That's a different conversation from the standard one-on-one and it gives the practitioner language for something they were probably already feeling.

Watch for the bias. Seniors tend to self-assign as Level 5 and juniors tend to self-assign as Level 1, and both are usually wrong. The senior is probably hat-locked on one channel they don't want to admit to. The junior is probably mixer-emergent in at least one domain where they aren't giving themselves credit.

The most useful signal is the team pattern, not the individual numbers. If your whole team is sitting at Level 2, the problem is not personal. It's organizational. Something in your standup format, your delivery cadence, your missing supervisory layer, is forcing a lower level than the team could operate at. The intervention is structural, not individual.

What Signals Good Managers Watch to Tell Levels Apart

If you're trying to read the level from outside — listening, not asking — here's what I look for.

Level 1-2: long answers to simple questions. The practitioner is processing one channel at a time, so questions that touch multiple channels take a while to assemble.

Level 3: awkward silences when asked about a different domain. They're thinking about it, they just aren't yet able to report it cleanly. The pause is the tell.

Level 4: the construction "while I was doing X I was also thinking that Y" starts to appear. The simultaneity is articulated, with effort, and the articulation is itself a sign of the level.

Level 5: the channels are integrated in the first sentence. The listener doesn't notice a switch happening — the answer arrives already woven.

These are signals, not tests. They're useful for orientation, not for grading.

Honest Limitations of the Model

There is no validated psychometric instrument behind this. It's observational, built from years of watching practitioners and trying to give names to patterns I kept seeing. If you want a peer-reviewed scale, this isn't one.

Levels can mix by domain. The same practitioner can be Mixer-fluent in architecture and Hat-locked in product. The model handles this badly — it treats "level" as a person-level attribute when it's really a person-by-channel attribute. That's a known weakness.

Organizational context forces levels downward. Hat-mode standups produce hat-mode reports even when the practitioner is operating in mixer. If the ritual doesn't have room for the integrated answer, the practitioner gives the un-integrated answer the ritual asks for, and you misread the level as lower than it is.

It's a first cut, not a closed derivation. I'm holding it loosely. The next version comes from a manager who applies it for six months and finds where it breaks.

A Practical Question to Use It on Monday

Walk into Monday with three questions in your pocket.

What level is your modal team operating at, today, in the activities that matter most? Not the answer your team would give in a survey — the answer you'd reach by watching them in standup for a week.

What organizational ritual is forcing a lower level than the team could otherwise operate at? Standup format is the usual suspect. Code review format is the second. Sprint planning is the third.

What is the first low-cost intervention — change the standup format, restructure code review to invite multi-channel feedback, add a weekly synthesis ritual — that would lift the team a level? Pick the cheapest one and try it for a month.

Honestly, what level would you place yourself at, and which specific channel keeps you stuck in hat-locked? Share the case and I'll come back with analysis.

#MixerMode #TechLeadership #EngineeringManagement #CIO