You finish a project, feel stuck, and open another framework's docs. The impulse makes sense: a new API produces visible progress, samples compile, and the résumé gets another line. That does not fix a common mid/senior problem: showing, with evidence, that you can keep systems up, amplify other people, and communicate hard decisions.
The useful question stops being "which technology is missing?" and becomes: what evidence of my work could a skeptical peer open and verify? If the answer is only a tool list, the bottleneck may not be knowledge. Installing a dependency is simply more comfortable than organizing the proof. The dependency, at least, does not schedule a career conversation.
Knowing how to use is not the same as sustaining
Knowing a technology lets you ship a happy path: set up the project, know the APIs, get a feature live. Sustaining means closing the operational loop:
- detect that the user is getting an error;
- separate symptom, trigger, and contributing causes;
- restore the service with a safe action;
- record what happened without hunting a villain;
- ship a durable change that reduces recurrence or impact.
The Shakespeare Search postmortem published by Google makes that difference concrete. The incident involves rising HTTP errors, a latent failure exposed by load, and restore/prevent actions. The point here is not that environment's numbers, nor a heroic retelling. It is the shape: detection, mitigation, explanation, follow-up. The answer was not "rewrite everything with this week's framework."
To observe your operational capacity, pick a service you own and answer: if it pages at 3 a.m., can you find the user impact, run the last safe restore path, and point to an improvement that remained after the incident? If not, the fix is not another API. It is a user-facing alert, one runbook step you actually test, and a note or PR the team can reopen.
Watching known metrics also does not close the topic. DORA on monitoring and observability includes customer-perceived state, tools for production debugging, and the ability to investigate properties nobody predicted. A dashboard that does not trigger a decision is corporate decoration with auto-refresh.
Three axes to make seniority checkable
The split below is an editorial lens for this article, not an official career model. It organizes evidence on three axes: system, people, and communication. The goal is not a seniority score. It is to find where verifiable artifacts are missing.
| Axis | Question | Evidence a peer can verify | If it is empty | How to observe safely |
|---|---|---|---|---|
| System | Do you observe, restore, and improve the current system? | dashboard tied to a decision, exercised runbook, postmortem or prevention PR | test one restore path and leave a small improvement | controlled environment, existing production alert, change history |
| People | Does your work increase someone else's capacity? | reviewed design, someone sponsored into visible work, or a delivery made by a person you coached | pick a real delivery, define expected autonomy, record the support | feedback from that person, delivered artifact, authorship preserved |
| Communication | Do your decisions survive outside a meeting? | written proposal, decision with alternatives, or a reviewable incident write-up | write context, decision, impact, and gap on one page | async peer review, no sensitive data, no extra names |
This lens blocks two shortcuts. The first is treating title as proof: the StaffEng archetypes guide shows different shapes — Tech Lead, Architect, Solver, Right Hand — not one universal ladder. The second is hiding leadership work under "helping." Unblocking a delivery, onboarding someone, and noticing abandoned work are technical contributions, but they need a result and an artifact.
There is also a practical difference between mentorship and sponsorship. Mentorship offers guidance; sponsorship puts someone's name in front of a visible opportunity. Lara Hogan on sponsorship turns good intent into an observable action. If the people axis is empty, pick someone for a real contribution, nominate them to present or lead the next step, then check whether they got credit and space — not whether you appeared as the savior in the meeting.
How to tell an incident without dumping a résumé
A strong technical story does not need drama, names, or twenty tickets. It needs another person to understand context, decision, and consequence. Google SRE's blameless postmortem culture looks at contributing causes and fixes systems and processes, assuming people decided with the information they had.
Use this short structure:
- Situation: which service, which visible impact, how it was detected;
- Action: which decisions you made — declare the incident, revert, shed load, add capacity, or fix a playbook;
- Result: how the service was restored and which preventive action actually shipped;
- Evidence: an allowed link to a postmortem, PR, runbook, or panel that confirms the story.
Say "I" only for the action that was yours. For the rest, describe the team and the system. Strip names, private messages, character judgments, and the lazy thesis that "the culture is broken." If the write-up still reads like a culture war, rewrite causes as observable conditions and turn each condition into an action with an owner. Then ask a colleague to mark what they cannot confirm. That review is the safe observation; publishing internal details to look experienced is not.
When learning another framework solves a real problem
A new framework is not forbidden. It just has to answer a named problem. Choose Boring Technology talks about "innovation tokens": each new technology adds failure modes, operations, and cognitive cost the team does not know yet. Known technology also fails, of course, but usually in ways someone already wrote down. An underrated luxury.
Before adopting something new, write answers to five questions:
- Which production or business problem fits in one sentence?
- How would it be solved with the current stack?
- What makes that solution prohibitively expensive or inadequate?
- Who owns alerts, docs, restore, and migration?
- If there is overlap, what is the plan to retire the previous solution?
The framework helps when the current limit is demonstrable, the failure modes can be operated, and someone owns the migration. It only postpones the conversation when the problem is "I want to learn," nobody can narrate the last incident, and the team accumulates two solutions for the same job.
The remediation is simple: record the five answers in a short decision and first test the alternative on the current stack. Observe cost, risk, and operability with data the team can already collect, not with a product-page promise. If the new option wins, adopt it with an exit plan for the old one. If there is no answer to question three, keep the stack and spend the energy on the axis with no evidence.
The 30-minute experiment
Block half an hour. The expected result is the emptiest axis and a single artifact to produce — not an imaginary seniority percentage.
Minutes 0–5: list at most three pieces of work from the last 90 days.
Minutes 5–15: for each, note what it was, what you did, the impact versus the goal, and the complexity you faced. Attach one evidence: document, PR with a rollback path, dashboard, postmortem, or a delivery from someone you coached. No artifact, mark UNVERIFIED.
Minutes 15–25: describe an incident or near-incident with situation, impact, your action, result, and a follow-up that shipped. No names, no score-settling. If there was never an incident, use a risky change and explain how it would be reverted.
Minutes 25–30: sort the items into system, people, and communication. The axis with the most blanks or UNVERIFIED is the next investment.
If you continue over the weekend, produce only one artifact: exercise a runbook step for system; record an autonomous delivery or a sponsorship for people; turn the decision into a reviewable page for communication. Send it to a colleague and ask: "what here can you not verify?"
That is the next step: run the 30-minute experiment before opening another framework tutorial. If a real technical problem then requires the new tool, good — now you have a reason. If it does not, you also got an answer, without downloading half the internet to obtain it.