๐ฃ Part 4: Mauve Is the New Rose
Part 4 of the Mauve series: my company handed engineers a "how to use the AI tool" doc. Buried in the mental model โ you're not coding anymore, you're managing a team. Nobody asked.
Congratulations on your promotion. There's no raise, no title, and no way to say no.
"hired 10 or 20 junior, highly motivated software engineers in a different timezone"
โ from a training doc my company wouldn't let me copy and paste. I screenshotted it anyway.
That's not a metaphor. That's the literal onboarding description for how I'm supposed to relate to an AI orchestration tool at work. Not "a smarter autocomplete." Not "a pair programmer who never gets tired." A team. Junior. Motivated. Timezone-displaced. Needing "clear direction, good context, and review from someone who understands the system and the outcome."
I've read that sentence a dozen times now. Every time, it says the same thing: you are now their manager. And I think about that every time someone tells me agentic tooling is about giving engineers their time back.
(It is, technically. The time you get back is the time you used to spend writing code. The time you now spend is the time middle managers spend running standups nobody asked for.)
๐๏ธ The Org Chart Nobody Redrew
Here's the thing about a mental model: it's not decoration. It's the job description in disguise. If the doc says "think of it like managing 20 junior engineers," then the doc is not describing a tool. It's describing a headcount โ sorry, a team โ and you're the one holding the org chart nobody drew for you.
Strip the branding off "Thinking in Mauve" and read it as a role transition:
๐๏ธ Daily backlog grooming = Sprint planning
๐ฌ Chat refinement before execution = Spec review with a report
๐ซ Trigger through the Jira workflow = Delegating the work
๐จ "Intervene only for decisions, blockers, changes in intent" = Managing by exception
๐ PR review with enough context to own the decision = Performance review
๐ Slack escalation, treated as urgent = Managing up, down, and sideways at 2am
๐ "Walk away on purpose" = Trusting your reports โ with none of the training that usually comes first
Every single line item in that doc is a real, load-bearing management skill. Delegation. Escalation triage. Review-without-rewrite. Trusting a report enough to not hover, which โ ask literally any first-time EM โ is the single hardest muscle to build. Nobody wakes up good at "walk away on purpose." It takes a manager coaching you through the anxiety of not knowing what's happening for six hours. Where's that coach in this doc? There isn't one. You get a bulleted list and a "good luck."
๐งพ The Fine Print Nobody Signed
"The highest-leverage activity you can do before handing off to Mauve is turning an ambiguous request into work that an agent could execute without guessing."
Writing unambiguous specs, defining non-goals, flagging invariants, naming required reviewers โ that's not "refining a ticket." That's the actual, certified, textbook job of engineering management. Somebody just renamed it "delegation hygiene" and slid it back onto the IC desk with a straight face.
And the kicker: you don't get the title. You don't get the pay band. You don't get to put "managed a distributed team of 10โ20 engineers" on your review packet, because technically you didn't โ you "used a tool." The org chart still says Senior Engineer. The actual day-to-day now says Engineering Manager, Unpaid, No Direct Reports, Direct Reports Are Vibes.
I know exactly what that job looks like from the inside. I've done it. I quit it. I wrote about why.
๐ I've Already Quit This Job Once
A year ago I wrote a whole post about walking away from management. Not because I didn't want to lead โ because of exactly this pattern, minus the AI wrapper.
The admin that ate every hour and produced nothing anyone read. The "empowerment" that turned out to be top-down alignment wearing a lanyard. The role with no edges โ technical lead, PM, scrum master, therapist, whatever the day demanded, until being stretched across five jobs meant doing none of them well. The autonomy that was never actually there โ finding out months later my team had been quietly reassigned to something I was never looped in on, so instead of solving the problem I was the problem: one more boss handing out fragmented direction.
I picked IC because IC gave me back the one thing management spent: focus. Same impact, less burnout. That was the entire thesis.
And here's what nobody in that training doc bothered to notice: none of it changed. The admin's still here โ I just call it "spec refinement" now. The role with no edges is still here โ reviewer, escalation contact, and quality bar, simultaneously, for as many tickets as I can stand to open. The autonomy is still missing โ I didn't choose this scope, I inherited it the day the doc went live, same as I inherited side-projects my team got pulled into without me. The only real difference is that my reports don't have feelings, careers, or families โ which somehow makes it worse, not better. At least when I burned out managing people, I was building people. This is managing without even that part.
I didn't leave management to become management again with worse benefits.
๐ถ Walk Away on Purpose (No, Seriously, Read That Again)
"Do not repeatedly refresh the ticket, inspect every intermediate step, or provide corrections that should have been expressed in the specification."
This is correct advice. It is also, functionally, "stop micromanaging your reports," lifted directly from every leadership book published since 2004, and handed to engineers with zero acknowledgment that micromanagement is a trauma response, not a personality flaw. People micromanage because they were burned by unreviewed work going sideways, or because nobody ever taught them what "enough trust" looks like. You don't fix that with a bulleted list. You fix it with coaching, feedback loops, and time. None of which is in this document.
๐ฏ Nobody Asked If I Wanted This
Here's the part that actually gets me โ more than the extra work, more than the unpaid title bump. Nobody asked.
There was no calibration cycle where I raised my hand and said "actually, I'd like to move off the IC track into people-adjacent orchestration work, please evaluate me for that." There was no comp conversation. There was a doc. A doc I couldn't even copy and paste out of โ which, read charitably, is a security policy, and read accurately, is a company that doesn't want its own management-track redefinition getting screenshotted and blogged about.
I ported this tool into a VSCode extension myself, in a couple of days, on my own initiative, because I wanted to understand what it actually does before someone handed me a workflow doc telling me what it's supposed to do to me. It's already shipped two PRs. It's good at what it's good at.
That's not the complaint.
The complaint is that "good at what it's good at" got used as the on-ramp to quietly reclassify an entire engineering org's job function, and the doc that announces it reads like a rollout memo for a Jira plugin instead of what it actually is: a career-track change with a "no comment" box where consent should go.
Mauve Is Just Rose, Bruised
Rose-colored glasses show you the world the way you wish it were. Mauve-colored ones show you the world the way it actually is โ slightly duller, slightly off, the color of a bruise that hasn't finished forming.
I put mine on. I read the doc twice. I did the thing where you follow the instructions exactly, in good faith, because that's supposed to be how you evaluate a new system honestly.
And what I found underneath the workflow diagrams wasn't a better way to ship code. It was a promotion letter nobody signed, for a job I already resigned from once, with a title nobody's allowed to put on LinkedIn.
You don't need a title to be somebody's manager. You just need a company willing to skip the part where they tell you.