When delivering tickets stops being enough

Stop rewarding your best coders for their output and start teaching them to engineer the organization itself.

Mar 24, 2026

👋 Hey, it’s Stephane. I share lessons, and stories from my journey to help you lead with confidence as an Engineering Manager. To accelerate your growth see: AI Interview Coach | 50 Notion Templates | The EM’s Field Guide | CodeCrafters | Get Hired as an EM | 1:1 Coaching

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive. Subscribe now.

Your best senior engineer is likely hitting a wall right now. They’ve spent the last eight years mastering the “how” of software development. They can out-code anyone, they know the legacy quirks of your database, and they never miss a ship date. Yet, in your 1:1s, they sound restless. They look at AI tools handling the “grunt work” of coding and feel like their craft is losing its value. They want that Staff title, but they think the path involves getting even deeper into the stack or mastering yet another framework.

The problem is that you might be reinforcing this. If you are still measuring them by their ticket throughput or their ability to debug an incident faster than anyone else, you are keeping them stuck. At the Senior level, being a “Tech Lead” is now the baseline expectation. The jump to Staff requires a shift in how they spend their time: moving away from the IDE and toward the gaps between teams.

If you don’t help them navigate this pivot, they will eventually burn out or leave for a competitor just to see if the title is easier to get there.

From solver to connector

Most engineers spend their early career getting rewarded for being a “solver”. They are the “ticket hunters” who knock down the Jira backlog. But the terminal level for a pure solver is Senior. To reach Staff, an engineer must become a “connector”.

This means looking at the department as the system they are engineering, rather than just the app. It involves seeing where two teams are speaking different languages and stepping in to translate before a week of development time is wasted on a misunderstanding.

I’ve seen incredibly gifted engineers get passed over for Staff roles because they couldn’t influence anyone outside their own pod. Leadership at this level is about impact and scope. A Staff engineer’s best contribution of the month might not be a line of code. It might be reading a status update, realizing a project is a waste of money, and convincing leadership to kill it before a year of salary is sunk into it.

Moving beyond the baseline

Since “Tech Lead” traits are increasingly expected at the Senior level, you have to help your engineers identify which Staff archetype actually fits their strengths and the company’s needs.

The Architect: This isn’t an ivory-tower role. An Architect owns the long-term success of a critical technical domain, like your API strategy or storage infrastructure. They succeed by having good judgment that people trust. They spend their time understanding business constraints so they can advocate for the right technical direction.

The Solver: The Solver handles high-stakes, arbitrarily complex problems that lack a clear path forward. They move between hotspots as directed by leadership. The challenge for you is making sure they don’t just “fix and leave”, which can frustrate the teams left to maintain the solution.

The Right Hand: Usually found in larger organizations, this person operates as an extension of an executive. They borrow the leader’s authority to handle problems that sit at the intersection of technology, people, and process.

How to coach the transition

To get your seniors moving again, stop talking about their coding speed. Start talking about their influence.

1. The business layer: Staff engineers must sit between business needs and technical execution. Tell your senior to spend a week talking to people who lack their context - Product Managers, Sales, or Legal. They need to understand what those stakeholders care about. If an engineer doesn’t know the PM’s goals or “pain points”, they are just guessing at what to build.

2. Write a one-pager strategy: Encourage them to stop opening their IDE as their first move. Instead, have them write a “One-Pager” that defines a business problem and suggests a high-level technical direction. Then, have them “shop it around” to other leads and stakeholders to get buy-in before they write code. This is how they build the reputation for having good ideas that is required for the Staff level.

Managing the long game

This transition is often a grieving process. Your engineer might feel like they are “losing” their love for coding because they spend more time in meetings and docs. They might feel like they aren’t “doing real work” because their commit count is dropping.

Remind them that leadership is a craft in itself. They are no longer just individual contributors; they are force multipliers. Their importance is felt in the direction they set and the disasters they prevent.

Your job as a manager is to provide the safety for them to experiment with these new skills. They will likely stumble in their first high-stakes negotiation or fail to convince another team to follow their vision. Stay close to them, offer feedback, and help them see that this plateau isn’t the end - it’s just the point where they trade their old map for a new one.

If you enjoyed this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide