[HN Gopher] Show HN: A simulator for engineers transitioning fro...
___________________________________________________________________
Show HN: A simulator for engineers transitioning from IC to
management
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. Link:
https://apmcommunication.com/scenario/backchannel-vp
Author : pingananth
Score : 58 points
Date : 2026-01-05 15:13 UTC (7 hours ago)
(HTM) web link (apmcommunication.com)
(TXT) w3m dump (apmcommunication.com)
| ttul wrote:
| 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.
| bdcp wrote:
| > Try to convince me this isn't the case.
|
| Have you tried AI to convince you otherwise?
| gordonhart wrote:
| > 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
| pingananth wrote:
| 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!
| wordpad wrote:
| 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.
| pingananth wrote:
| 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.
| DrScientist wrote:
| > 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?
| pingananth wrote:
| Wow, that's a lot of question and convoluted context that
| surely validates it's going to take time for AI to arrive
| there!
| rpdillon wrote:
| 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.
| pingananth wrote:
| 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
| joaomacp wrote:
| 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
| pingananth wrote:
| 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!
| munchbunny wrote:
| 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.
| pingananth wrote:
| 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!
| scott_w wrote:
| 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.
| pingananth wrote:
| '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.
| noident wrote:
| It's often better to say nothing at all rather than to reply
| with an LLM generated response.
| pingananth wrote:
| 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
| leoqa wrote:
| This is clearly another LLM response bud. Stop using it
| to communicate it's too obvious.
| IMTDb wrote:
| 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.
| tonnydourado wrote:
| > 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.
| pingananth wrote:
| 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!
| motbus3 wrote:
| It totally depends who Gary is....
| pingananth wrote:
| haha! Yea, in real life, we be nicer to nice people and
| otherwise right. That kinda logic which simulators suck
| at! :D
| pingananth wrote:
| 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.
| DetroitThrow wrote:
| >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!
| pingananth wrote:
| 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
| StrangeSound wrote:
| Are your responses written by an LLM?
| DetroitThrow wrote:
| >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.
| ryanjshaw wrote:
| > 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.
| motbus3 wrote:
| 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.
| cbeach wrote:
| > 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.
| tonnydourado wrote:
| 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(tm), 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.
| pingananth wrote:
| 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.
| tonnydourado wrote:
| 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".
| pingananth wrote:
| 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.
| holsta wrote:
| > 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.
| pingananth wrote:
| 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!
| DetroitThrow wrote:
| 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.
| pingananth wrote:
| 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!)
| _def wrote:
| On which guidelines are the solutions based on?
| pingananth wrote:
| 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
| tantalor wrote:
| Feedback: The "Get the Advanced Pack ($19)" button links to
| https://apmcommunication.lemonsqueezy.com/checkout which is a 404
| page.
| pingananth wrote:
| 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!
| DJBunnies wrote:
| 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.
| pingananth wrote:
| 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!
| cbeach wrote:
| 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.
| pingananth wrote:
| 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.
| elliot07 wrote:
| 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!
| pingananth wrote:
| 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.
| 6thbit wrote:
| 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.
| pingananth wrote:
| 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.
| mvkel wrote:
| 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.
| cbeach wrote:
| > 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.
| mvkel wrote:
| > 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.
| pingananth wrote:
| 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.
| mvkel wrote:
| All fair points, and agreed. Appreciate this context.
| scott_w wrote:
| > 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.
| mvkel wrote:
| 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.
| scott_w wrote:
| > 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.
| mvkel wrote:
| 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
| scott_w wrote:
| 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.
| motbus3 wrote:
| 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)
| jtokoph wrote:
| 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.
| pingananth wrote:
| 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.
| jtokoph wrote:
| 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.
| pingananth wrote:
| 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!
| pingananth wrote:
| 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.
| stalfosknight wrote:
| I wish there were blunter / more direct responses to choose from.
| pingananth wrote:
| 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?
| stalfosknight wrote:
| 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.
| pingananth wrote:
| 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.
| stalfosknight wrote:
| 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.
| qazxcvbnmlp wrote:
| 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.
| pingananth wrote:
| 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.
| mayhemducks wrote:
| 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.
| pingananth wrote:
| 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.
| pingananth wrote:
| 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!
| aio2 wrote:
| Reminds me of the DOS game Executive Suite, I liked the demo (got
| the best path)!
| alexgotoi wrote:
| 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.
___________________________________________________________________
(page generated 2026-01-05 23:01 UTC)