The best advice I got on my promotions as a software engineer was from a Principal Architect at Amazon after he told me his story of getting promoted to Principal, and this has stayed with me my whole career.
He said, very simply:
> Your architecture can be a love letter to your technical brilliance,
> but if it does not move customer and company goals, it will not move your level.
That hurt a little. Because I recognised myself in it.
A few years ago I wanted to design something with every shiny thing in the book: API Gateway, Lambda, DynamoDB, event bus, the works.
On paper it was beautiful. In reality it was expensive, slow to ship, and did not match the skills of the team that would maintain it.
So we shipped a hybrid architecture instead.
Fewer moving parts, more reuse of existing services, cheaper to run, easier to hand over.
Over time, here is how my thinking about promotions changed.
1. Start from the business goal, not the tech stack
Before talking about Kafka vs SQS or MySQL vs DynamoDB, answer this first: What money, risk, or customer pain will this remove? Promotions track that, not the number of services in your diagram.
2. Ship finished products, not clever demos
Leaders remember the feature that went live, stayed stable, and earned or saved real money. Drive the entire lifecycle yourself: design, build, launch, oncall, cleanup, docs.
3. Make the team faster, not just yourself
Tools, scripts, templates, better CI, better dashboards. If people quietly say “things move faster when you are on this” your manager already has half a promotion case.
4. Do your share of the unsexy work
Oncall, migrations, bugs, incident reviews. Senior folks who avoid this slow the entire org. Senior folks who lean into it become trusted very quickly.
5. Grow people, not just systems
Mentor juniors, run design reviews, write clear docs, set standards. When your manager sees that you are already acting like the next level, formal promotion becomes a catch up, not a favour.
6. Be proactive about your promotion, not obsessed with it
Have periodic one to ones. Talk about where you want to go and ask what evidence your manager would need to support that.
Remember your manager has ten other people to manage. It is your responsibility to make your impact visible.
Do not be desperate. Understand the timelines and work within them. As you get close to the boundary, collect the missing data points: impact metrics, incident write ups, design docs, peer feedback. Make the story easy to tell.
Most importantly, work for the business, not for promotion-driven development.
If your roadmap only exists to tick boxes on a promotion rubric, people can feel it. If your roadmap clearly creates value, saves cost, or reduces risk, promotion becomes the natural side effect.
So instead of asking “What new tech can I use this year?”
Ask, “Where can I create obvious business impact and leave the system and the people around me better than I found them?”
