Promotions · Primly Community

how to build visibility for promotion when you're in a non-glamorous role like QA or infrastructure

qa_quinn · 3 replies

Been a QA engineer for six years. Two different companies, two different experiences trying to get promoted.

The honest thing about QA and infrastructure roles: the work that makes you excellent at the job is almost entirely invisible when it works. You prevent the outage. You find the bug before it ships. The user never knows. This is good for users and terrible for your promo case.

Promo calibration panels mostly contain product and engineering leaders who are evaluating impact. Impact in their mental model usually means: shipped feature, launched product, increased metric. Prevented thing from breaking does not fit neatly into that frame.

So you have to translate.

How I've made it work:

Quantify the near-misses explicitly. "My regression suite caught this class of defects 8 times in Q3, preventing releases that would have affected 40k users." Numbers. Concrete. Specific.

Own a metric. If you can get your name attached to a quality metric (test coverage, escaped defect rate, deploy reliability), do it. Then show it moving in the right direction because of your work.

Leadership surface area. Volunteer to run a blameless postmortem, write the incident report, present QA strategy to the eng org. The point is being seen making decisions by people above your manager.

Cross-team scope. Infrastructure and QA are often well positioned to do work that spans multiple teams. A testing framework that multiple product teams adopt is a strong senior/staff story.

At Company A, I spent three years being excellent at QA work and got deferred twice. At Company B I spent two years doing the above and got promoted. Same skills. Different packaging. Annoying but true.

3 replies

infra_ines

Infrastructure person here, this is painfully accurate. The best compliment you can get in infra is "we didn't notice anything." Which is also the worst thing for your promo case. I've started writing quarterly impact docs that are basically: here's what didn't break and here's why I'm the reason.

sre_sol

The quarterly impact doc is the move. I also started requesting that my manager include specific system reliability improvements in team updates to leadership. Creates a paper trail of visibility that I don't have to maintain myself.

brand_ben

For what it's worth, as a manager I think QA and infra engineers are chronically underleveled relative to their impact in most orgs. You're right that the translation problem is real and you shouldn't have to do that extra work, but you do. Good framing in this post.