Caffeine, Code & Chaos

Systems engineer. Robotics geek. Maker of shiny things. Part race car, part glitter. Powered by caffeine and curiosity.

The Eligibility Exercise: A Practical Framework for Your Next Promotion

I guess it’s the season, but I’ve had multiple folks ask me for guidance on promotions lately. I always ask the same question first:

Have you done an eligibility exercise?

Yup. They make the same face you just made, then ask “WTF is that?!?”

Here’s the thing - most people walk into a promotion conversation armed with vibes and a vague (or fierce) sense that they “deserve it.” That’s not a strategy. That’s a wish. Let me show you a better way.

What Is an Eligibility Exercise?

An eligibility exercise is the process of taking the next level up job description and documenting how you meet (or exceed) every single requirement. The idea is simple:

  1. Get the job description for the role you want
  2. Copy it into a document
  3. Add notes under each requirement explaining how you already meet or exceed it
  4. Identify any gaps where you fall short

That’s it. No fancy frameworks. No career coaching certifications required. Just honest self-assessment against a concrete target.

Why This Works

Let’s be real - most promotion conversations fail for one of two reasons:

  • You can’t articulate your case. You feel ready, but when your manager asks “why?”, you fumble through a highlight reel that sounds more like a Thanksgiving dinner speech than a business case.
  • You’re not actually ready. And that’s okay! But it’s way better to figure that out on your own terms than to hear it in a meeting you hyped yourself up for.

The eligibility exercise solves both problems. If you’re ready, you’ll have a clear, evidence-based case. If you’re not, you’ll have a targeted development plan. Either way, you win.

A Worked Example

Let’s walk through this with a real(ish) scenario. Say you’re currently a Software Developer and you’re eyeing a Senior Software Engineer role. Here’s a typical job description for that senior role, followed by the kind of notes you’d add during your eligibility exercise.

Job Description: Senior Software Engineer

About the Role

We’re looking for a Senior Software Engineer to join our platform team. You’ll design, build, and maintain scalable backend services while mentoring junior engineers and driving technical excellence across the organization.


Requirements and Your Evidence

7+ years of professional software development experience

I have 11 years of active experience as a software developer on both large and small teams. I started as an intern at Acme Corp in 2015, moved into a full-time dev role in 2016, and have been shipping production code continuously since then across three different companies.

Experience serving as a technical lead throughout the full software development lifecycle

My most recent experience as a tech lead was with the WidgetMaker project. I oversaw the work of a product manager, a project manager, and 10 developers. I was the primary point person for issues that arose in the development process. I also worked across various peer teams to facilitate the security and production deployment paths for the application. Under my guidance, we shipped the app on time and under budget.

