The Tale of Impact

Hiring advice repeats itself until it sounds like wisdom. Communicate better. Show curiosity. Take feedback well. Put projects on GitHub. And above all: show impact.

Don't write "managed vulnerabilities." Write what that management changed. Don't list duties. Quantify outcomes. Turn every bullet into a before-and-after story so a stranger can feel the weight of your work in six seconds.

On paper, that sounds reasonable. In practice, it is a fairy tale told by people who already sit close to the scoreboard.

What managers say they want

I keep reading the same themes from hiring managers - in security, in engineering, everywhere adjacent:

• They want candidates who explain their work without being dragged through it.
• They want initiative, not pure ticket execution.
• They want people who metabolize negative feedback instead of defending their ego.
• They want CVs that match seniority, plus side projects that prove you do more than your job description.
• They want impact. Not activity. Impact.

Communication matters, of course it does. A silent genius who cannot describe a decision will struggle in any team. I am not arguing against clarity.

I am arguing against the fantasy that "impact" is a fair filter for how most technical careers actually work.

Most of us did not enter tech to impact people

A lot of people go into tech because they want to work with systems, not audiences. Objects, constraints, failure modes, protocols, code paths. Problems with edges.

That preference is not a defect. It is one of the reasons technology advances. Progress often comes from people who obsess over the problem itself, not from people who obsess over how the obsession will look on a resume.

Yes, communication is useful. No, the people whose life goal is messaging should not be the only ones considered "valuable." Product managers, project managers, and other intermediaries exist precisely because someone has to translate between the people who build and the people who decide. Pretending every engineer must also be a polished impact narrator is how you get hiring theater instead of hiring signal.

Being able to explain your work is better than not being able to. Making "impact storytelling" the entrance exam is something else.

Impact is not equally distributed

Even if you accept the impact gospel, opportunity is not equal.

You can spend years inside the same product and still have outcomes that are hard to measure, easy to dismiss, or owned by someone else on paper. HR will usually say yes. Technicians often will not - unless the effect is loud, visible, and attributed. In most jobs it is not. Quiet infrastructure work, standards mapping, threat modeling that never got political airtime, risk findings that sat unread: all of that can be real labor with weak resume cosmetics.

What is the "impact" of five years reading security standards if, when you pointed at the things that would actually move risk, nobody with authority treated it as a priority? Technicians are often excellent at spotting critical failure points. We are rarely the people who get to take responsibility for fixing them - or credit for having seen them first.

So when a hiring process demands "real impact" from someone whose only organizational contact was a direct manager who said "good job" or "bad job," what they are really asking for is proximity to power, visibility, and attribution. Not competence.

A practical hiring alternative

I am not only complaining. Here is a simpler process for hiring technical talent:

1. Screen for overlap, not mythology. If the candidate knows roughly half the technologies used in the role, they are worth interviewing. The other half is learnable. ATS keyword perfection is not a substitute for judgment.
2. Say the boring truths early. In the interview, state the role, the organizational hierarchy, the direct manager, the salary, and the realistic path for professional growth. Ambiguity is not strategy.
3. Put a technical person in the room. After CV screening by ATS and AI, the technical team should validate ability in situ. That is the whole point of the filter chain. Don't outsource the final call to people who cannot tell signal from resume poetry.
4. Keep the technical bar useful. You do not need a theatrical take-home. You need to see whether the person can interpolate what they already know onto the business's problems.
5. Give dates. If the interview is on Monday, say when a decision is expected - one week, two weeks, whatever is real. Candidates plan lives. Ghosting is not "still reviewing."

None of this requires a novel process. It requires respect for technical judgment and for other people's time.

Stop forcing CV cosplay

Technicians should not be trapped in the loop of rewriting the same career into a new dialect for every posting. Tech skills transfer. People who can reason about systems can pivot across adjacent roles without reinventing their biography every weekend.

Tailoring a CV for a role you actually want is fine. Treating endless CV adaptation as the main professional sport is how the market trains people to sound impactful instead of being useful.

Impact is a useful word when it describes something that happened. It becomes a fairy tale when it becomes the only story hiring is willing to hear - especially from people who were never given the stage, the budget, or the authority to produce the kind of ending recruiters like to read.