When Bigger Projects Make Better Promotion Stories

Key takeaways

• Evaluating engineers by project size can reward unnecessary work.
• Complexity creates ongoing costs in maintenance, operations, and learning.
• Large designs need concrete requirements that simpler alternatives cannot meet.
• Eliminating work deserves credit based on measured savings and reduced maintenance.

A new platform makes a great promotion story. A configuration change that makes the platform unnecessary takes more explaining. If your review process rewards project size, that gap becomes an expensive incentive.

Good judgment can leave very little to show

Staff engineers typically take on broad technical responsibility without becoming people managers. Depending on the company, their decisions may affect several teams. Proving the value of those decisions is harder than listing what they shipped.

Imagine several teams processing the same data separately. One engineer discovers that an existing feature, configured correctly, can eliminate the duplication. Another proposes a shared platform.

If the configuration change meets the requirements, it may be the better investment. But the platform proposal comes with architecture diagrams, milestones, and a migration plan. There is plenty to put in a promotion packet.

The simpler solution might leave behind a small change and a problem nobody has anymore.

When reviewers use the volume of those artifacts to judge performance, project size can crowd out the question that matters: how much the solution helped.

Cross-team impact can become cross-team overhead

Suppose a promotion rubric asks engineers to demonstrate influence across multiple teams. That is a reasonable expectation for a senior technical role.

The trouble starts when influence is measured mainly by how many teams participate or how widely a new system is adopted.

Turn a small fix into a shared platform and more teams become involved. Someone needs to coordinate design reviews. Someone needs to manage migrations. Someone needs to negotiate dependencies.

All of that coordination produces evidence of leadership. It does not, by itself, establish that the organization is better off.

If the project created dependencies that were never necessary, managing them well still leaves a basic question unanswered: why did those dependencies need to exist?

Blaming individual ambition misses the incentive. When reducing work is hard to get credit for and expanding work is easy to document, the evaluation system deserves scrutiny.

The maintenance bill outlives the launch

Overengineering is not a line count. It means adding complexity beyond what current requirements and credible future needs justify.

Consider introducing a general-purpose platform for a feature used by one team. That platform may need deployment procedures, access controls, incident ownership, and onboarding documentation. Shipping it starts several recurring obligations.

The arithmetic can be less flattering than the launch presentation.

Suppose a new system cuts a manual process from 8 hours to 2 hours a month. Maintaining that system takes another 4 hours a month. The net saving is 2 hours a month, before accounting for the time spent building it.

That might still be worthwhile. But the decision should use the net saving.

Larger designs can also be necessary. Teams may need independent deployments or different security controls. Those are concrete reasons to separate systems.

The useful test is whether the added complexity addresses a specific need valuable enough to justify its ongoing cost.

Make work eliminated part of the promotion case

A better review starts with better questions:

• Whose problem got smaller, and by how much?
• Could an existing capability have met the requirements more simply?
• How much operating and maintenance work does the solution require?
• What would have happened if the project had never started?

That last question matters. A project’s existence is not evidence of its necessity.

Engineers can also document subtraction. Record which manual steps disappeared, how much incident response time fell, or which systems no longer need an owner. Keep projected savings separate from results actually measured.

This gives reviewers something concrete to assess when an engineer’s most valuable contribution produces very little new infrastructure. It also makes the continuing cost of a larger project visible alongside its benefits.

Knowing when enough has been built is part of staff-level judgment. Promotion decisions should recognize that judgment alongside successful execution. The engineer who makes a major project unnecessary deserves a strong promotion story, too.