All Work Must Be in Jira
The unpopular rule that saved every team I've led
This has been my mantra for the past decade across multiple companies where I worked as a CTO.
I know, I know. Another process guy. But hear me out.
Why I Push This So Hard
On one hand it’s about protecting engineers. You know the pattern - PM pings someone on Slack: “Hey, quick question, can you just look at this thing?” Three days later that engineer is still on it while their actual sprint work rots. Sales sends a “critical bug” directly to whoever responds first. Marketing needs a “tiny change.”
Without a forcing function, engineers become victims of whoever has the loudest voice. Jira isn’t bureaucracy here - it’s protection. It gives everyone the right to say: “Happy to help. File a ticket and we’ll prioritize it.”
On the other hand, it prevents the “what the hell is he doing” frustration. I’ve been in those meetings. A stakeholder asks when something is shipping. You turn to your team and get vague answers. “Soon.” “We’re working on it.” When stakeholders can’t see what’s happening, they fill the void with anxiety. They start interrupting engineers for status updates. They escalate.
The rule isn’t surveillance. It’s transparency. And transparency creates autonomy - when people can self-serve their status updates, they stop interrupting your team.
The Data Behind This
On protecting engineers from interruptions:
Gloria Mark’s research at UC Irvine found it takes 23 minutes to refocus after an interruption. Sophie Leroy at University of Washington calls this “attention residue” - part of your brain stays stuck on the previous context. The more engaging the interrupted task, the worse it gets.
Five interruptions a day? That’s two hours of lost focus. Every day. Studies estimate context switching can reduce productivity by up to 40%. Interrupted tasks take twice as long to finish and contain twice as many errors.
On transparency reducing overhead:
The Project Management Institute found that 56% of project failures cite ineffective communication as the primary cause. When stakeholders can’t see what’s happening, they fill the void with meetings, Slack pings, and escalations.
When everyone sees progress as it happens, status meetings become lighter - or disappear entirely. Managers who know what’s happening without asking can focus on decisions instead of chasing updates.
The Early Stage Exception
Of course, if you’re an early stage startup with few devs, skip all that and just keep things rolling. Those engineers have a product-mindset anyway. They’re talking to customers, shipping daily, small enough that coordination happens naturally.
But 10 people and beyond? Things get messy without clear processes and Jira hygiene.
The complexity of coordination scales with team size. Four people have 6 communication channels. Ten people have 45. Twenty people have 190. Without structure, information loss becomes inevitable.
“Just Fix Culture” Doesn’t Work
Haters might say, you just need to fix culture or motivate people. But I’ve been there - highly motivated team, excellent people who genuinely care about the product.
And you know what? Until it’s a habit, hygiene slips.
Because motivation doesn’t create habits. Passion doesn’t override human cognitive limits. Even the most dedicated engineer will forget to update a ticket status when they’re deep in debugging. Even the most diligent PM will slip on documentation during a crisis.
Hygiene isn’t about motivation. It’s about systems. And systems only work when they’re mandatory.
One Hacker News commenter captured the anti-process view: “Tickets in Jira are not the work itself - it is a LARP of the work. Fixing a bug without filing a Jira ticket is in itself progress. Moving a Jira card without any other change is not.”
And they’re right - the ticket isn’t the work. But the ticket enables the coordination of work. And in any team larger than a few people, coordination is the bottleneck, not individual execution.
What I Actually Saw Work
I saw this play out - and the research backs it up.
Less frustration on both ends.
The American Institute of Stress found that 80% of employees report “productivity anxiety” - the constant feeling they should be doing something else. The cure? Clear priorities. When engineers see exactly what’s expected, they stop second-guessing. When stakeholders see progress without asking, they stop pinging.
Gallup reports that 41% of employees experience high daily stress, with unclear expectations being a major driver. A shared backlog fixes this for everyone - assignees know what to work on, reporters know where their request stands.
Better strategy and prioritization.
You can’t prioritize what you can’t see. Professor Paul Nutt at Ohio State found that 50% of strategic decisions fail - but structured visibility into work improves success rates to 80%.
When all work lives in one place, leadership stops guessing. They see what’s actually consuming engineering time. They make trade-offs based on reality, not whoever yelled loudest in the last meeting.
The Anti-Patterns to Avoid
Let me add - doing this wrong is way worse than not doing it at all.
Over-engineering workflows is the biggest mistake. Complex state machines with multiple approval gates don’t enable agility - they codify bureaucracy.
Required fields backfire. When every ticket demands ten mandatory fields, users fill in garbage data just to satisfy the system. If a field must be required, always include an “I don’t know” option.
Using Jira as communication tool creates fragmentation. Teams add notes, tag each other, hold conversations in comments instead of having actual discussions. Jira is a system of record, not Slack replacement.
Looking Back
After a decade of pushing this rule, here’s what I can tell you.
The teams that resist process the loudest are usually the ones drowning in coordination overhead. They just don’t see it. It’s death by a thousand Slack pings.
The teams that embrace visibility - even grudgingly at first - eventually become its biggest advocates. Because they discover something: when everyone knows what everyone’s working on, trust increases. The need for meetings decreases. Engineers actually enjoy their tools.
Both camps have valid points. Heavy process without purpose creates waste. Absence of discipline creates chaos. The path is narrow - hard limits that force prioritization while keeping signal-to-noise ratio high.
Is it unpopular? Sometimes. Does it work? Every single time.
What’s your experience? Do you enforce ticket hygiene or think it’s process theater? Drop a comment.