Stacey on Software

What Would You Say... You Do Here?

December 29, 2025

There’s another scene in Office Space that doesn’t get quoted as often as the TPS reports or the red stapler.

The Bobs are interviewing Tom Smykowski, a nervous middle-manager who senses the axe hovering above his neck. They ask him, point-blank: “What would you say… you do here?”

Tom fumbles. He explains that he takes specifications from the customers and brings them to the engineers. He’s a people person! He deals with the customers so the engineers don’t have to!

The Bobs blink. “So you physically take the specifications from the customer and bring them to the software people?”

“Well… no. My secretary does that. Or the fax.”

It’s painful to watch. Tom can’t articulate his value because he’s never had to. The system has allowed him to exist in a role that may or may not matter, and nobody — including Tom — has ever stopped to ask.

But here’s what I find interesting: the Bobs aren’t asking a mean question. They’re asking the right question. What does this role actually do? What problem does it solve? Is there a better way?

That’s solution thinking. And it’s rarer than you’d expect.

Finding the Best Answer We Can

Last time, I talked about resolution — the art of patching symptoms without addressing root causes. Resolution asks: “How do we make this friction go away?” It’s memos and checklists and gates. It’s comfortable. It’s also how organizations slowly calcify.

Solution asks a different question: Given what we actually understand about this problem, what’s the best response available to us right now?

Not perfect. Not theoretical. Not “if we had infinite time and budget.” Just: what’s the best we can do with what we know and what we have?

Russell Ackoff described solution as finding an optimal (or near-optimal) answer within current constraints. It requires something resolution doesn’t: genuine curiosity about what’s actually happening.

Remember the fourteen-gate deployment process from last time? Resolution would add a fifteenth gate. Solution meant asking “what decision does each gate enable?” — and discovering that most of them enabled nothing at all.

The Impediments We Tell Ourselves

Here’s the thing. Most people I work with want to solve problems. They’re not committed to bureaucratic theater. They’re not in love with their TPS cover sheets. When you ask them, they can usually articulate what’s broken and often have ideas about how to fix it.

So why don’t they?

I’ve heard a lot of reasons over the years. Let me offer some reframes.

“I don’t have the authority.”

Maybe. But authority is often fuzzier than we assume. I’ve watched junior developers reshape entire processes just by asking good questions in the right meetings. I’ve seen individual contributors quietly stop doing pointless work and wait to see if anyone noticed. (Often, they don’t.)

You might not have authority to mandate change. But you almost certainly have authority to ask questions, propose experiments, and model different behavior. That’s often enough to shift the system.

“Nobody will listen.”

Perhaps. But “nobody” is rarely accurate. Usually it’s “the specific people I’ve tried haven’t been receptive.” That’s different. It means there might be other people — peers, skip-levels, adjacent teams — who would listen.

And sometimes “nobody will listen” really means “I haven’t found the right way to frame this yet.” The same idea can land completely differently depending on how it’s presented, who presents it, and when. If the idea matters, it’s worth trying different angles.

“We tried that before and it didn’t work.”

This one’s tricky, because sometimes it’s true. But “we tried something like this five years ago under different leadership with different constraints and it failed” doesn’t mean the same approach would fail today. Context matters. Timing matters. Execution matters.

I worked with a team that had “tried pair programming before” and concluded it didn’t work. When we dug in, it turned out they’d tried it for two weeks, with no training, while simultaneously being pressured to hit an aggressive deadline. That’s not a fair trial — that’s setting up a straw man to knock down.

If something didn’t work before, it’s worth asking: What specifically didn’t work? What was the context? What would we do differently?

“We don’t have time.”

This is the big one. And I’m sympathetic, because it’s often genuinely true. You’re juggling fires. The roadmap is packed. There’s no slack in the system for thinking.

But here’s my question: do you have time to keep not solving this problem?

Every hour spent on workarounds, on re-explaining the same issue, on cleaning up the same recurring mess — that’s time too. The question isn’t whether you have time to address root causes. It’s whether you have time waste cleaning up the same messes over and over.

Sometimes the answer really is “not right now.” That’s fair. But sometimes “we don’t have time” is a story we tell ourselves to avoid the discomfort of change. It’s worth being honest about which one it is.

Solution Starts with Curiosity

The Bobs, for all their faults, demonstrate something useful in that scene with Tom. They ask a genuine question: what does this role do?

That’s solution thinking in embryo. Not “how do we cut headcount?” — that’s resolution, optimizing for a symptom. But “what problem does this role solve, and is there a better way?” — that’s trying to understand the system.

Solution requires curiosity. It requires admitting that we might not fully understand the problem yet. It requires being willing to ask questions that feel obvious or uncomfortable.

Here’s what I’ve found: the best solutions usually come from people who are willing to look naive. They ask “why do we do it this way?” when everyone else has stopped asking. They notice the things that have become invisible. They’re not smarter than everyone else — they’re just less attached to the current answer.

Making Space for Solutions

So how do you actually do this? Here are a few moves that have worked for me:

Start with one problem you actually understand. Not the biggest problem, not the most political problem — just one where you genuinely grasp what’s happening and why. Solution thinking is a skill. Practice on something tractable before you tackle the org-wide dysfunction.

Ask “what would good enough look like?” Perfection is the enemy of solution. You’re not trying to design the ideal system — you’re trying to find the best available response. Sometimes that’s a 60% improvement. Sometimes it’s just “fewer incidents per month.” Define what success looks like before you start optimizing.

Run small experiments. You don’t need permission to try something different for a week. “Let’s skip this meeting for two sprints and see what happens” is an experiment. “Let’s try deploying twice as often with half the ceremony” is an experiment. Small experiments generate data. Data changes conversations.

Find your allies. You’re almost certainly not the only person who sees the problem. Find the others. Sometimes solution thinking is lonely work, but it doesn’t have to be. A small coalition of people who agree “this is broken and we should try something different” can move mountains.

Make the invisible visible. A lot of dysfunction persists because nobody’s tracking it. Start measuring. How long does this process actually take? How often does this failure recur? What’s the real cost of this workaround? Numbers have a way of making problems harder to ignore.

The Opportunity

Here’s what I want you to take from this: solution is available to you. Right now. Today.

You don’t need a reorg. You don’t need executive sponsorship. You don’t need a consultant to come in and validate what you already know. You need curiosity, a willingness to ask uncomfortable questions, and the patience to try things and learn.

Most problems aren’t mysteries. They’re just things we’ve stopped looking at. The people closest to the work usually know what’s wrong. They often know what would help. The gap isn’t insight — it’s permission.

So give yourself permission. Ask the obvious question. Propose the small experiment. Find the ally. Start measuring.

The system is more malleable than it looks. And you have more agency than you think.


This is part three of a four-part series on Ackoff’s problem treatments. Next up: dissolution, and the art of redesigning systems so problems can no longer arise.


Welcome to my personal blog. Writing that I've done is collected here, some is technical, some is business oriented, some is trans related.