I stopped closing tickets. I started closing risks.
Three years ago I could proudly show 40 closed tickets in a sprint. The client was still unhappy.
Not because I was working poorly. Because I was solving the wrong problems.
Tickets are tasks someone formulated yesterday. Risks are what will kill the project the day after tomorrow. The first category counts nicely in Jira. The second barely exists there.
This is what's often called the developer owner mindset — and it took me a while to understand what that actually means in practice, not in a LinkedIn post.
The productivity illusion
Most teams measure performance through velocity: story points closed, tasks moved to Done. It's not a bad metric — it helps with planning. But it tells you nothing about whether you're moving in the right direction.
Think about this: you close 15 tickets in a week. UI tweaks, field renames, route refactors. Meanwhile, a problem quietly builds in production — cache doesn't invalidate when a product is updated. Three months later, customers see stale prices. Nobody wrote a ticket for that.
Velocity was great. The outcome wasn't.
The problem isn't Jira or sprints. The problem is confusing task throughput with project safety.
What "risk" means for an engineer — no PMBOK required
I say "no PMBOK" deliberately. Formal risk management frameworks are valuable on large enterprise projects. For day-to-day senior developer work, they're overkill and honestly intimidating enough that most people skip them entirely.
My working definition: a risk is any circumstance that can make us unable to deliver on a commitment. To the client. To the team. Or to ourselves — not shipping code we'd be afraid to touch a year later.
Risks look different depending on the project:
- A dependency on an external API with no fallback.
- A developer who's the only person who understands the integration module.
- A release date tied to a marketing campaign with no buffer.
- A DB schema that won't allow adding multi-currency support without a full refactor.
None of these show up on their own in a ticket. You have to see them.
Three questions I ask before every sprint
Before working through the backlog, I ask three questions — either to myself or out loud in planning.
First — what could prevent us from deploying at the end of the sprint? Technical dependencies, unresolved access questions, data not ready from a third party. If there's even one such blocker, it matters more than any feature in the backlog.
Second — what don't we currently know that's critical to know before the end of this iteration? Not bugs, not features — unknowns. Sometimes the right answer is a quick proof-of-concept, or just a 20-minute call with the client before writing code.
Third — if we push this to production and something goes wrong, how do we roll back? This is about rollback strategy and observability. If there's no answer yet — add monitoring first, then deploy.
These three questions take 10 to 15 minutes. They don't replace the backlog. They filter it.
I run them at the start of every sprint, not just before big releases. The cadence matters — risks compound quietly.
The risk that wasn't in any ticket
On one project we were building a large product catalog — over 28,000 SKUs, high load, caching via Redis. All current tasks were on track, velocity was normal, demos looked fine.
Two weeks before launch, I asked myself the second question: what don't we know that's critical? It turned out we hadn't tested cache invalidation during a mass price update via import. Nobody framed this as a risk — the import tasks were complete, unit tests were passing.
We reproduced the scenario on staging. Importing 5,000 products triggered a state where some pages kept serving stale prices for 40 minutes. For an e-commerce store that's real damage: customer sees one price, places an order, then receives a correction email.
The fix took three days. If we'd caught it in production — two weeks, a broken launch, and a damaged client relationship. The kind of thing that kills long-term contracts.
That ticket didn't exist. The risk did.
When owner mindset gets in the way
Shifting from "close the ticket" to "close the risk" requires context. You need to understand the product's business logic, know what the client has promised their users. That's not always written in the tickets.
It's traditionally a manager's job. When a developer takes it on, they spend time away from code.
This is a real trade-off, and I won't pretend otherwise. I'm not saying every senior engineer should operate as a product owner 100% of the time. But a few hours a week on understanding context pays off the moment you spot a risk before it becomes an incident.
One thing that helps: if there's already a project manager thinking about risks, don't duplicate their work. Owner mindset doesn't mean doing everyone's job. It means staying aware of what's happening outside your own ticket.
What changed in client conversations
The most noticeable change wasn't in speed or code quality. It was in conversations.
Before, on status calls I'd report: "closed 12 tickets, 8 still in progress." Now I say: "last week we found a cache invalidation risk and removed a potential pricing problem before launch."
The client hears two different things. In the first case — task progress that's hard to evaluate without context. In the second — protection of their business from a specific, concrete problem.
Trust gets built on the second kind of update.
If you recognized yourself in those 40 tickets — try adding the three questions above to your next sprint kickoff. See what surfaces that wasn't in the backlog.
If you've run into this pattern yourself, or landed somewhere different — reach out in DM.