← All guides

Category guide

Writing Great Technical Achievements

Technical people undersell themselves in a specific way: they describe the artifact and skip the consequence. The system gets named, the stack gets listed, and the reader still has no idea whether any of it mattered.

Three things in one sentence

A strong technical achievement holds the technical work, its scale, and what the business got.

The stack is present in both rewrites, but it is not the point. It is the how behind a measured outcome.

The scale numbers engineers forget to state

Scale is the metric most often left out, and it is the one that instantly communicates the difficulty class of the work. A CI/CD pipeline is a school project or a serious platform depending entirely on whether deployment went from four hours to twelve minutes for a team shipping daily. Reach for whichever of these you have:

• Requests per second, or peak versus steady-state load
• Events, records, or transactions per day
• Data volume under management, and how fast it was growing
• Users, tenants, or services depending on the thing you built
• Team and codebase size, for anything about developer experience

When the work was invisible

Infrastructure, refactors, test coverage, and on-call improvements are the hardest technical achievements to write, because the outcome is an absence, the incident that did not happen or the outage nobody noticed. Absences still have numbers.

Seniority changes the emphasis

Early-career achievements can live at the implementation level. Senior ones should show the decision: why this architecture, what tradeoff it bought, what it made possible downstream. "Cut warehouse costs 60% and made queries 8x faster through partitioning and materialized views" is an implementation story. Adding "which let the data team kill a $200K vendor contract" makes it an engineering-leadership story.

The tradeoff you consciously accepted belongs in the sentence too, and almost nobody includes it. "Chose eventual consistency for the notification path to hold write latency under 50ms, accepting up to 3 seconds of propagation delay" tells a staff-level reader more about you than any list of technologies.

Signals that read as senior

Quietly include the maturity markers: testing, observability, reliability numbers, documentation that other teams actually used. Nobody hires for 99.99% uptime by itself, but its presence tells a reviewer you think about what happens after the code ships. The same goes for anything you built that another team adopted without being told to. Internal adoption is the most honest review your work will ever get, and it is a number: how many teams, how soon.

The claim you cannot make alone

Almost all engineering is team engineering, and the temptation on a resume is to quietly drop the team. Do not. Interviewers ask "walk me through how you did that" for exactly this reason, and the answer that begins with "well, the four of us" after a bullet written in the first person singular is the one that ends the conversation.

The fix costs nothing and usually strengthens the sentence, because scope is itself a credential.

Naming your part is not modesty. It is the difference between a claim that survives a follow-up question and one that does not.