Earlier this year we changed something small in description and large in effect: we stopped handing engineers individual tickets and started handing them epics. An epic is a larger chunk of work (a whole feature, or a meaningful slice of one) that still needs to be broken down into individual tasks before it can be built. The breakdown now happens during the work, by the engineer doing it, rather than up front by someone else.
It sounds like a process tweak. In practice it has changed how shared understanding moves through the team, how much context engineers carry, and how much ownership they take. It’s a good example of how the day-to-day of software work is shifting as AI-assisted tooling matures, so it’s worth explaining what we changed and why.
01 · The shiftFrom pre-defined tickets to epics.
The old model was familiar to anyone who has worked in software. Larger pieces of work were decomposed ahead of time into individual tickets, each describing one slice, and engineers picked up those pre-defined tickets and executed them. Planning and execution were separate phases, often handled by different people.
Under the new model, an engineer (who has already been part of refining the PRD, breaking large product requirements down into individual epics) receives the epic and does the task-level planning themselves, breaking it into individual tickets on the fly as they go. Tickets still get created and tracked; but instead of arriving pre-defined, they’re written during execution by the person closest to the code, using AI-assisted development tooling to move quickly between planning and building.
Recent improvements in the underlying models are what made this a natural next step rather than a leap. When the tooling can hold more context and help an engineer reason through a breakdown in the moment, the up-front decomposition stops being a prerequisite and starts being overhead.
02 · Why we did itRemoving the rework of planning apart from doing.
The core benefit is that it eliminates the rework that comes from refining tasks separately from executing them.
When planning happens in its own phase, you’re making decisions about work you haven’t started yet. And some of the most important discoveries, like a missing edge case, a cleaner approach, or a scope that turns out to be wrong, only surface once you’re in the cycle of execution. Under the old model, those discoveries meant going back and revising tickets that had been carefully written days earlier. The planning was real work, and a meaningful share of it got thrown away.
Pushing the breakdown closer to the work means fewer planning cycles and less throwaway refinement. The engineer learns something mid-build and adjusts the next ticket immediately, because they’re the one writing it. The plan and the reality stay in sync because they’re being produced by the same person at the same time.
03 · The tradeoffEpics have to carry more.
This isn’t free. If the engineer is doing the breakdown, the epic has to give them enough to do it well. That means epics now need to carry more information than they used to, and that’s a good thing: clearer acceptance criteria, better context on the why behind the work, and sharper scope so it’s obvious what’s in and what’s out.
We invest less in pre-writing individual tickets and more in getting the shared understanding right at the PRD and epic level. What we’ve found is that the investment pays back. Time spent building genuine shared understanding at the epic level, rather than dictating tasks, gives senior engineers more ownership of how the work gets done, and we’re seeing it produce better final outcomes.
04 · The bigger pictureWhat this says about how work is changing.
Step back and the specifics matter less than the pattern. The shift is away from handing people narrow, pre-defined instructions and toward handing them well-framed problems and the context to solve them. The detailed decisions move closer to the people doing the work, and the role of planning shifts from specifying every step to establishing clear intent and boundaries.
This is the direction a lot of knowledge work is heading as AI tooling gets better. Work and roles are compressing. When the cost of moving between thinking and doing drops, it stops making sense to separate them into different phases owned by different people. Better shared understanding up front, more context in the hands of the person executing, and more ownership as a result.
The engineers building your software carry more context about what they’re building and why, and have more room to make good judgment calls in the moment instead of waiting on a re-planning cycle. That tends to show up as better decisions and fewer of the misunderstandings that come from work passing through too many hands.
05 · Where we are nowCommitted, with some housekeeping.
There’s some expected housekeeping that comes with a change like this: updating tooling, templates, and the workflows built around the old model. None of it has changed our conclusion. We’re fully committed to this way of working going forward, and we’ll keep refining how we write epics as we learn what makes them most useful.
Founder of r90
Former CTO of Vanco
Writes about the method underneath modern software companies and engineering organizations. Read more →