Have you tried AI to convince you otherwise?

Linking Marshall Brain's ever-relevant novella "Manna" on this: https://marshallbrain.com/manna1

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!

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?

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!

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!

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.

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.

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.

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.

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.

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.

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.

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!

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!

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.

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.

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.

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.

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.

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 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.