Strong proficiency in one or more backend languages (e.g., Go, Python, Java, C#)

I’m highly proficient in Python and Go. Python has been my primary language for 8 years - I’ve built REST APIs, CLI tools, data pipelines, and automation frameworks with it. I picked up Go three years ago and have since built two production microservices that handle 50k+ requests per minute. I also contribute to our team’s internal Go library for shared middleware.

Experience designing and building distributed systems at scale

I was the lead designer on our event-driven order processing system, which handles roughly 2 million events per day across 12 microservices. I authored the original architecture proposal, led the design review with our principal engineers, and implemented three of the core services. I also designed our retry and dead-letter strategy, which reduced failed message rates by 94%.

Demonstrated ability to mentor and grow junior engineers

I’ve been the onboarding buddy for our last four new hires. I run a weekly “office hours” session where junior devs can bring questions or code for review. Two engineers I mentored have since been promoted to mid-level roles. I also created our team’s “First 90 Days” onboarding guide, which has been adopted by three other teams in the org.

Experience with CI/CD pipelines and DevOps practices

I built and maintain our team’s GitHub Actions CI/CD pipeline, which runs linting, unit tests, integration tests, and deploys to staging automatically on every PR merge. I also implemented our blue-green deployment strategy on Kubernetes, which cut our rollback time from 30 minutes to under 2 minutes. I’ve given two internal tech talks on CI/CD best practices.

Excellent communication skills with the ability to explain technical concepts to non-technical stakeholders

I present our quarterly technical roadmap to the VP of Product and their leadership team. I write weekly engineering updates that go out to the broader org, translating complex technical work into business-impact language. My manager has specifically called out my communication skills in my last three performance reviews as a key strength.

Bachelor’s degree in Computer Science or equivalent practical experience

I have a Bachelor’s degree in Information Systems from State University (2015). I also hold AWS Solutions Architect and Kubernetes (CKA) certifications.


Preferred Qualifications

Experience with cloud platforms (AWS, GCP, or Azure)

Our entire stack runs on AWS. I have hands-on experience with EC2, ECS, Lambda, S3, DynamoDB, SQS, SNS, CloudWatch, and IAM. I’m the team’s go-to person for AWS architecture questions and I hold the AWS Solutions Architect Associate certification.

Familiarity with observability tools (Datadog, Prometheus, Grafana)

⚠️ GAP IDENTIFIED - I have basic experience with CloudWatch and some exposure to Grafana dashboards, but I haven’t worked deeply with Datadog or Prometheus. I’d want to spend some time getting hands-on with our observability stack before stepping into this role.

Experience with database design and optimization (PostgreSQL, Redis, DynamoDB)

I’ve designed schemas for three production PostgreSQL databases and implemented query optimizations that reduced our slowest API endpoint response time from 1200ms to 180ms. I also introduced Redis caching to our most-hit endpoints, reducing database load by 40%.

Contributions to open-source projects or technical communities

⚠️ GAP IDENTIFIED - I don’t have meaningful open-source contributions yet. I’ve filed a few issues and one small documentation PR, but nothing substantial. This is an area I could start building toward.

Notice the Gaps?

See those “GAP IDENTIFIED” flags? That’s the real magic of this exercise. You’re never going to be a perfect match for every line item, and that’s fine. The point is that you know where the gaps are so you can:

  1. Build a plan to close them before your promotion conversation
  2. Proactively address them when you make your case (“I know observability is an area where I’m still growing, and here’s what I’m doing about it…”)
  3. Decide if the gap is a dealbreaker or just a nice-to-have

A hiring manager (or your current manager) is going to be way more impressed by someone who says “I’ve identified two growth areas and here’s my plan” than someone who hand-waves and says “yeah, I can figure that out.”

How to Run Your Own Eligibility Exercise

Here’s your action plan:

  1. Get the job description. Ask your manager, check internal job boards, or look at external postings for similar roles at your company’s level. If your company uses a career ladder or leveling guide, even better.

  2. Copy it into a doc. Google Docs, Notion, a markdown file - whatever works for you. Just get it somewhere you can annotate.

  3. Go line by line. For each requirement, write 2-4 sentences explaining how you meet it. Be specific. Use project names, metrics, timelines, and outcomes. “I’m good at this” is not evidence. “I reduced deploy time by 80% on Project X” is.

  4. Flag your gaps honestly. Don’t skip requirements you can’t answer. Mark them clearly and start thinking about how to close them.

  5. Share it with your manager. This is optional but powerful. Walking into a 1:1 with a completed eligibility exercise tells your manager three things: you’re serious, you’re self-aware, and you’ve done the work. It also gives them a concrete document to advocate with when they go to bat for you.

Quick Reference: Good vs. Bad Evidence

Weak Evidence Strong Evidence
“I’m a good communicator” “I present quarterly roadmaps to VP-level stakeholders”
“I know Python” “I’ve built three production services in Python over 8 years”
“I help junior devs” “Two engineers I mentored were promoted within 18 months”
“I do DevOps stuff” “I built our CI/CD pipeline that runs 200+ deploys per month”
“I’m ready for more responsibility” “Here’s a doc showing I meet 11 of 13 requirements for the role”

The Three Things Every Promotion Needs

Before you march into your manager’s office with your shiny new eligibility document, let’s talk about how promotions actually work at most companies. There are three things that need to align:

  1. Personal Eligibility - Do you meet or exceed all of the requirements for the next level?
  2. Business Need - Is there a business need for another staff member at that higher level?
  3. Budget - Is there money available to fund the higher salary?

Here’s the uncomfortable truth: you can only control the first one.

That’s exactly why we spend so much time on the eligibility exercise. It’s also listed first for a reason. It doesn’t matter how much budget is available or how many open spots there are. If you aren’t qualified, you aren’t qualified. Full stop.

Business need and budget are leadership decisions that happen above your pay grade (literally). Reorgs happen. Headcount freezes happen. Fiscal years end at inconvenient times. None of that is in your control, and burning energy worrying about it is wasted effort.

But here’s what you can do: make sure that when the business need exists and the budget is there, you’re the obvious choice. That means being undeniably ready, with the documentation to prove it. When your manager goes into a planning meeting and someone says “do we have anyone ready for a senior role?”, you want your name to come out of their mouth without hesitation.

Starting the Conversation with Your Manager

So you’ve done the exercise. You’ve mapped your evidence. You’ve flagged your gaps (and ideally started closing them). Now what?

You need to have a conversation with your manager, and how you frame it matters. This isn’t a “give me a promotion” meeting. This is a calibration conversation. You’re checking whether your self-assessment matches their perspective.

Here’s a template to get you started:

“Hey [manager], I’d like to discuss my career growth at [company]. I’ve been reviewing the qualifications for the [target role] and I believe I meet all of them. I’ve put together some documentation mapping my experience to each requirement, and I’d love to review it with you to make sure we’re on the same page.”

Notice what this does:

  • It signals intent without making a demand
  • It shows preparation - you’ve already done the work
  • It invites collaboration - you’re asking for their perspective, not arguing yours
  • It’s professional and low-pressure - easy for your manager to say yes to

Your manager might agree with your assessment. They might push back on a few areas. Either way, you’ve started a productive conversation grounded in specifics instead of feelings.

Once You’re Aligned, It’s Not About You Anymore

This is the part most people miss. Once you and your manager confirm that you meet the requirements, the conversation shifts. It’s no longer about whether you’re ready. It’s about business need and budget, and that’s your manager’s problem to solve, not yours.

Your job at that point is to:

  • Keep performing at the higher level (you’ve already proven you can)
  • Ask your manager what the timeline looks like and what factors are in play
  • Check in periodically without being pushy (quarterly is reasonable)
  • Stay patient but not passive - continue building your case and closing any remaining gaps

The worst thing you can do is nail the eligibility conversation and then coast. Keep the momentum going. Keep updating your document. Keep collecting evidence. When the stars align on business need and budget, you want to be so far past the bar that approval is a formality.

Summary and Key Takeaways

Promotions aren’t about tenure or good vibes. They’re about demonstrating readiness with evidence, and then being patient while the business catches up. The eligibility exercise gives you a structured, honest way to build your case (or identify what you need to work on first).

Here’s what to remember:

  • Get the job description for the role you want, not the role you have
  • Document your evidence with specifics - projects, metrics, outcomes
  • Flag your gaps honestly and make a plan to close them
  • Promotions need three things: personal eligibility, business need, and budget - you control only the first
  • Start a calibration conversation with your manager using your eligibility doc
  • Once aligned, shift focus - your readiness is confirmed, now it’s about timing and business factors
  • Stay ready so that when the opportunity opens, you’re the obvious choice

Stop guessing whether you’re ready. Do the exercise. The answer will be right there in front of you.

Closing

Have questions or want to share your eligibility exercise experience? Find me on GitHub, LinkedIn, or Bluesky.

Comments