How to Advocate for Your Work Without Shrinking
Confidence in engineering is not volume. It is the willingness to stand behind careful work and speak clearly in rooms that reward hedging.
[ essay ]
You wrote a function that is elegant under constraint. You designed a failure path that treats the user like a person instead of a log entry. Then you opened the pull request and prefaced it with this might not be the best approach — as if care were something to apologize for before anyone read the diff.
Shrinking is a habit learned in rooms that punished certainty in some people and rewarded it in others. Advocacy is not arrogance. It is describing what you built, why you built it, and what tradeoffs you accepted — in plain language, without preemptive surrender.
Stop apologizing for competent work
If you tested the change, documented the edge case, and would stake your on-call pager on the rollback plan, say so. Uncertainty belongs where it is real: I have not load-tested above 10k RPS is honest. Sorry for bothering you attached to a necessary security fix is not.
Your work deserves the same descriptive energy you give the systems you maintain. Name the problem. Name your solution. Invite critique on the merits.
In meetings, lead with the user impact, then the technical approach, then the risks. Hedging every sentence trains stakeholders to hear weakness instead of nuance.
Rejection is not permanent
Proposals get rejected. Features get cut. Projects get shelved. These outcomes are tides — they arrive on schedules you do not control and recede on schedules you only partly influence. A no today is not a verdict on your capacity tomorrow.
Archive the lesson without archiving yourself. What assumption was wrong? What stakeholder needed a diagram instead of a paragraph? What will you bring to the next pitch?
Keep a folder of rejected proposals with notes. It becomes evidence of persistence, not failure — and a library of arguments that get sharper each time.
Take up space that matters
Your voice in code review matters when it catches the bug before merge. Your architectural opinion matters when it saves six months of rework. Your perspective matters when the team has been staring at the same whiteboard long enough to mistake familiarity for truth.
Advocacy is not dominating airtime. It is refusing to disappear when the decision affects code you will maintain. Ask the question. Offer the alternative. Write the doc nobody assigned.
The goal is not to be the loudest person in the room. The goal is to be legible — so the work can be evaluated on what it is, not on how small you made yourself while presenting it.
Practice in low-stakes rooms first
Advocacy is a skill. Rehearse the architecture summary with a peer before the executive review. Write the one-paragraph pitch before the meeting that could decide the quarter. Confidence grows from preparation, not from personality type.
Record a two-minute Loom walking through the design if writing feels insufficient. Visibility is not vanity when it prevents the wrong decision. Bring data when you have it: latency numbers, support tickets, error rates. Evidence is advocacy without volume.
— JV · Dark Heart Labs.