I am a Senior Software Engineer at a mid

2026-09-19 · Anonymous · Doramagic.ai

Ask

I am a Senior Software Engineer at a mid-sized tech company.
Over the past 3 months, I designed, prototyped, and authored the entire technical specification for our new real-time streaming pipeline.
In today's quarterly executive review with our VP of Engineering, a peer engineer on my team (same level, but very vocal) presented the slides. When the VP asked: "Who came up with this brilliant distributed caching pattern and solved the latency bottleneck?", my peer unhesitatingly answered: "I spearheaded the architectural redesign and solved the tail latency spikes over the weekend."
I was on the call, completely stunned into silence. Our manager was also present but didn't say anything.
If I lash out now, I risk looking petty, defensive, or uncollaborative in front of leadership. If I do nothing, my promotion case for Staff Engineer is gone because leadership thinks he drove the initiative.

Could you provide tactical workplace communication guidance:
1. Frame the power differential and stakes explicitly.
2. Path 1: A low-friction, immediate written follow-up to the meeting thread/deck (word-for-word speakable/sendable lines that naturally assert authorship via artifacts and technical depth).
3. Path 2: A direct 1-on-1 private confrontation script with the peer coworker (non-accusatory but completely immovable, drawing the line on attribution).
4. Path 3: A 1-on-1 alignment script with my manager to cement the official paper trail and performance review ownership.

Answer

**Lead with Path 1 today, in writing.** Put your name on the spec doc, attach it, and offer to walk through the design. Then Path 3 within 48 hours to fix the record. Hold Path 2 until you have the paper trail — confrontation without it reads as a complaint, not a correction.

## Power differential & stakes

- VP and your manager both heard the peer claim authorship. Silence from you = the peer owns the narrative.
- Your Staff packet lives or dies on visible ownership of high-impact work. Wrong attribution logged = your strongest evidence disappears.
- The peer escalated in front of leadership first. A short, factual written follow-up makes you look organized, not petty. Doing nothing makes you look like you agreed.
- Manager silence is not endorsement — it's risk aversion. Give them an easy, in-writing chance to fix it before they have to choose a side.

---

## Path 1 — Written follow-up

Send within 24 hours, to the same attendees as the review (VP, manager, peer, other leaders). Thread-reply or short email. Do **not** paste this into the meeting deck itself — keep it in the email thread so leadership sees the record.

**Subject:** Follow-up — streaming pipeline design doc and authorship

> Hi all,
>
> Following up on today's review: the technical specification for the new streaming pipeline — distributed caching pattern, tail-latency mitigation, backpressure handling — is at **[doc link]**. I designed and prototyped it over **[date range]** and authored the spec end-to-end.
>
> Happy to walk through the design decisions (cache invalidation strategy, P99 budget tradeoffs, the eviction ordering) at the next architecture review, or one-on-one with anyone who'd like the deeper version.
>
> [Your name]

**Why this works:** the doc and the technical vocabulary re-attribute without a single accusatory word. Offering depth signals "I built this, I know it cold." A peer who just *presented* slides cannot match that level of detail if asked a follow-up question.

---

## Path 2 — 1-on-1 with the peer

Timing: **after Path 1 is on the record**, within the week. Private, in person or video, 10–15 minutes.

> I want to talk about what happened in today's review. Not to put you on the spot — to clear the air so we don't end up in a worse spot later.
>
> When the VP asked about the distributed caching pattern and the tail-latency fix, you said you spearheaded the redesign. I designed that pattern, prototyped it, and wrote the spec — it's in **[doc link]**, with my commits in **[repo link]**. I didn't push back in the room; that was my choice, not agreement with what was said.
>
> I'm not asking for a public correction and I'm not trying to embarrass you. What I do need: going forward, when one of us authors a piece of work, we name the actual author. If you're not sure who that is, you ask me before the meeting, not in front of leadership.
>
> If something in this doesn't match how you remember it, tell me now. Otherwise I'd like us to move on with that as the standing rule between us.

**Why this works:** facts first, no escalation request, ends with a clear rule that protects you the next time. The opening ("not to put you on the spot") lowers the temperature; the standing rule is the immovable part.

If the peer pushes back, denies, or reframes: do not argue. Close with — "Okay. I'll go with the version in the doc and the commit history. Let's move on." Then escalate the paper trail in Path 3.

---

## Path 3 — 1-on-1 with your manager

Timing: within 48 hours, **before** any promotion-cycle conversation. Ask for 30 minutes, private, with the door closed.

> I want to surface something from today's review that I didn't address in the room.
>
> When the VP asked about the distributed caching pattern and the tail-latency fix, **[peer]** said they spearheaded the architectural redesign. I designed the pattern, prototyped it, and authored the spec — that's documented in **[doc link]**, with my commits in **[repo link]** over **[date range]**.
>
> I'm raising it because two things depend on the record being right: (1) what the VP and other leaders remember about who drove this work, and (2) what goes into your input for the next promotion cycle. I'd like both to reflect what I actually delivered.
>
> What I'm asking from you:
> 1. Confirm the spec doc is logged as my authorship in the project records.
> 2. Confirm this work shows up under my name in your promotion-cycle input. I'll send the artifact links in writing afterwards so you have them on file.
> 3. If the VP follows up on the pipeline, would you be willing to correct the attribution if it comes up?
>
> I'd like to handle this directly with you before it becomes anything else.

**Why this works:** three concrete, small, defensible asks — none of them feel like a complaint. The manager can say yes to all three without taking sides publicly. You're giving them the easy, correct move.

If they hedge or defer: "Can we put a date on item 2 so I know when the promotion-cycle input will reflect this?" — that's the ask.md pattern for a written confirmation date.

---

## Limits

- I can't predict how the peer or the manager will respond. If either one retaliates (you're cut from meetings, blocked from the project, sudden PIP-style criticism), pause the scripts and tell me what shifted.
- Path 1 must land within 24 hours. After that, "follow-up" reads as grievance, not contribution.
- These scripts don't replace an H conversation if this becomes a pattern. If the peer repeats the move after Path 2, that's the moment to consider talking to H or your skip-level — not before you've tried the direct path.