I used to think being a good engineer meant being fast. Pick up a ticket, ship it, grab the next one. Repeat. My Jira board was clean. My PRs were consistent. I was, by every visible metric, doing great work.
And I was completely invisible.
Nobody pulled me aside and told me I was doing it wrong. That's the tricky part. Closing tickets is the job. But it's the job description, not the career path. And somewhere along the way, I started confusing the two.
The moment it clicked for me
About a year into my current role, I noticed something strange. There was this gap in our product. A core capability that can be improved, something that should have existed but didn't. Many be back when the team tried to make this feature, the tech wasn't there to make it work. AI wasn't mature enough. So the team moved on and it just... stayed that way.
I kept thinking about it. Not because anyone asked me to. Not because there was a ticket for it. I just kept using the product and thinking "why doesn't this exist?"
So I built it. On my own time, outside my sprint work. I prototyped it, proved it could work with models that were now available, designed the whole thing, developed it, and got it ready for production. Then I showed it to my team, my PM, my engineering manager.
The director loved it.
That side project ended up saving the users a few million dollars within months. And yeah, it got me promoted to Senior. In roughly a year.
But here's what I want you to understand: the promotion wasn't the goal. I wasn't scheming. I wasn't playing politics. I just cared enough about the product to notice something was broken and went and fixed it. The promotion was a side effect.
What I keep hearing from the best engineers
Over the past couple of years, I've had a lot of conversations with developers. People at Google, Meta, PayPal, Oracle, Amazon, engineers at startups and mid-stage companies. Some of them are the most talented coders I've ever met. But the ones who stand out, the ones who keep growing, they all have something in common.
They think about the product, not just the code.
They know what their team's product does. Not just technically, but why it exists. How it makes money. Where it sits in the larger org. What its strengths and weaknesses are. Which teams depend on it and which teams they depend on.
They ask questions constantly. Not just in their own team, but across the org. In big tech, there are dozens or hundreds of teams. The engineers who grow fastest are the ones who treat the company like a product they're trying to understand. They map the whole thing out. They know where the gaps are, where things are fragile, where the opportunities live.
And then they go fix something nobody assigned them.
The four mistakes that keep mid-level devs stuck
I've seen this pattern enough times now to feel confident naming it. Here's what holds people back, and it's almost never their coding ability.
1. They grind tickets but never zoom out
You can close 50 tickets a sprint and still be operating at the same level you were a year ago. If every ticket is roughly the same complexity and scope, you're just running on a treadmill. You're getting faster at execution, but you're not expanding your judgment, your influence, or your understanding of the system.
The engineers I admire most don't just execute. They step back and ask: are these even the right tickets? Is this the most important thing our team could be doing right now? That shift from "how do I finish this" to "should we even be doing this" is the gap between mid and senior.
2. They wait to be told what to work on
This is the silent killer. If your entire workload comes from your Jira board, then your career is being directed by whoever writes those tickets. That's usually a PM or a team lead. They're doing their best, but they're solving for the team's priorities, not your career growth.
The best engineers I know are the ones who bring problems to the table. They walk into a planning meeting and say "I've been looking at this, and I think we have an issue here. Here's a rough idea for how we could solve it." That's the behavior that gets noticed. Not because it's showy, but because it's rare.
3. They don't talk to other teams
You cannot understand the full picture of your product by staying inside your own team's Slack channel. You need to know who depends on your team's work and who your team depends on. You need to understand the priorities of adjacent teams so you can spot conflicts, redundancies, and opportunities.
Some of the best insights I've had came from casual conversations with engineers on completely different teams. You'd be surprised how often two teams are solving the same problem in parallel without knowing it, or how a small change in your service could unblock a massive initiative for another team.
4. They optimize their code but not the product
I know this is Product manger's zone but still I have seen people doing above and beyond in this area.
I know engineers who can write beautiful, perfectly optimized code. Clean abstractions, solid test coverage, elegant patterns. And their product is still losing users because nobody stepped back to look at the actual user experience or question whether the feature should exist at all.
Code quality matters. But product judgment is the multiplier. The ability to look at something and say "this works, but it's solving the wrong problem" is worth more than any refactoring.
Know your place in the org (and I don't mean "stay in your lane")
I mean the opposite. You should know exactly where your team sits in the larger organization. What your team's product feeds into. What teams talk to yours. What the company's biggest bets are right now and whether your team is contributing to them or just maintaining something on the side.
This isn't political maneuvering. It's context. And without context, you're just coding in a vacuum.
When I started actively learning about the full product, attending meetings I wasn't strictly required to be in, reading dashboards that weren't "mine", using our product as an actual user, everything changed. I stopped building features in isolation and started understanding why things existed and where they fell short.
That context is what let me spot the gap that turned into a multi-million dollar feature. It wasn't genius. It was just having enough visibility to connect dots that were obvious once you could see them.
The AI era makes this even more urgent
Here's something I don't think enough people are talking about: AI is compressing the feedback loop between product ideas and shipped code. What used to take a team two sprints can now be prototyped in a weekend. The bar for "just ship it" has dropped dramatically.
This means the engineers who just execute tickets are getting easier to replace. Not by AI itself (yet), but by other engineers who are using AI to move faster while ALSO bringing product thinking to the table.
The most valuable engineer in 2026 isn't the one who can close the most Jira tickets. It's the one who can figure out which tickets shouldn't exist, which ones are missing, and why the backlog doesn't match what the business actually needs.
If you want to grow faster right now, don't just clear your board. Clear your board AND find a problem that isn't on anyone's board yet. That's the move.
The uncomfortable truth about promotions
Nobody gets promoted for doing exactly what they were told to do. That gets you a good performance review. Maybe a small raise. But promotions, especially at big tech companies, go to people who demonstrated impact at the next level BEFORE they got the title.
That means you can't wait for permission. You can't wait for the perfect ticket to land in your sprint that magically demonstrates senior-level thinking. You have to go create that opportunity yourself.
Talk to other teams. Use your product obsessively. Read the business metrics, not just the engineering dashboards. Ask your PM why the roadmap looks the way it does. And when you spot something that could be better, don't file a ticket and hope someone picks it up. Build a prototype. Write a one-pager. Show people what's possible.
That's what separates the engineers who get promoted in a year from the ones who are still waiting after four.
So here's your challenge
Next week, spend one hour doing something that isn't on your Jira board. Just one hour. Use your product like a real user. Talk to someone on a different team. Look at a dashboard you've never opened. Read a design doc from a project you're not involved in.
You'll probably find something interesting. Maybe even something broken. And that thing, the problem nobody asked you to solve, might be the most important work you do all year.
Your Jira board is someone else's plan for your time. The question is whether you also have a plan of your own.
Little about me : Full-stack engineer with 5 years in the industry, currently at PayPal building consumer products used by millions.
