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.
I agree that this is true 90% of times but if you included office politics in the equation sometimes it is not.
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.
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!
This is a brilliant deconstruction. You’ve highlighted a flaw in my 'Correct' path: I optimized for Process Protection (Save the Sprint), but you are optimizing for Relationship Preservation (Save the VP's face).
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 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!
This is exactly why management is hard to unit test!
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
When the traffic was peak, I did use LLM to polish my responses.
Later, I started replying without an LLM.
No, AI agents at work. This is an individual at work!
> Much better solution is to help you junior dev solve the problem
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 the VP requires these numbers and went as far as back channeling you there is probably a quite good reason for that.
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.
I think the scenario is correct, the analysis for each choice seems to be realistic but this dialog would be finished after a couple of interactions for sure.
(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)
Fair point! $19 for just this one interaction would be steep.
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.
I would argue that the price is too low. Any price under $200 is practically free to the employee with so many companies providing learning and development budgets.
You hit the nail on the head regarding L&D psychology. For corporate budgets, $19 signals 'toy,' not 'training.'
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.
Many companies have discretionary budgets fully in control of the employee. For example, I had $2,500 per year to spend on valid expenses without needing prior approval.
That sounds like a manager budget.
My rationale of 19$ is considering the global audience and budget.
I do have a vision of introducing team licenses later but currently focused on gathering volume and feedback!
I appreciate this pushback. You are describing Leadership (Mission, Strategy, Listening), whereas this scenario is simulating Management (Protection, Filtering, execution).
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.
It's not one or the other, but should align with the culture. Like the old board chair of Starbucks said: if you're going to be an asshole, be a really good one.
Not disagreeing, but adding a cultural context. So if your culture is a trading floor like boiler room, sure, shame publicly, all day long. Maybe not at a cancer nonprofit
I think there's more nuance to what I'm saying: it's not just based on your company culture but on the situation you're faced with. Let's make my example more concrete. Let's say a member of your team calls another team member stupid for an honest mistake, in a public setting (so was witnessed by the rest of your team). Telling that person there and then "that's a disrespectful way to speak to a colleague and is against our values" will:
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.
> far preferable to arranging a face to face meeting over this low impact, simple procedural issue
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.
Id agree if it were a VP of Eng (total mess) or Product (should know and be bought in on the dev process) but this is a VP of sales. Depending on the company they can be much more operational and I would just assume that they asked the individual due to familiarity or happenstance and didn't understand the level of effort to deliver.
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.
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.
'Estimation is work' is a maxim I wish more organizations understood!
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.
Fair check! I use it to polish my phrasing (especially trying to keep up with this thread volume), but the 'scars' and the management experience behind the comment are 100% human. Point taken though—I'll try to keep it rawer
My first go at this I got a C- for sending mixed/inconsistent signals to Gary by at first agreeing to his request, but then saying no to a follow-up request.
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 hear you!
A good leader will do it only when it is truly necessary but we never know this ( atleast until we really know someone! ) Probably adding more context on Gary's nature of ask will help. Also, as mentioned in other replies, the point here is to provide heuristics and not a playbook.
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.
This is cool. It feels a lot like business school cases where you get a packet of context and need to think about how to navigate the many factors at play, though with more direct practice, much less of the social dynamics of a class discussion, and less of a main character storytelling vibe, which are all good things IMO.
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.
That 'MBA case study' feeling is exactly what I was aiming for—moving away from passive video consumption to active decision-making.
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.
I don't agree with the optimal path of The HiPPO War. The founder very explicitly said he thinks shipping the current user experience is Bad™, that he'd rather loose the 50k in ads. It doesn't make sense that he would accept shipping it anyway because "We can ship a 'Soul' update" later.
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.
Well, while this may be the ideal strategy, most of us have bills to pay and some of them are more tolerant than others. Also, there is no guarantee that the next boss is going to be logical. So, this is prevention and not cure.
It felt nice finding the optimal path. I found it nice as a hook to pay for the whole course, I think I'd enjoy this hands-on approach to learning, congrats for making it feel appealing!
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
Hey, Thanks! I'm really glad the 'game' mechanic landed well. I wanted to avoid the 'video lecture' fatigue.
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!
Wow, this is really great. These vignettes could make a good, short book that doesn't get into weird diatribes and instead actual experiences with engineering orgs. This is basically what I want to show to senior/staff engineers about how to do this back and forth.
I wanted to pre-order, but the link doesn't let me.
Thank you! That specific use case—helping Senior/Staff engineers visualize the 'back and forth'—is exactly where I think the biggest gap is. It’s hard to learn negotiation from a static blog post.
On the Pre-order: I’m sorry about that! The payment gateway is currently stuck in 'Verification Pending' (bad timing with the HN hug).
If you can avoid this transition I would recommend it. Say no, take a pay cut, feign ignorance.
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.
That misery is real. That's actually a hidden use case for this simulator: play it, realize you hate the politics, and happily decide to stay an IC before accepting the promotion!
The simulator is an excellent reminder that engineering managers sign up for an eternity in the Kobayashi Maru scenario, and there's no way to Captain Kirk it, either.
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.
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.
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.
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.
Oof. Thanks for flagging! It looks like the HN traffic spike (or a config error on my end) tripped the payment gateway safety.
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!
This looks great and I see it’s potential, but only for startups and 1-2 layers of management. I can’t imagine a scenario where a VP would make a direct request to a dev in a corporation.
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
This is cute. I think within 36 months AI will replace middle management in software companies. This will happen because, ironically, today’s middle managers will switch back to being individual contributors, using AI to contribute PRs once again (who doesn’t prefer this anyway?).
Sufficiently powerful AI can become the middle manager of everyone’s dreams. Wonderfully effective interpersonal skills, no personality defects. Fair and timely feedback.
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?
If we use outsourcing as proxy for what jobs will move to AI first, management jobs will be the last to be replaced.
Managing is about building relationships to coordinate and prioritize work and even though LLMs have excellent soft skills, they can't build relationships.
Spot on. AI might simulate the message perfectly, but it can't hold the social capital and trust required to actually move a team when things get tough.
> Sufficiently powerful AI can become the middle manager of everyone’s dreams. Wonderfully effective interpersonal skills, no personality defects. Fair and timely feedback.
> The girls liked it because Manna didn’t hit on them either. Manna simply asked you to do something, you did it, you said, “OK”, and Manna asked you to do the next step.
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.
I actually ran this specific 'Backchannel VP' scenario through raw GPT-4 before building the hard-coded version, and the results were surprisingly 'meh.'
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!
I'm not sure you understand the job. Do you have management experience? It's mostly about discussion, agreeing on how to proceed, and building relationships. It's not clear to me at all that people will want to work for AI instead of a real human that cares. I certainly wouldn't.
Agreed. People work for people, not APIs. That human connection and the feeling that your manager actually cares ( hopefully :D ) is the one thing you can't automate away
Glad you were able to crack it!
Thanks for sharing about the Executive Suite DOS game - wasn't aware of this. Truly amazing considering it was conceived and well executed back then in 1980's!
Which one you tried?
The level is easy for most of it except for one Product Management scenario.
Even otherwise based on your experience and skills, you can find the optimal path on first play. Nothing wrong about it. All good!
I would have liked to tell the VP "No, we're not doing this and I don't appreciate being bypassed like this. Don't do this again." or something like that that. In my view, VP the Sales has no business meddling with my juniors.
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.
Yes, because the manager is not paid anymore to do code and code review but to preserve political capital, manage team and other stakeholders as well.
Glad that it provided a perspective and see your manager with more empathy.
Well, I'm not sure this particular example helps me see my manager with more empathy. I think the manager in your example is too concerned with people pleasing.
"Political capital" is irrelevant and only exists when we permit it to exist.
I messed around a bit and found it annoyingly rigid. In reality I would have already established clear communication and rapport with both the ic and the vp.
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.
Interesting! I haven't come across any teams communicating to sales on sprint goals. ofcourse this could be an early stage startup but that's exactly my point as well. I provide heuristics and guidelines and not a playbook. The final decision will depend on multiple contexts like - your org, stage of the product, org culture, nature of your sales VP and yours, revenue, and a lot more. This is why it is subjective and not deterministic.
Honestly, may be an unpopular opinion but I disagree with the ideal path. This may be on-paper the correct path for this sim, but in my experience this will lead you to bad career + team outcomes. There's better options based on my experience:
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!
I don't think this is unpopular at all—I think it’s actually the 'Senior/Pragmatic' view.
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.
Off base.
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.
I agree that this is true 90% of times but if you included office politics in the equation sometimes it is not.
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.
> there is probably a quite good reason for that.
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.
Haha, fair point on overestimating them!
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!
It totally depends who Gary is....
haha! Yea, in real life, we be nicer to nice people and otherwise right. That kinda logic which simulators suck at! :D
This is a brilliant deconstruction. You’ve highlighted a flaw in my 'Correct' path: I optimized for Process Protection (Save the Sprint), but you are optimizing for Relationship Preservation (Save the VP's face).
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 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!
This is exactly why management is hard to unit test!
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
Are your responses written by an LLM?
It's crazy that it set off our alarms at the same time. One agreement -- oh, nice human. Two -- what is this!?
When the traffic was peak, I did use LLM to polish my responses. Later, I started replying without an LLM. No, AI agents at work. This is an individual at work!
Exactly what I was thinking. Is someone letting their ai agent do _all the work?
I'll my hat if they aren't.
> Much better solution is to help you junior dev solve the problem
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 the VP requires these numbers and went as far as back channeling you there is probably a quite good reason for that.
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.
> you can only really get them to surface that
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.
I think the scenario is correct, the analysis for each choice seems to be realistic but this dialog would be finished after a couple of interactions for sure.
(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)
Fair point! $19 for just this one interaction would be steep.
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.
I would argue that the price is too low. Any price under $200 is practically free to the employee with so many companies providing learning and development budgets.
You hit the nail on the head regarding L&D psychology. For corporate budgets, $19 signals 'toy,' not 'training.'
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.
Many companies have discretionary budgets fully in control of the employee. For example, I had $2,500 per year to spend on valid expenses without needing prior approval.
That sounds like a manager budget. My rationale of 19$ is considering the global audience and budget. I do have a vision of introducing team licenses later but currently focused on gathering volume and feedback!
Punishing in public; managing via Slack; being a speed bump just because, all in service of preventing the "scope creep" bogeyman.
This is good management?
You can almost see how a toxic workplace experience seeped into OP's world model.
People just want to feel heard. Show up to listen, zoom out to be strategic, think about the mission.
I appreciate this pushback. You are describing Leadership (Mission, Strategy, Listening), whereas this scenario is simulating Management (Protection, Filtering, execution).
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.
All fair points, and agreed. Appreciate this context.
> Punishing in public
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.
It's not one or the other, but should align with the culture. Like the old board chair of Starbucks said: if you're going to be an asshole, be a really good one.
> It's not one or the other
I'm not sure if you're disagreeing with me or not, given that was the gist of my comment.
Not disagreeing, but adding a cultural context. So if your culture is a trading floor like boiler room, sure, shame publicly, all day long. Maybe not at a cancer nonprofit
I think there's more nuance to what I'm saying: it's not just based on your company culture but on the situation you're faced with. Let's make my example more concrete. Let's say a member of your team calls another team member stupid for an honest mistake, in a public setting (so was witnessed by the rest of your team). Telling that person there and then "that's a disrespectful way to speak to a colleague and is against our values" will:
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.
> Punishing in public
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.
> far preferable to arranging a face to face meeting over this low impact, simple procedural issue
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.
Id agree if it were a VP of Eng (total mess) or Product (should know and be bought in on the dev process) but this is a VP of sales. Depending on the company they can be much more operational and I would just assume that they asked the individual due to familiarity or happenstance and didn't understand the level of effort to deliver.
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.
I like the demo.
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.
'Estimation is work' is a maxim I wish more organizations understood!
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.
It's often better to say nothing at all rather than to reply with an LLM generated response.
Fair check! I use it to polish my phrasing (especially trying to keep up with this thread volume), but the 'scars' and the management experience behind the comment are 100% human. Point taken though—I'll try to keep it rawer
Deeply, deeply insulting.
This is clearly another LLM response bud. Stop using it to communicate it’s too obvious.
My first go at this I got a C- for sending mixed/inconsistent signals to Gary by at first agreeing to his request, but then saying no to a follow-up request.
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 hear you! A good leader will do it only when it is truly necessary but we never know this ( atleast until we really know someone! ) Probably adding more context on Gary's nature of ask will help. Also, as mentioned in other replies, the point here is to provide heuristics and not a playbook.
Founder Update (12:30 AM IST)
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!
Update ( 6 AM IST )
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.
This is cool. It feels a lot like business school cases where you get a packet of context and need to think about how to navigate the many factors at play, though with more direct practice, much less of the social dynamics of a class discussion, and less of a main character storytelling vibe, which are all good things IMO.
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.
That 'MBA case study' feeling is exactly what I was aiming for—moving away from passive video consumption to active decision-making.
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!
I don't agree with the optimal path of The HiPPO War. The founder very explicitly said he thinks shipping the current user experience is Bad™, that he'd rather loose the 50k in ads. It doesn't make sense that he would accept shipping it anyway because "We can ship a 'Soul' update" later.
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 actually hit on a very real tension here.
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 have a strategy for dealing with bosses that ignore logic, it's been foolproof so far, going on 14 years of experience.
I call it "quitting".
Well, while this may be the ideal strategy, most of us have bills to pay and some of them are more tolerant than others. Also, there is no guarantee that the next boss is going to be logical. So, this is prevention and not cure.
It felt nice finding the optimal path. I found it nice as a hook to pay for the whole course, I think I'd enjoy this hands-on approach to learning, congrats for making it feel appealing!
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
Hey, Thanks! I'm really glad the 'game' mechanic landed well. I wanted to avoid the 'video lecture' fatigue.
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!
Wow, this is really great. These vignettes could make a good, short book that doesn't get into weird diatribes and instead actual experiences with engineering orgs. This is basically what I want to show to senior/staff engineers about how to do this back and forth.
I wanted to pre-order, but the link doesn't let me.
Thank you! That specific use case—helping Senior/Staff engineers visualize the 'back and forth'—is exactly where I think the biggest gap is. It’s hard to learn negotiation from a static blog post.
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!)
If you can avoid this transition I would recommend it. Say no, take a pay cut, feign ignorance.
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.
That misery is real. That's actually a hidden use case for this simulator: play it, realize you hate the politics, and happily decide to stay an IC before accepting the promotion!
The simulator is an excellent reminder that engineering managers sign up for an eternity in the Kobayashi Maru scenario, and there's no way to Captain Kirk it, either.
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.
Glad that you chose happiness.
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.
> It’s a short, specific puzzle. I’d love to know if you think the "Correct" path I designed matches your real-world experience, or if I’m off base.
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.
Glad the logic held up!
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 like the UI.
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.
Glad you dig the UI!
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.
Feedback: The "Get the Advanced Pack ($19)" button links to https://apmcommunication.lemonsqueezy.com/checkout which is a 404 page.
Oof. Thanks for flagging! It looks like the HN traffic spike (or a config error on my end) tripped the payment gateway safety.
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!
Very cool! It would be great to have this kind of simulator for negotiating other kinds of scenarios as well, hiring, salary, promotions, etc.
Great feedback that!will add it to the roadmap!
This looks great and I see it’s potential, but only for startups and 1-2 layers of management. I can’t imagine a scenario where a VP would make a direct request to a dev in a corporation.
Thanks for the feedback. Sure, it's not a scenario in a corporation but startups?
On which guidelines are the solutions based on?
It's a mix of personal scars and peer review.
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
This is cute. I think within 36 months AI will replace middle management in software companies. This will happen because, ironically, today’s middle managers will switch back to being individual contributors, using AI to contribute PRs once again (who doesn’t prefer this anyway?).
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.
> Try to convince me this isn’t the case.
:-)
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?
Wow, that's a lot of question and convoluted context that surely validates it's going to take time for AI to arrive there!
If we use outsourcing as proxy for what jobs will move to AI first, management jobs will be the last to be replaced.
Managing is about building relationships to coordinate and prioritize work and even though LLMs have excellent soft skills, they can't build relationships.
Spot on. AI might simulate the message perfectly, but it can't hold the social capital and trust required to actually move a team when things get tough.
> Try to convince me this isn’t the case.
Have you tried AI to convince you otherwise?
> Sufficiently powerful AI can become the middle manager of everyone’s dreams. Wonderfully effective interpersonal skills, no personality defects. Fair and timely feedback.
Linking Marshall Brain's ever-relevant novella "Manna" on this: https://marshallbrain.com/manna1
> The girls liked it because Manna didn’t hit on them either. Manna simply asked you to do something, you did it, you said, “OK”, and Manna asked you to do the next step.
Lots of great replies - thank you, everyone.
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.
This comment is visionary. Fingers crossed to see how it pans out!
I actually ran this specific 'Backchannel VP' scenario through raw GPT-4 before building the hard-coded version, and the results were surprisingly 'meh.'
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!
I'm not sure you understand the job. Do you have management experience? It's mostly about discussion, agreeing on how to proceed, and building relationships. It's not clear to me at all that people will want to work for AI instead of a real human that cares. I certainly wouldn't.
Agreed. People work for people, not APIs. That human connection and the feeling that your manager actually cares ( hopefully :D ) is the one thing you can't automate away
Reminds me of the DOS game Executive Suite, I liked the demo (got the best path)!
Glad you were able to crack it! Thanks for sharing about the Executive Suite DOS game - wasn't aware of this. Truly amazing considering it was conceived and well executed back then in 1980's!
Apparently I found the optimal path on first play?
Which one you tried? The level is easy for most of it except for one Product Management scenario. Even otherwise based on your experience and skills, you can find the optimal path on first play. Nothing wrong about it. All good!
I wish there were blunter / more direct responses to choose from.
That’s interesting! I definitely defaulted to 'Diplomatic/Safe' options for this version.
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 would have liked to tell the VP "No, we're not doing this and I don't appreciate being bypassed like this. Don't do this again." or something like that that. In my view, VP the Sales has no business meddling with my juniors.
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.
Yes, because the manager is not paid anymore to do code and code review but to preserve political capital, manage team and other stakeholders as well. Glad that it provided a perspective and see your manager with more empathy.
Well, I'm not sure this particular example helps me see my manager with more empathy. I think the manager in your example is too concerned with people pleasing.
"Political capital" is irrelevant and only exists when we permit it to exist.
I messed around a bit and found it annoyingly rigid. In reality I would have already established clear communication and rapport with both the ic and the vp.
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.
Interesting! I haven't come across any teams communicating to sales on sprint goals. ofcourse this could be an early stage startup but that's exactly my point as well. I provide heuristics and guidelines and not a playbook. The final decision will depend on multiple contexts like - your org, stage of the product, org culture, nature of your sales VP and yours, revenue, and a lot more. This is why it is subjective and not deterministic.
Honestly, may be an unpopular opinion but I disagree with the ideal path. This may be on-paper the correct path for this sim, but in my experience this will lead you to bad career + team outcomes. There's better options based on my experience:
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!
I don't think this is unpopular at all—I think it’s actually the 'Senior/Pragmatic' view.
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.