Key Features
Sufficiently powerful AI can become the middle manager of everyone’s dreams. Wonderfully effective interpersonal skills, no personality defects. Fair and timely feedback.
Try to convince me this isn’t the case.
Linking Marshall Brain's ever-relevant novella "Manna" on this: https://marshallbrain.com/manna1
Managing is about building relationships to coordinate and prioritize work and even though LLMs have excellent soft skills, they can't build relationships.
:-)
Where is the AI going to get the information required to do the job?
How is the AI going to notice that Bob looks a bit burnt out, or understand which projects to work on/prioritise?
Who is going to set the AI managers objectives? Are they simple or are they multi-factorial and sometimes conflicting? Does the objective function stay static over time? If not how is it updated?
How are you going to download all the historic experience of the manager to the AI or are they just going to learn on the job.
What happens when your manager AI starts talking to another teams manager AI? Will you just re-invent office politics but in AI form? Will you learn how to game your AI manager as you understand and potentially control all it's inputs?
Have you tried AI to convince you otherwise?
I think most of these objections are valid against a “ChatGPT-in-a-box is your manager” framing. That’s not what I meant by “AI replaces middle management”.
What I did mean is: within ~36 months, a large chunk of the coordination + information-routing + prioritization plumbing that currently consumes a lot of EM/PM time gets automated, so orgs can run materially flatter.
A few specifics to the questions:
“Where does the AI get the information?”
Not from vibes. From the same places managers already get it, but with fewer blind spots and better recall: issue trackers, PRs, incident timelines, on-call load, review latency, meeting notes, customer tickets, delivery metrics, lightweight check-ins. The “AI manager” is really a system with tools + permissions + audit logs, not a standalone LLM.
“How does it notice burnout / team health?”
Two parts: (1) observable signals (sustained after-hours activity, chronic context switching, on-call spikes, growing review queues, missed 1:1s, reduced throughput variance), and (2) explicit human input (quick pulse check-ins, opt-in journaling, “I’m overloaded” flags). Humans are still in the loop for the “I’m not okay” stuff. The AI just catches it earlier and more consistently than a busy manager with 8 directs and 30 Slack threads.
“Who sets objectives / what about conflicting goals?”
Exactly: humans. Strategy is still human-owned. But translating “increase reliability without killing roadmap” into day-to-day sequencing, tradeoff visibility, and risk accounting is where software can help a lot. Think: continuous, explainable prioritization that shows its work (“we’re pushing this because it reduces SEV risk by X and unblocks Y; here are the assumptions”).
“What about historic experience?”
You don’t “download” a manager’s career. You encode the org’s policies, past decisions, and constraints into an accessible memory: postmortems, decision records, architecture notes, norms. The AI won’t have wisdom-by-osmosis, but it will have perfect retrieval of “what happened last time we tried this” and it won’t forget the quiet lessons buried in docs.
“Will we reinvent office politics / will people game it?”
We already do. The difference is: an AI system can be designed to be harder to game because inputs can be cross-validated (tickets vs PRs vs customer impact vs peer feedback) and the rules can be transparent and audited. Also: if you try to game an AI that logs its reasoning, you leave a paper trail. That alone changes incentives.
“Relationships and trust can’t be automated.”
Agree. And that’s why I don’t think “management disappears.” I think it unbundles the human part (trust, coaching, hard conversations, hiring/firing accountability, culture) - that part stays human.
The mechanical part (status synthesis, dependency chasing, agenda generation, follow-up enforcement, draft feedback, metric hygiene, “what should we do next and why”) becomes mostly automated. But did everyone love that part anyway? I don't.
So the likely outcome isn’t “everyone reports to an API”. It’s: fewer layers, more player-coaches, and AI doing the boring middle-management work that currently eats the calendar.
In other words: I’m not claiming AI becomes the perfect human manager. I’m claiming it makes the org need less middle management by automating the parts that are fundamentally information processing.
The missing piece wasn't intelligence, but statefulness and emotional memory.
A human manager (or VP) remembers that you embarrassed them in a meeting three weeks ago, and that hidden state dictates their reaction today. LLMs—currently—are too 'forgiving' and rational. They don't hold grudges or play power games naturally.
Until AI can simulate that messy, long-term 'political capital' (or lack thereof), I think we still need humans to navigate other humans. But I agree, for pure PR review and logical feedback, I'd take an AI manager any day!
However, I won't pay for the course as I'm only an IC with no realistic path to management. But maybe "transitioning from IC to management" is too small of a niche for this product: sounds like it would be good for managers that want to improve: "strategies for management from an ex-developer" or something like that
On the niche size: You make a great point. I targeted 'Transitioning' specifically because that’s usually the moment of maximum pain (and imposter syndrome).
Established managers often feel they've 'figured it out' (even if they haven't!). The transition window is where people are actively looking for a lifeline.
But you're right—at the Staff/Principal IC level, a lot of this just becomes 'Managing Up.' Dealing with a Backchannel VP is a survival skill whether you manage people or just manage architecture!
If there was a way to combine this with coaching sessions, I think this could be a very effective way to train IC's that are stepping into leadership roles (managers, staff/principal IC's, PM's, etc.). It could also be interesting to have a variant of the exercise where you ask the student/user to write their own message.
You hit the nail on the head regarding coaching. I actually view this tool not as a replacement for coaching, but as the 'Lab Work' that happens between sessions.
If a new manager can play the 'Firing' scenario 5 times at home and fail safely, they come to their coaching session with specific, high-quality questions rather than generic anxieties. It allows the human coach to focus on the nuance rather than the basics.
Thanks for the feedback!
For people looking to transition to management, one thing I’ve learned is that a big part of my job is getting everyone to do only one thing at a time. Every stakeholder (including engineering managers) are obsessed with the idea of “sneaking a bit more work in,” and I’ve never seen it work. I will actually go as far as to refuse to estimate work if I have something more important for the team to focus on. After all, estimation is work and we have a higher priority!
The benefit is that you’ll often find nobody actually estimated the business value/priority before asking for the work estimate, so you end up wasting less time overall. The hard part is resisting the pull of your boss asking you to do something.
You really highlighted the core tension here: The theory of management (WIP limits, focus) is logical and easy to understand. But the practice—actually looking at your boss in the eye and saying 'No, we won't even estimate that right now'—is pure emotional friction.
That specific 'hard part' you mentioned—resisting the pull of authority—is exactly the muscle I'm trying to help people build without burning bridges. It’s the difference between knowing the rule and having the stomach to enforce it in a balanced way.
The only way to get "perfect rating" is to go to your junior dev and bring another interruption (maybe the dev was 90% done !). So now he has been interrupted twice by two different manager and you have contradicted your own boss in front of an employee. You just broke a cardinal rule of middle management: it's ok to tell your boss he is wrong, but not in front of someone else. Additionally, you also need to tell him to f** off with is request to get the numbers (without even trying to understand if the request was legitimate or not !), so that your precious sprint is saved. I don't see how he gets what he wants in your ideal handling. AT best you seem to tell him you will "look into it" in two weeks.
Much better solution is to help you junior dev solve the problem so the interruption goes away as fast as possible and he can go back to contributing to the sprint. If the VP requires these numbers and went as far as back channeling you there is probably a quite good reason for that. Maybe the last time he needed something you told him it was not possible because the sprint thingy is unmovable ? Once you have the result, you can go give those to the VP yourself, highlight the work of the junior dev, and use this "I am giving you the very important data you asked for" as a foot in the door to show that you had to pull the dev from the other feature, that these interruption also have cost and that you are more than happy to take care of them. He gets what he wants, the difficult conversation of "you did not do what you are supposed to do" happens behind closed doors, and you have a much better of getting results if he sees you as an ally to get his important stuff rather than a hinderance.
Eeeehhh, might be overestimating executives a bit =P
But yeah, my first instinct is also to tell Gary to fuck off. That said, I would default to a process reason, so, the advice at the end wasn't totally useless for me.
And I'm with you—my default instinct is also to tell Gary to back off using a Process Reason (e.g. 'It's not in the sprint'). It feels safe because it's logical.
The 'Advice at the end' was just trying to highlight why that specific shield often cracks against a VP (because they think they own the process). Glad that specific breakdown was useful to read, even if the scenario felt a bit generous to the exec!
Again, it also depends on who "Gary" is in the real world!
You are absolutely right that contradicting the VP in front of the Junior Dev breaks the 'United Front' rule.
This highlights a key point: I built this to teach transferable heuristics (e.g., 'Protect the team'), not to be a rigid playbook. In real life, specific contexts (like 'Is the VP usually reasonable?') often override the default rule.
Your approach—facilitate the request to clear the distraction, then negotiate boundaries in private—is a more sophisticated heuristic than the one I initially coded. It trades short-term sprint purity for long-term political capital.
I love this. I’m going to add your 'Shield & Deliver' path as an alternative (and perhaps superior) winning state. This is exactly the nuance I wanted to surface.
I would be wary of this being the superior winning state, but definitely an alternative. I've done exactly this in my career as a tech lead only for it to burn me, and probably 2/3rds of the time the best thing for everyone is to simply "Save the Sprint" and not become mired in discussions that often are for personal empire building that strategic leadership would hate.
Maybe people have different experiences than me on this, feel free to speak up!
You are absolutely right. If you 'Shield & Deliver' every time, you risk becoming the 'Yes Man' who absorbs infinite scope creep for someone's vanity project (Empire Building).
The 'Correct' answer actually depends entirely on the Nature of the Request: Legitimate Business Crisis? -> Shield & Deliver Noise/Politics? -> Save the Sprint
Distinguishing between the two before you act is the master skill. I think keeping both paths as valid strategies with different 'Trade-off' warnings or having 2 different contexts is the right move to reflect that ambiguity
This is good intuition but generally people won't tell you whether they have a good or silly/self-serving reason in my experience, and you can only really get them to surface that by comparing it to the priority of other commitments and forcing them to depriotize something.
I think the ratings might be a bit borked. There's a dialogue path choice that results in the A+ where you end up asking directly whether the back-channel was worth another delay, and you. The VP says no. No junior gets interrupted.
Sometimes you don’t even need to surface it. You just force responsibility: “This will prevent us from being ready for Friday’s demo. If you’re cool with that I’ll run it by {project sponsor}.”
Now it’s between the VP and the project sponsor - as it rightfully should be.
Meanwhile there are five other subordinates and all the overhead that you're neglecting while you fiddle with your dev environment trying to get started on the task, as you've been away from direct engineering for a while.
If it is in a deep political institution these are the initial set of questions I would start with:
Who is the Jr to the the VP, what are their relation ? How is your Jr to the manager ? How is the manager relation to the VP? How respectful to boundaries the VP is to the boundaries? How likely is for him to repeat or to get you shoved out the way next time ? How much do you care about being put astray in comparison to the quality of overall work ? How many times this has occurred before ? How likely is for the Jr to bypass you anyway ?
And as one can see, this is just too much to bother with. Sometimes it is easier to cry out that you need more money and or time.
I would do the same by the way. Make the distraction go away and try to put things back into the process route. If the process does not work and this is constant there is no reason to tell the person that pays you that they are always wrong.
Also, you're commiting the team to deliver something you (probably) don't have the technical knowledge to estimate, so you might be adding another week of death March after just 1 weekend.
The lesson at the end is not wrong, but the characters don't seem realistic.
That said, I have always been IC for a reason, so what do I know.
You are spot on about the risk: Promising a 'Soul Update' without consulting the team is essentially writing a blank check that Engineering has to cash. As an IC, you are right to call that out—it's a dangerous move.
Why I wrote the 'Winning' path that way: In my experience, Founder objections are often 50% about the product and 50% about anxiety. They threaten to 'lose the 50k' because they are scared of a flop. The 'Ship + Fast Follow' strategy works because it addresses the anxiety without killing the momentum.
On a lighter note: I definitely had a 'Steve Jobs' archetype in mind when writing that dialogue—hence the obsession with the product's 'Soul' over its metrics! Dealing with a visionary who ignores logic is a distinct skill set from dealing with a rational MBA type.
I call it "quitting".
As someone about to step into a C-suite role: I picked the "correct" path and as long as people are reasonable, it works well.
That caveat—'as long as people are reasonable'—is the biggest variable in the equation. The real challenge is sticking to that correct path when the other side acts irrationally.
Good luck with the new role!
I wanted to pre-order, but the link doesn't let me.
On the Pre-order: I’m sorry about that! The payment gateway is currently stuck in 'Verification Pending' (bad timing with the HN hug).
I’ve set up a temporary waitlist here: https://forms.gle/UhRNLqbaHQfjiS8V8
If you drop your email there, I’ll ping you as soon as payments are live (and I'll send a discount code as an apology for the friction!)
Experience: I draw primarily from 14 years in product companies, focusing on the specific friction points where I've seen Leads struggle (or where I struggled myself).
Vetting: I stress-test the dialogue options with a network of Engineering Managers and Directors to ensure the 'winning' paths reflect reality, not just theory.
That said, unlike C++, management doesn't have a compiler to prove you are 'Correct.' It is subjective. The feedback in this thread is actually highlighting some edge cases I missed, which helps me refine the grading logic
I've temporarily disabled payments to be safe. You can drop your email on the waitlist https://forms.gle/HyPpz77T6yARoZVn7 and I'll send a discount code once I fix the plumbing. Sorry about that and thanks for notifying!
9/10 times the new manager is miserable and doesn't add anything to the employees' day to day aside from stressing about your next 1:1, and is then locked to that role for the duration.
https://en.wikipedia.org/wiki/Kobayashi_Maru
I've had the fortune to be able to steer my career back down to IC with no loss of income every time I have been pushed up into an EM role.
Only one data point, but I'm 100% happier as IC than EM.
But there are other players who likes to trade it for Money!
Thanks for sharing the Kobayashi Maru scenario though! Can use it as a fun simulation if someone fails all scenarios to make it light hearted yet meaningful.
1. If the junior dev is really that critical for a large project for some bizarre reason (fix that next time), tell Gary he's critical to that and say you can realloc ppl to cover or do this task under a 1hr time limit if it's urgent (if exceeds then kill the task). 2. Say to Gary next time let me know directly rather than dm someone on the team so you can route it to the right person (buys trust, covers team). 3. Renewal of BigCo is important to the biz. You should have some room to accommodate requests like these without being a stone to adhoc requests. It will not buy you or your team favour at all. Remember, this is a startup!
This highlights a key distinction: The simulator is designed to teach heuristics (e.g., 'Default to protecting the team'), not a rigid playbook. In a real startup, specific contexts (like 'BigCo Renewal') often override the default heuristic.
You nailed three critical nuances that the default path glossed over:
Bus Factor: If the Junior is the only one who can pull the data, that's an engineering failure on my part.
Business Alignment: In a startup, 'Revenue' > 'Sprint Integrity.' Being a 'stone' to revenue-critical requests is a fast way to lose influence.
The Middle Path: Your suggestion (Timebox/Reallocate) is the advanced move. It solves the VP's pain without wrecking the sprint.
Thanks for adding this perspective—it shows exactly where 'Best Practice' meets reality.
I’ve been running these sorts of training exercises w gpt5 and it’s been quite insightful. Not for mgmt but general senior-staff level communication. That even has flexibility to explain better context on my specific situation and role.
I wouldn’t pay $19 for this as it stands.
You nailed the trade-off. LLMs are incredible for open sparring, but they often work best if you already know the underlying principles to guide the roleplay.
I view this tool as the 'Drills' to learn those heuristics, so you can then go to GPT and practice them with your specific context. Appreciate the honest signal on pricing.
this is good management?
It's fascinating that you can feel how the toxic culture of his work experience bled into OP's world model.
The junior dev is watching, and got the benefit of seeing that you value his time
> managing via Slack
Far preferable to arranging a face to face meeting over this low impact, simple procedural issue
> being a speed bump just because
Defending your team's finite attention and time from random direct requests from the business is a major part of your job as an EM.
> "scope creep" bogeyman
There's good reason scopes are defined and communicated, and deadlines and expectations are managed.
Whenever an issue involves people, slack simply won't suffice. There's too much good will lost on either side. "No worries if not [grumble grumble]!"
This isn't procedural, like sending an invoice to the wrong email address. This is a vp overstepping and threatening the success of another employee. They know what they're doing.
Quickly understanding the urgency/importance of the ask while communicating the impact it is having on the deliverable is the right call. Good business people work like this all the time. Seeing the discussion is a good learning opportunity for a junior.
In an ideal org, we wouldn't need to be 'speed bumps.' But in my experience, the 'Scope Creep Bogeyman' isn't imaginary—it is often the #1 cause of team burnout.
The intent wasn't to glorify 'Slack Management,' but to acknowledge that in 2026, that is the battlefield where a manager often has to stand between their team and a chaotic environment. It’s ugly work, but someone has to be the shield.
Honestly, the "praise public, reprimand privately" truism that people learn is, along with the shit sandwich, one of the most harmful maxims in management.
There are situations where, as the leader, the team needs to see you act. Let's take an example of someone speaking to another team member in an inappropriate way. If you reprimand privately, nobody knows you did that. Now, you have a team that thinks it's ok (or is raging that you think it's ok) to talk to each other in that way. If you call it out publicly, now everyone knows it's not.
It is a double-edged sword, though. I'd not put a junior on full blast for introducing a bug, or a team member for missing an issue in a code review. That would send completely the wrong message.
I'm not sure if you're disagreeing with me or not, given that was the gist of my comment.
a) Demonstrate to all witnesses that the behaviour is not in line with your values
b) Make the victim of the behaviour feel seen and know they aren't alone
c) Make clear to the person receiving the feedback that you're unhappy
To achieve this same result in private conversations is monumentally more effort, if not impossible. If you pull them into a private conversation, you're still publicly reprimanding them, just without giving clear communication to everyone. Do you wait until later to reprimand in private? Then you need to speak to everyone about what was said and repair the damage that the delay in speaking up caused.
However, there are plenty of situations where calling out something so publicly would be the wrong thing to do, like pushing bugs to production, as you'd likely be seen to be overreacting. You still want to give the feedback if, say, the team member was ignoring processes. It's just usually better done in private.
(I think 1.9 USD is more realistic than 19 USD for now. I don't want to say the product is bad, it is hard to evaluate it at 19 USD for this simple interaction. For a QA simulation with multiple choices seems quite pricey)
My current logic: I'm optimizing for the individual dev/lead paying out of pocket who wants to start now without asking a manager for approval. The goal is to be below the 'mental friction' threshold for a personal impulse buy.
But for a Team/Enterprise version (where the manager buys it for 5 people), you are absolutely right—the pricing structure needs to look very different.
The intention is that the license covers the Full Library (I'm building 12+ scenarios covering Firing, Performance Reviews, Hiring, etc.).
But your comment proves I failed to communicate that scope more better on the landing page. It looks like a 'Single Level' purchase right now, which is definitely not the value prop. I will revisit my messaging. Thanks for the heads up.
Was there a specific turn in the conversation where you really wanted to just give a hard 'No' or call them out, but felt restricted by the choices?
I'm not a manager and have no interest in becoming one but I have often wondered what is going through a manager's head when they cave to egregious horseshit from executives. I find this simulation really interesting and maybe it might help me empathize my manager more.
"Political capital" is irrelevant and only exists when we permit it to exist.
When we setup our sprint goals we would have built in time to handle random requests aannddd I would have kept in good grace with the vp so that he knows were on the same team even if I say no to the request.
Also, how I respond depends on why the vp decided to backchannel me. If they did because they didnt care about our teams goals (and only theirs) then I might need to escalate to their management to set clear boundaries. If they did so because in the past I forgot about their requests, then I probably need to not forget about their requests.
If they are clearly not looking out for our shared interest (or that of the company) and instead only worried about themselves, maybe slightly narcissistic then Im going to respond in a different tone than if they made a genuine mistake.
I wish there was a bit more context about the overall status of the project - yes it is a risk to ask a dev to context switch, but it is also a risk to deny a trivial request from Gary. If Gary has a meeting with the client later and it goes poorly, that could be in part because of the lack of flexibility of the team to meet Gary's needs. If Gary is a bad leader, he's going to be doing a lot of fly-bye requests. If he is a good leader, he'll do it when it is truly necessary. In my view, writing and running a SQL query should be a quick an easy task even for a Jr Dev. At the end of a sprint, there should be plenty of things to demo even if search doesn't make it into this sprint. Also, I'm a firm believer in natural consequences - if Gary can be made aware of the consequences of bypassing the tech lead, he learns the hard way that it needs to be worth it.
I am genuinely blown away by the feedback and the debate in this thread. To the community—thank you.
Status Update: The HN Traffic came at a tricky time—my payment provider is stuck in "Verification Pending" due to the spike, so the checkout is currently failing.
I’ve switched the button to a Priority Waitlist for now.
If you want to lock in the early-bird pricing ($19 One-Time / Lifetime Access), drop your email there. I’ll send everyone on that list a 20% off code as an apology once I wake up and fix the checkout.
You can also drop your email id if interested in the link: https://forms.gle/NqS6ttLaVGKecuS4A
It is 12:30 AM here in India, so I’m going to grab some sleep. I’ll be back online in ~7 hours to answer every remaining comment.
Keep the feedback coming!
I couldn't sleep peacefully as this checkout was frustrating.
I have now moved to polar.sh for checkout and as a gratitude for the community I have auto-applied a 20% discount for the community.
To the folks who have provided your email ids in waitlist, mailing you in 5 mins.
Back to bed for real now.
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.