AIO APEX
es
Works best with a model that has a large context window and a plain, specificity-over-flattery style — Claude Opus 4.7, GPT-5.4, or Gemini 3 Pro. Smaller or distilled models tend to round vague claims up into confident-sounding prose instead of flagging them as weak, which defeats the entire point of this prompt.You are six weeks out from a promotion calibration cycle. You have a folder of self-review notes, a handful of Slack messages where a teammate said something nice, and a vague sense that this was a good year — but no structured case, and no idea which of it actually proves you are ready for the next level.Career

El Constructor de Casos de Promoción: Convierte Logros Dispersos en un Caso Cuantificado para tu Próximo Nivel

Compartir:
El Constructor de Casos de Promoción: Convierte Logros Dispersos en un Caso Cuantificado para tu Próximo Nivel

Por qué importa este prompt

Promotion committees reject packets for vague, unquantified claims far more often than for genuinely insufficient work. A packet written from memory the night before the deadline systematically underclaims impact, because people default to hedged language ("helped improve," "contributed to") instead of the specific before/after numbers that actually persuade a room of people who were not in the room when the work happened. Finding out your case was too vague only after the committee has already met costs you an entire additional cycle — six to twelve months, in most leveling systems — that a structured review the week before would have caught.

Para qué lo usamos

You are six weeks out from a promotion calibration cycle. You have a folder of self-review notes, a handful of Slack messages where a teammate said something nice, and a vague sense that this was a good year — but no structured case, and no idea which of it actually proves you are ready for the next level.

Prompt

Role: Act as a skeptical, senior member of a promotion calibration committee who has reviewed hundreds of packets and immediately spots padding, vague claims, and missing evidence. You are not here to make me feel good — you are here to tell me whether my case would survive a room full of people who do not already like me.

Context: I am currently a [YOUR CURRENT TITLE AND LEVEL], aiming for [TARGET TITLE AND LEVEL] at [COMPANY NAME, OPTIONAL]. The calibration cycle is on [CYCLE DATE]. Below is my raw, unorganized material — self-review notes, praise from Slack or email, project retros, old performance review text, anything I have: [PASTE YOUR RAW NOTES, ACCOMPLISHMENTS, AND FEEDBACK HERE]

Task:
1. Extract every distinct accomplishment from the raw material — do not merge two different pieces of work into one bullet.
2. For each one, force it into this structure: Action → Scope → Measurable Result → Who Else Benefited.
3. If an accomplishment has no measurable result, do not invent one. Instead, tell me exactly what number to go find and who would have it (e.g., "ask your manager for the before/after ticket backlog size" or "check the dashboard for the deploy frequency change").
4. Group the accomplishments under the actual competencies required for [TARGET TITLE AND LEVEL]. If I have pasted a leveling rubric, use it. If not, use these four standard dimensions: Scope of Ownership, Technical Depth, Leadership and Influence, Cross-Team Impact.
5. Identify the single weakest competency in my case. If the case is not yet strong enough to make this cycle, say so directly — do not soften it into encouragement.

Constraints: Never invent or round up a number I did not provide. Never use generic adjectives like "excellent," "strong," or "outstanding" unless they are someone else's direct quote. Every claim must trace back to the Action → Scope → Result structure or it gets flagged, not included. Name the weakest point explicitly even if it is discouraging to read.

Output Format:
- A table with four columns: Competency | Accomplishment | Measurable Result | Still Needs
- A 150-word "Case Summary" paragraph written so a manager could paste it directly into a calibration document without editing
- A short "Biggest Gap" section naming the weakest competency and one concrete action I can take before the cycle closes to address it

Resultado

Competency Table (excerpt)

