Software Modernization Projects Dilemma (Part 2)
This is the second part of a two-part series. Reading the first part is not required, but it is recommended.
After working with the same team for two years, I joined another tier 0 product team as a senior software engineer — one of the company’s most critical services handling massive traffic, where any downtime directly impacts revenue.
The new team focused primarily on product requirement delivery, and they were working with a legacy codebase that had significant tech debt: deprecated libraries, a cumbersome deployment process, and unstable integration tests etc.
Having spent all my time on feature work in my previous team, I worried I wouldn’t grow by doing more of the same. (Looking back now, I realize this assumption was incorrect — working on product features actually contributed significantly to my growth; I’ll unpack that in a future post).
The tech debt issues seemed like the perfect opportunity. As a result, I decided to focus on software modernization tasks for my career growth.
Two years flew by after joining the new team. I had successfully delivered challenging software modernization tasks — from removing outdated library updates to building a new deployment pipeline. Feeling confident about my contributions, I decided it was time to speak with my manager about promotion.
“I want to talk about promotion,” I said confidently in a one-on-one meeting.
“I think I’ve made some good progress for the team. Deployment is way simpler and faster now. Our test cases are finally stable. And we’ve basically eliminated all the critical security vulnerabilities.”
“So… Does this seem like staff-level work to you?”
“You’re doing great work,” my manager replied calmly.
“but I have to stack-rank the team, and those tasks aren’t staff-level.”
“Because… some lack business value. These tasks aren’t business priorities and had no impact on customers and other teams”
“Also, at the staff level, you need to work across teams, influence broader decisions, and build visibility beyond just our team.”
About the Author
