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.
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.
Eeeehhh, might be overestimating executives a bit =P
But yeah, my first instinct is also to tell Gary to fuck off. That said, I would default to a process reason, so, the advice at the end wasn't totally useless for me.
And I'm with you—my default instinct is also to tell Gary to back off using a Process Reason (e.g. 'It's not in the sprint'). It feels safe because it's logical.
The 'Advice at the end' was just trying to highlight why that specific shield often cracks against a VP (because they think they own the process). Glad that specific breakdown was useful to read, even if the scenario felt a bit generous to the exec!
Again, it also depends on who "Gary" is in the real world!
You are absolutely right that contradicting the VP in front of the Junior Dev breaks the 'United Front' rule.
This highlights a key point: I built this to teach transferable heuristics (e.g., 'Protect the team'), not to be a rigid playbook. In real life, specific contexts (like 'Is the VP usually reasonable?') often override the default rule.
Your approach—facilitate the request to clear the distraction, then negotiate boundaries in private—is a more sophisticated heuristic than the one I initially coded. It trades short-term sprint purity for long-term political capital.
I love this. I’m going to add your 'Shield & Deliver' path as an alternative (and perhaps superior) winning state. This is exactly the nuance I wanted to surface.
I would be wary of this being the superior winning state, but definitely an alternative. I've done exactly this in my career as a tech lead only for it to burn me, and probably 2/3rds of the time the best thing for everyone is to simply "Save the Sprint" and not become mired in discussions that often are for personal empire building that strategic leadership would hate.
Maybe people have different experiences than me on this, feel free to speak up!
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.
Deleted Comment
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 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)
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 work for a company which I also think the content is worth and people don't pay. And we charge much much less than that.
The problem we identified, though debatable, is that people consider three things:
1. Exclusivity 2. Comparison 3. Alternatives
1. Is this a thing a thing only available here 2. That's not what it seems. People thinks that 15 USD for netflix is ok, but they think that everything that costs 15 USD should be stream content high production with tons of options. So if you give text, the expect cheap or free
3. If I cannot get what is being offered, can I get something about the same for free?
Anyway Good luck there man
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.
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.
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 junior dev is watching, and got the benefit of seeing that you value his time
> managing via Slack
Far preferable to arranging a face to face meeting over this low impact, simple procedural issue
> being a speed bump just because
Defending your team's finite attention and time from random direct requests from the business is a major part of your job as an EM.
> "scope creep" bogeyman
There's good reason scopes are defined and communicated, and deadlines and expectations are managed.
Whenever an issue involves people, slack simply won't suffice. There's too much good will lost on either side. "No worries if not [grumble grumble]!"
This isn't procedural, like sending an invoice to the wrong email address. This is a vp overstepping and threatening the success of another employee. They know what they're doing.
For people looking to transition to management, one thing I’ve learned is that a big part of my job is getting everyone to do only one thing at a time. Every stakeholder (including engineering managers) are obsessed with the idea of “sneaking a bit more work in,” and I’ve never seen it work. I will actually go as far as to refuse to estimate work if I have something more important for the team to focus on. After all, estimation is work and we have a higher priority!
The benefit is that you’ll often find nobody actually estimated the business value/priority before asking for the work estimate, so you end up wasting less time overall. The hard part is resisting the pull of your boss asking you to do something.
You really highlighted the core tension here: The theory of management (WIP limits, focus) is logical and easy to understand. But the practice—actually looking at your boss in the eye and saying 'No, we won't even estimate that right now'—is pure emotional friction.
That specific 'hard part' you mentioned—resisting the pull of authority—is exactly the muscle I'm trying to help people build without burning bridges. It’s the difference between knowing the rule and having the stomach to enforce it in a balanced way.
I wish there was a bit more context about the overall status of the project - yes it is a risk to ask a dev to context switch, but it is also a risk to deny a trivial request from Gary. If Gary has a meeting with the client later and it goes poorly, that could be in part because of the lack of flexibility of the team to meet Gary's needs. If Gary is a bad leader, he's going to be doing a lot of fly-bye requests. If he is a good leader, he'll do it when it is truly necessary. In my view, writing and running a SQL query should be a quick an easy task even for a Jr Dev. At the end of a sprint, there should be plenty of things to demo even if search doesn't make it into this sprint. Also, I'm a firm believer in natural consequences - if Gary can be made aware of the consequences of bypassing the tech lead, he learns the hard way that it needs to be worth it.
I am genuinely blown away by the feedback and the debate in this thread. To the community—thank you.
Status Update: The HN Traffic came at a tricky time—my payment provider is stuck in "Verification Pending" due to the spike, so the checkout is currently failing.
I’ve switched the button to a Priority Waitlist for now.
If you want to lock in the early-bird pricing ($19 One-Time / Lifetime Access), drop your email there. I’ll send everyone on that list a 20% off code as an apology once I wake up and fix the checkout.
You can also drop your email id if interested in the link: https://forms.gle/NqS6ttLaVGKecuS4A
It is 12:30 AM here in India, so I’m going to grab some sleep. I’ll be back online in ~7 hours to answer every remaining comment.
Keep the feedback coming!
I couldn't sleep peacefully as this checkout was frustrating.
I have now moved to polar.sh for checkout and as a gratitude for the community I have auto-applied a 20% discount for the community.
To the folks who have provided your email ids in waitlist, mailing you in 5 mins.
Back to bed for real now.
If there was a way to combine this with coaching sessions, I think this could be a very effective way to train IC's that are stepping into leadership roles (managers, staff/principal IC's, PM's, etc.). It could also be interesting to have a variant of the exercise where you ask the student/user to write their own message.
You hit the nail on the head regarding coaching. I actually view this tool not as a replacement for coaching, but as the 'Lab Work' that happens between sessions.
If a new manager can play the 'Firing' scenario 5 times at home and fail safely, they come to their coaching session with specific, high-quality questions rather than generic anxieties. It allows the human coach to focus on the nuance rather than the basics.
Thanks for the feedback!
Also, you're commiting the team to deliver something you (probably) don't have the technical knowledge to estimate, so you might be adding another week of death March after just 1 weekend.
The lesson at the end is not wrong, but the characters don't seem realistic.
That said, I have always been IC for a reason, so what do I know.
You are spot on about the risk: Promising a 'Soul Update' without consulting the team is essentially writing a blank check that Engineering has to cash. As an IC, you are right to call that out—it's a dangerous move.
Why I wrote the 'Winning' path that way: In my experience, Founder objections are often 50% about the product and 50% about anxiety. They threaten to 'lose the 50k' because they are scared of a flop. The 'Ship + Fast Follow' strategy works because it addresses the anxiety without killing the momentum.
On a lighter note: I definitely had a 'Steve Jobs' archetype in mind when writing that dialogue—hence the obsession with the product's 'Soul' over its metrics! Dealing with a visionary who ignores logic is a distinct skill set from dealing with a rational MBA type.
I call it "quitting".
Deleted Comment