CompetencyAccomplishmentMeasurable ResultStill Needs
Scope of OwnershipTook over the payments reconciliation service after the previous owner leftReduced monthly reconciliation discrepancies from 340 to 12 cases over two quartersConfirm with finance whether the 12 remaining cases are a known acceptable floor
Technical DepthRedesigned the retry logic for the billing webhook pipelineCut failed-webhook incident tickets from 18/month to 3/month; ask platform team for the exact latency deltaA specific p99 latency number — check the dashboard before the cycle
Leadership and InfluenceMentored two mid-level engineers through their first on-call rotationBoth passed their first solo on-call shift with zero escalations — confirmed by on-call logsNone — this is well-evidenced as is
Cross-Team ImpactVague note: "worked closely with the data team on the migration"Not provided — flagged, not includedAsk the data team lead for the specific deliverable and date it shipped

Case Summary (150 words):

Over the past two quarters, [NAME] took ownership of the payments reconciliation service after its previous owner departed, reducing monthly discrepancies from 340 to 12 cases — a 96% reduction achieved through a redesigned retry architecture that also cut failed-webhook incidents from 18 to 3 per month. This work required independently diagnosing a cross-system race condition that had gone unaddressed for over a year. Beyond individual delivery, [NAME] mentored two mid-level engineers through their first on-call rotations, both of whom completed solo shifts with zero escalations, demonstrating leadership readiness beyond their current scope. The case for Staff Engineer is strong on Scope of Ownership and Technical Depth. Cross-Team Impact remains the open gap: the data team migration work needs a specific, dated deliverable before this packet goes to committee.

Biggest Gap: Cross-Team Impact is currently unevidenced. Before the cycle closes, get the data team lead to confirm in writing what specifically shipped, when, and what measurable effect it had — a vague "worked closely with" will not survive calibration.

La mayoría de los consejos para prepararse para una promoción se limitan a decir «haz una lista de tus logros». Ese consejo produce exactamente el tipo de expediente que los comités de calibración rechazan: una lista de actividades —«lideré la migración», «mejoré la fiabilidad»— sin ninguna evidencia que las respalde. La diferencia entre una actividad y un logro es un resultado medible, y casi nadie lo aporta si no se le obliga a hacerlo.

Este prompt impone esa estructura con una sola regla: Acción → Alcance → Resultado Medible → Quién más se benefició. Cuatro casillas, y si la tercera queda vacía, la afirmación no entra en el caso final — se marca con instrucciones precisas sobre qué número hay que buscar y quién lo tiene. Esto importa porque el fallo habitual no es mentir, es redondear hacia arriba. «Ayudé a mejorar la fiabilidad» suena cierto y suficiente en el momento de escribirlo, pero quien lo lee en el comité no tiene forma de saber si eso significa una mejora del 2% o del 200%. Sacar esa laguna a la luz —«pide a tu manager el tamaño del backlog de tickets antes y después»— convierte un recuerdo vago en una tarea de investigación que puedes completar antes del plazo.

La segunda decisión de diseño es agrupar los logros por competencia en lugar de por proyecto. La mayoría organiza su autoevaluación de forma cronológica, que es la forma natural en que funciona la memoria pero la forma equivocada de construir un caso: una rúbrica de calibración evalúa Alcance de Responsabilidad, Profundidad Técnica, Liderazgo e Impacto Interequipos como dimensiones separadas, y una lista cronológica oculta cuáles de esas dimensiones son débiles. Ordenar por competencia hace visible la laguna de inmediato — en el ejemplo de salida anterior, tres competencias están bien respaldadas y una es una sola frase vaga sin nada detrás.

La última instrucción, y la más importante, es la que casi todas las herramientas de autoevaluación omiten por completo: nombrar la competencia más débil y decir directamente si el caso ya es lo bastante sólido. Un prompt que solo organiza el material sin llegar a decir «esto no está listo» es simplemente una herramienta de formato. El valor real aquí está en detectar un caso débil seis semanas antes de que lo haga un comité, cuando todavía hay tiempo para ir a buscar el número que falta — en vez de seis semanas después, cuando la única opción que queda es esperar al siguiente ciclo.

Usa esto igual que en el ejemplo anterior: pega todo lo que tengas, incluso elogios de Slack a medio recordar, y deja que la estructura te diga qué falta en lugar de intentar adivinarlo tu mismo.

prompt-engineeringperformance-reviewpromotioncareer-growth
Compartir: