سازنده پرونده ارتقا: موفقیت‌های پراکنده را به پرونده‌ای کمی‌شده برای سطح بعدی تبدیل کنید
چرا این پرامپت اهمیت دارد
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.
ما از آن برای چه استفاده می‌کنیم
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.
پرامپت
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
نتیجه
Competency Table (excerpt)
| Competency | Accomplishment | Measurable Result | Still Needs |
|---|---|---|---|
| Scope of Ownership | Took over the payments reconciliation service after the previous owner left | Reduced monthly reconciliation discrepancies from 340 to 12 cases over two quarters | Confirm with finance whether the 12 remaining cases are a known acceptable floor |
| Technical Depth | Redesigned the retry logic for the billing webhook pipeline | Cut failed-webhook incident tickets from 18/month to 3/month; ask platform team for the exact latency delta | A specific p99 latency number — check the dashboard before the cycle |
| Leadership and Influence | Mentored two mid-level engineers through their first on-call rotation | Both passed their first solo on-call shift with zero escalations — confirmed by on-call logs | None — this is well-evidenced as is |
| Cross-Team Impact | Vague note: "worked closely with the data team on the migration" | Not provided — flagged, not included | Ask 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.
بیشتر توصیه‌های آماده‌سازی برای ارتقا صرفاً می‌گویند «فهرستی از موفقیت‌های خود تهیه کنید». این توصیه دقیقاً همان نوع پرونده‌ای را تولید می‌کند که کمیته‌های ارزیابی رد می‌کنند: فهرستی از فعالیت‌ها — «رهبری فرآیند مهاجرت»، «بهبود پایداری» — بدون هیچ مدرکی در پشت آن‌ها. تفاوت میان یک فعالیت و یک موفقیت، وجود یک نتیجه قابل‌اندازه‌گیری است و تقریباً هیچ‌کس بدون اینکه مجبور شود، آن را ارائه نمی‌دهد.
این پرامپت این ساختار را با یک قاعده اعمال می‌کند: اقدام ← دامنه ← نتیجه قابل‌اندازه‌گیری ← کسانی که از این سود بردند. چهار بخش، و اگر بخش سوم خالی بماند، ادعای مربوطه وارد پرونده نهایی نمی‌شود؛ بلکه علامت‌گذاری می‌شود، همراه با دستورالعملی دقیق درباره اینکه باید به دنبال چه عددی بود و از چه کسی باید آن را پرسید. این موضوع اهمیت دارد زیرا شکست رایج، دروِِغ‌گویی نیست، بلکه گرد کردن به سمت بالاست. جمله «به بهبود پایداری کمک کردم» در لحظه نوشتن، درست و کافی به نظر می‌رسد، اما عضو کمیته‌ای که آن را می‌خواند، هیچ راهی برای تشخیص این موضوع ندارد که منظور بهبود ۲ درصدی بوده یا ۲۰۰ درصدی. روشن کردن این کاستی — «اندازه بک‌لاگ تیکت‌ها پیش و پس از تفییر را از مدیرت بپرسید» — یک خاطره مبهم را به یک وظیفه تحقیقاتی قابل‌انجام پیش از موعد نهایی تبدیل می‌کند.
دومین انتخاب طراحی، گروه‌بندی موفقیت‌ها بر اساس شایستگی به‌جای پروژه است. بیشتر افراد خودارزیابی خود را به‌صورت زمانی مرتب می‌کنند که روش طبیعی عملکرد حافظه است، اما روش نادرستی برای ساختن یک پرونده محسوب می‌شود: یک معیار ارزیابی، دامنه مسؤولیت، عمق فنی، رهبری و تأثیر میان‌تیمی را به‌عنوان ابعادی جداگانه نمره‌گذاری می‌کند و فهرستی زمانی، ابعاد ضعیف را پوشیده نگه می‌دارد. مرتب‌سازی بر اساس شایستگی، این کاستی را بی‌درنگ نمایان می‌کند — در نمونه خروجی بالا، سه شایستگی به‌خوبی مستندسازی شده‌اند و یکی تنها یک جمله مبهم بدون هیچ پشتوانه‌ای است.
آخرین و مهم‌ترین دستور، موضوعی است که تقریباً تمام ابزارهای خودارزیابی به‌طور کامل از آن صرف‌نظر می‌کنند: نام بردن از ضعیف‌ترین شایستگی و بیان مستقیم اینکه آیا پرونده هم‌اکنون به‌اندازه کافی قوی هست یا نه. پرامپتی که صرفاً محتوا را ساماندهی می‌کند بدون آنکه هرگز بگوید «این هنوز آماده نیست»، تنها یک ابزار قالب‌بندی است. ارزش واقعی در اینجا، شناسایی یک پرونده ضعیف شش هفته پیش از شناسایی آن توسط کمیته است، زمانی که هنوز فرصت کافی برای یافتن عدد گمشده وجود دارد — نه شش هفته پس از آن، زمانی که تنها گزینه باقیمانده، انتظار برای دوره بعدی است.
از این پرامپت دقیقاً مانند نمونه بالا استفاده کنید: هر آنچه در اختیار دارید، حتی تعریف‌های نیمه‌فراموش‌شده در Slack را وارد کنید و اجازه دهید ساختار پرامپت نشان دهد چه چیزی کم است، به‌جای آنکه خود تلاش کنید آن را حدس بزنیح.