Ticket takers vs ticket makers

There tends to be two types of engineer on every team I've worked on. The first picks up the next ticket in the backlog, builds exactly what's described, and moves on. The second looks at the backlog and asks why half of it exists.

Both are valuable. But only one of them changes the trajectory of a product.

The ticket-taking loop

Ticket-taking is comfortable. Someone else has defined the problem, scoped the solution, and written acceptance criteria. Your job is to execute. There's nothing wrong with this. Reliable execution matters. But most engineering cultures accidentally optimise for this mode and nothing else.

Velocity is measured in tickets closed. Sprint reviews celebrate points completed. Performance reviews ask "what did you deliver?" and the easiest answer is a list of tickets.

None of those metrics capture the engineer who noticed that half the support tickets stem from the same confusing UI pattern. Or the one who realised a feature request from sales would be unnecessary if the existing feature just worked properly.

What ticket-making looks like

Ticket-making is identifying problems before they become tickets. Noticing a pattern in support requests and tracing it to a root cause. Pushing back on a spec because it solves the symptom, not the underlying problem. Proposing work that isn't on anyone's roadmap because you've seen evidence that it matters.

This isn't product management. It's engineering with enough context to have opinions about what to build, not just how to build it.

It's uncomfortable because you're accountable for the problem identification, not just the solution. You might be wrong. That's the price of having an opinion. The engineers who've had the biggest impact on teams I've been part of were the ones willing to be wrong occasionally in exchange for being right about the things that mattered most.

The organisational question

If an engineer raises a problem and the response is "is there a ticket for that?", you're teaching people to stay in their lane. If the sprint is so tightly packed that there's no room for investigation, you're optimising for output over impact.

The best teams make room for both. They celebrate the person who killed a bad idea before it became a six-week project just as much as the person who shipped a feature on time.

Here's the thing that should make this urgent: AI is getting very good at taking tickets. Not in some hypothetical future. Right now. Claude, Copilot, Cursor, whatever your flavour, they can pick up a well-scoped ticket, understand the acceptance criteria, and write solid code. They're fast, they don't get bored, and they're getting better every month.

If the only thing your engineers do is pick up the next ticket and execute what's described, you're building a team that's competing with software. And software is cheaper.

The engineers who'll matter most in the next few years are the ones who can do the things AI can't: understand the messy human context behind a problem, notice that a feature request is really a workaround for a deeper issue, push back on a roadmap item because they've talked to users and the data doesn't support it.

Do your engineers know why they're building what they're building? Do they have enough context to form their own views? When they do, is there a path for that view to become action?

If not, you don't just have a team of ticket-takers. You have a team that's about to be outperformed by a tool that costs a fraction of a salary.