Show HN: A simulator for engineers transitioning from IC to management (apmcommunication.com)
Hi HN,
I’m a former C++ dev turned Product Manager.
I’ve noticed many engineers struggle with the "politics" side of things when they become Leads. To help with this, I’m building a text-based simulator.
It is NOT an AI chatbot. It is a hand-crafted, branching narrative (logic tree) based on real experiences.
I just launched the first scenario: "The Backchannel VP."
The Setup: Your VP Engineering is bypassing you and giving tasks directly to your juniors, causing chaos.
Your Goal: Stop the backchanneling without getting fired.
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.
40 comments
[ 1.1 ms ] story [ 71.1 ms ] threadSufficiently 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.
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.
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
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.
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.
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.
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.
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.
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
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.
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?
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.
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.
(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)
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!
Not at all. Real-life communications are not one-off. I would act differently if Gary does this one-time versus repeatedly.