Why does a 24-year-old engineer earn more than a 40-year-old manager, and why is this req hard?

Why does a 24-year-old engineer earn more than a 40-year-old manager, and why is this req hard?

A 24-year-old engineer can out-earn a 40-year-old manager because engineering pay follows scarcity and impact. A hard req is one where several scarce requirements are stacked on top of each other. Both facts come from the same source: the market pays for a specific, rare combination of what someone can do and whether they are available to do it, and that combination has little to do with age or years worked.

This lesson closes the module. Telling a strong engineer from an average one set the standard for a candidate. The stack-match call and reading a hiring manager's rejection covered judging one. The funnel explained why the search is slow. This lesson turns all of that into the two conversations that happen after the shortlist: what the role should pay, and why the search is taking as long as it is.

What is engineering pay actually priced on?

Engineering pay is priced on scarcity and impact. Total compensation, the base, equity, and bonus that make up an offer, gets set by how rare the person's combination of skills is and how much value one engineer's work carries. Seniority sets a floor for the range; scarcity and impact set where inside it, or above it, the number lands.

Both numbers run high in software compared to most fields. The combination that matters is a level, a specific stack, a domain, and being available to move, all at once. Each of those narrows the pool on its own, and a person clearing all four at a senior level is rare in a way a single skill never is. Impact runs high too: one engineer's code can run for millions of users at once, so a company will pay well past what the role's title suggests to keep the work in the hands of someone excellent rather than someone adequate.

Why can an individual contributor out-earn a manager?

An individual contributor can out-earn a manager because companies pay for scarce output, and senior engineering skill stays scarce whether or not the person manages anyone. Software companies with mature career ladders run two tracks past the senior level: a management track and an individual contributor track that keeps building. The second track exists because a company that only pays for people-management loses its best builders the moment they want a raise: the raise would arrive with direct reports attached, and the company needed their code.

A senior engineer who stays on the builder track and keeps growing in scope, from owning a system to owning the architecture several teams build inside, can reach pay at parity with a manager or past one. The 24-year-old in the title is the extreme case: a rare enough combination of skill and market timing lands pay a decade of tenure elsewhere would not reach, because the market is pricing the combination itself.

Why is the band the band?

A band is the pay range a company has approved for a level in a location, and it moves slowly because it applies to everyone doing that scope of work at that company. Stretch it for a single candidate and every other person at that level now has a documented case for the same raise, which is why the fix for a band that reads low against the market usually runs through the level.

This is the fact worth carrying into the conversation with a hiring manager who wants to beat the market with one offer. The lever they actually control is the scope sentence: whether this role is written at the level the market is paying for, or at a lower one with more responsibility quietly attached. Reopening the scope sentence is what moves a band, since the band is computed from it.

What does the counter-offer market do to an offer?

The counter-offer market shortens the distance between a signed offer and a lost candidate, since counter-offers are common in this market and a current employer usually responds rather than lose a productive engineer. A signed offer sits inside a live market until the actual start date, and the gap between offer and start is exactly when a counter lands.

The practical effect is pace and completeness. A search that closes fast gives the counter less time to arrive. A search that closes on more than pay, matching the stack, the scope, and the on-call load a candidate named as their reasons for looking, gives a counter less to work with, since a counter usually moves only the one line of the offer that was already competitive.

How do you show a requirement's cost in weeks?

You show a requirement's cost by pricing it against the funnel math: the reply rates, the pass-through at each stage, and the pool size after the requirement is applied. Requirements stack rather than add. A senior level cuts the market once. A specific stack cuts what remains again. A domain, a location, and availability each cut it again. A req with four or five real requirements can shrink a national market of engineers to a few hundred people, and that pool is mostly employed and already fielding other offers.

Each requirement has a rough price in weeks once the pool shrinks past it, because a smaller pool means more outreach per reply and a longer wait for someone to be between offers at the right moment. A req's difficulty is priced, requirement by requirement, the same way the salary is.

What goes into the paragraph you send on Friday?

A defensible case for a slow req names three things: the requirement stack in the order it was applied, the pool size and reply rate after that stack, and the number of weeks each requirement is adding to the timeline. Written down, it replaces a debate about effort with a specification a hiring manager can act on: cut a requirement, widen the level, or adjust the band, now that the cost of each one is on paper instead of felt.

That paragraph is also where this module closes. A shortlist built on what separates a strong engineer from an average one, narrowed through the trade-off calls, and slowed by a funnel that runs on its own numbers, ends here: a case that names what the req is actually asking for, what it costs, and what changing it would save.