People Prefer Organizing Problems Instead of Solving Them

I have a theory I've tested on myself, on colleagues, and on enough Jira boards to lose faith in rectangles:

Most people would rather organize a problem than solve it.

I've also learned the harder version - the one that actually hurts:

I've had many chances to solve problems and couldn't, because the people in charge either didn't care about fixing them, couldn't express that priorities were different, or wanted to be visible for their own sake.

In security, that last motive isn't annoying. It's dangerous.

The comfort of the sort

A team faces a vague threat: "We might miss the compliance deadline."

Within 48 hours:

• A new Jira epic.
• A Confluence page titled "Compliance Initiative - Overview."
• Labels multiply: Q3, risk, regulatory, needs-discussion.
• A Slack channel with a 📋 emoji.
• A meeting to schedule the next meeting.

Everyone looks busy. Almost nobody shipped a control change.

The problem was categorized, not reduced.

I do this too sometimes - reorganize my task manager instead of sending the hard email. Satisfying. Useless. Temporarily calming.

When you're allowed to organize but not to fix

The personal version is procrastination. The professional version - especially in security - is blocked remediation.

I've been in rooms where:

• The vulnerability was known.
• The fix was understood.
• The effort was small.
• The risk was real.

And still nothing shipped - because the person with authority didn't want the problem closed.

Why?

They don't care. It's not their OKR. It won't happen on their watch. Someone else will inherit the breach narrative.

They can't say priorities differ. Easier to nod in a risk meeting than admit shipping features beats patching infra this quarter.

They want visibility. Launching a governance initiative gets them in steering committees. Merging a one-line config fix does not. Ego decisions wear project management costumes.

I've watched people propose new frameworks to address a class of issues while a specific, exploitable finding aged in a backlog - because frameworks are meetings and fixes are accountability.

Why this hits security harder

Security work is already abstract to people who don't live in it. That makes performative organization especially seductive:

• Maturity models with pastel gradients.
• Risk registers that never shrink.
• Threat models printed once and shelved.
• Tooling purchases that "centralize visibility" but don't close findings.
• Quarterly alignment on methodology while SQL injection persists.

I've seen teams spend months "aligning on risk approach" while a critical issue waited for an owner.

The deck was gorgeous. The exposure was also still there.

Ego-driven visibility plays have a body count. Not immediately - later, when someone exploits the thing everyone agreed was bad but nobody prioritized because closing it didn't make anyone look important.

Threat modeling, done right, drives design changes. Done performatively, it's sticker collection. The difference often isn't competence. It's incentive alignment.

What I couldn't fix - and what that taught me

The frustrating pattern:

1. You identify a real issue.
2. You propose a proportionate fix.
3. Someone senior creates a workstream, a deck, or a tiger team.
4. Weeks pass.
5. The issue remains.
6. You're told to "stay aligned" and stop escalating "prematurely."

Prematurely. As if exploitation respects governance cadence.

I used to think bigger proposals would win - more thorough analysis, more standards citations, more diagrams. Now I think quick wins are the moral center of security engineering:

• Patch the thing.
• Close the port.
• Rotate the credential.
• Add the validation.
• Ship the config change.

Small, fast, verifiable. Boring fixes don't get you photographed at the town hall. They keep people safe.

I'm learning to lead with quick wins even when the organization wants a parade.

Organizing vs solving - the test

Good organization serves execution:

• Clear owner and deadline.
• Definition of done.
• Blockers escalated, not curated.

The test I use now:

If we stopped organizing right now, what concrete action would be impossible?

If the answer is "none," you're decorating.

Second test, specific to security:

If this issue is exploited tomorrow, will anyone wish we had run one more alignment workshop instead of merging the fix?

Usually yes.

The people problem behind the process problem

This isn't really about Jira. It's about who benefits from motion without closure.

Organizing is socially safe:

• Low rejection risk - taxonomies get nods.
• Visible progress - cards move on boards.
• Anxiety reduction - structure feels like control.
• Expertise performance - consultants deliver operating models before anyone touches production.

Solving is socially expensive:

• You choose and cut.
• You can be wrong publicly.
• You own maintenance.
• You might embarrass someone who said it wasn't urgent.

In security, the person blocking the fix often isn't malicious. They're optimizing for visibility, budget narrative, or conflict avoidance - while you optimize for exposure reduction.

Those timelines diverge until incident response reunites them.

Quick wins as political strategy

I don't mean sloppy fixes that create tomorrow's incidents. I mean minimum viable remediation - the smallest change that materially reduces risk now.

Examples:

• Disable the feature instead of redesigning it for six months.
• Block a dangerous endpoint at the gateway while the app team refactors.
• Rotate secrets before the audit deck is finished.
• Add logging before the SIEM integration is "strategic."

Quick wins build credibility. They also remove ammunition from the organizers - harder to justify a quarterly initiative when the critical finding is already closed.

I've started pitching fixes as: two hours, this owner, this verification step. Make the cost of delay obvious.

What I'm trying to do differently

When I catch myself - or others - organizing instead of solving:

Timebox research. Two hours, then ship or escalate with a recommendation.

One owner, one date. Not "the team."

Default to smallest fix. Patch the hole; schedule the cathedral.

Escalate with impact, not volume. One paragraph: risk, exploitability, fix, time estimate.

Measure closes, not workshops. Risks remediated beats risks discussed.

Closing

We like organizing problems because sorting is infinite and fixing is finite - and fixing has consequences.

I'm writing this as someone who loves systems and has definitely reorganized a backlog to avoid a hard conversation.

But I've also watched ego and visibility incentives leave real holes open while everyone looked productive.

In security, that's not a productivity annoyance. It's how breaches happen.

Organize if it helps you act.

If it helps someone stay visible while nothing gets fixed - call it what it is.

Then go merge the quick win anyway.

Even imperfectly.

Especially imperfectly.

That's how issues actually die.