#35 Business vs Promotion-driven development
If promotion depends on complexity, guess what teams will ship?
In some large organisations, promotion-driven development becomes a strategy engineers use for career progression. When they can’t find (or don’t know) the right business scope, they create one: a complex engineering challenge that looks impressive in a promotion packet. But if solving that challenge doesn’t move the needle for the business, is it really worth solving? More importantly, is the complexity justified?
If the answer is no, but it still leads to a promotion, that is promotion-driven development. Unfortunately, it’s a symptom of a broken incentive system.
Promotion-driven: Solving engineering problems that optimise the promotion packet.
Business-driven: Solving business problems that impact the company.
When leadership rewards this strategy (even accidentally), it signals a clear disconnect between them and engineering.
I don’t claim this is true across all companies; this is a personal opinion based on what I’ve seen and discussed with engineers from other companies.
I’ll share some thoughts below on the problem and how I approach it with both leadership and engineering.
A quick work from Scalekit who is kindly sponsoring this email.
Scalekit (Sponsor)
Agents are becoming first-class actors. They’re calling APIs, triggering actions, and operating without user sessions — which means your auth stack needs to support more than just humans. With MCP servers emerging as the standard interface for agents, Scalekit brings the comprehensive auth stack for AI apps. Their MCP auth module supports all client registration flows, so you can handle real-world clients without sprawl or security debt.
The good part is even if you’re already using a custom auth system, or third party auth providers like Auth0, Cognito, Scalekit plugs in alongside, letting you add scoped, observable auth for agents without ripping out what you’ve built.
Because if agents are on your roadmap, your auth infra needs to meet them there.
Problem with promotion-driven development
Shipping projects is a great skill. Doing enough reps as an engineer makes them more valuable for the team and the business. The number and quality of repetitions varies from one company to another. But in larger organisations, there’s often the challenge of competing for scope.
For example, if there are dozens of senior engineers and only a handful of projects, most engineers will be disincentivised to share scope, especially if their promotions depend on shipping those projects. Sadly, not picking the right projects can tank your performance review.
This culture of not sharing scope became more visible at Meta, especially when they cut 5% of their workforce in January and did more performance layoffs later this year. Some Meta engineers shared this shift where teams stopped sharing scope to avoid getting PIP’d.
This environment pushes engineers to find complex, promotion-driven initiatives that didn’t come from a business need. Common examples: architecture rewrites or microservices rewrites.
This is over-engineering, but with a different motivation: finding the complexity to make the promotion case more compelling.
Both leadership and engineering share responsibility for fixing this.
For engineers: Focus on the leverage
A well-rounded engineer should be obsessed with solving business problems. The goal is not delivering complex engineering output with no business value (i.e., showing off).
Finding scope can be very challenging, but introducing unnecessary complexity is not the right direction to follow. If you’re struggling to find scope:
Talk to product people and leadership. Your manager, skip-level, or product manager. Pay attention to their words: what they’re thinking about, what OKRs they mention, what customer deals are making the CEO literally sweat.
These are great signals for you to dig deeper.
Engineering and business challenges don’t have to be mutually exclusive. The problems are at the intersection of a Venn diagram, where solving them moves the business forward and make an engineering impact. This is finding your leverage.
Challenging Complexity
If an engineer presents a “microservice rewrite with no business OKRs” proposal in a design review, this should be challenged, either pivot to an idea backed by a business metric or completely reject it.
Whenever I’m proposing a new idea, I always have answers to the five whys ready.
Say I’m designing an architectural proposal (e.g., scaling out a database).
Valid questions are:
Why do we need to scale?
Answer: Because we’re reaching the limits of a single database instance.
Why are we hitting the limits?
Answer: Because we’re storing data on X, Y, and ZI see the value in storing X & Y, but why are we storing Z?
💡 Notice the shift: why are we solving this with infrastructure rather than addressing the data model?
Have you explored other options? Why this <approach>?
Why are we confident this plan will work without it becoming an operational burden?
Being prepared to answer these five whys (with research and data) is the mark of a well-rounded engineer.
Also, simplicity > complexity…
There’s an immense value to adopting pragmatism for solving problems. Evan & Stefan, cofounders of hellointerview.com, reinforced this in their blog post: 14 Lessons from Building Hello Interview. They run their entire product using only two services: a Next.js web server and a Temporal worker service.
To quote Stefan:
“Perfect is the enemy of shipped, and we’ve shipped a lot.”
For Leadership: Celebrate product stability
Product and feature launches are great. When engineers deliver and customers are acquired or retained, that’s successful engineering-product partnership.
This partnership still holds true even during “feature dryness.” When architectures are reviewed, costs reduced, and scale improved, those are meaningful contributions that strengthen stability and reliability of the product.
This could be:
Metrics improved (uptime, latency, cost savings, database connections)
Infrastructure wins
Onboarding large customers or sustaining high traffic (e.g., Black Fridays)
These are all efforts worth recognition and support by leadership.
POV: Promotions shouldn’t skew toward building “feature factory” teams, but toward building teams of creative problem solvers.
Maintaining the product might not be a sexy slide deck to present. But initiatives around reliability and scale have long-term impact worth celebrating!
Feature releases are not a prerequisite for promotion. Promotions should depend on many things, including (but not limited to) releasing new features.
Wrap up
Leadership should encourage business-driven development over promotion-driven development. Engineers should anchor themselves to solving business problems, complex or not, boring or not.
Complexity must always be challenged. Not because of the individual, but to justify maintaining that complexity and making sure all options were exhausted.
To me, a healthy design review meeting is one where the engineer has done enough research to justify their idea and can answer the five whys before presenting.
That’s the last post for the year. If you enjoyed reading this, consider subscribing to the newsletter.
I’ll be back on January 9th. Till then, happy new year to you and your families! 🎉