Solve the Problem, and Get Out of the Way

A Phrase That Needs a Second Sentence

There's a phrase I've used with clients and colleagues for years: solve the problem, and get out of the way.

The first half never needs explaining. The second half almost always does, because "get out of the way" sounds like walking away — finish the job, drop off the keys, stop answering the phone. That isn't what I mean at all. I want long relationships. Some of my favorite work has come from someone I'd built something for calling back years later with a new problem.

What I mean is narrower, and more demanding. I don't want to become part of the business process I was hired to improve. If someone needs me to run their report every month, tweak a routine question, adjust a schedule, or perform some ordinary operation they could have done themselves, I have to ask whether I really finished the job. I may have automated one piece of their work and quietly turned myself into a dependency for another.

A good application leaves the business more capable and less dependent on its developer. The people who own the process can operate it, configure it, measure it and adapt it, and I stay close enough to be useful when something genuinely new comes along.

Not a Stack, a Habit

People tend to ask what kind of developer I am and expect a list of technologies. .NET, SQL, SharePoint, React, Azure — I've worked in all of them over more than thirty years, along with a few I'd rather not admit to and several that no longer exist. None of them is why I still enjoy the work.

The honest answer is that I like solving problems. I like sitting down with someone who's trying to get something done, finding out why it's harder than it should be, and building whatever makes it easier. My title says solutions architect, and the architecture matters. But the part of the work I still do with my own hands is application development: understanding a business need well enough to design the fix, and then building it myself.

Technology is the tool. Solving the problem is the point.

The Request Is a First Draft

Most software requests arrive as proposed solutions. Someone asks for a report, a new approval step, a portal, an integration. Sometimes the request is exactly right. Often it's one person's best guess at a fix for something they haven't fully described yet — a first draft of the problem, written in the vocabulary of a solution.

So before I build anything, I want to know what decision the report will support, what risk the approval step is supposed to control, and what happens today when the process breaks. The business knows its own operations far better than I do, and I don't walk in assuming otherwise. But the business also shouldn't have to be its own software architect. What I bring is experience, curiosity and technical judgment, offered inside a conversation where the business supplies the purpose.

That's exactly why the "just tell me what to build" mindset bothers me so much. It deserves more than a paragraph, and I'll come back to it.

Job Security Comes From the Next Problem

I never liked the idea that the safest developer was the one nobody could replace. Know where every setting lives. Be the only person who understands the nightly job. Make the system need you.

The longer I worked, the less sense it made. A developer who becomes indispensable to a single system has tied their future to that system. They spend their days keeping old work alive instead of taking on new problems, and the business carries a risk it may not even know it has. That risk compounds. Every month the dependency stands, more gets built on top of it, so the cheapest time to unwind it is now.

I wrote about this more directly in The Art of Making Yourself Replaceable, the essay where a third-grader at career day asked whether that meant I couldn't keep a job. This is the same idea seen from the business's side of the table. The people who own the process should be able to run it without me — and that's precisely why they'll want me back. Real job security comes from solving the current problem well enough that someone trusts you with the next one.

Build for the Changes You Can See Coming

Businesses change constantly, in small ways. A policy gets revised, someone new takes over a process, a question that mattered this year stops mattering next year. If every one of those changes needs a developer, the software becomes a bottleneck for the very business it was supposed to help.

I like to say I build LEGOs and the business builds the creations. I make dependable pieces and the rules for how they fit together, and the people who understand the business decide what to assemble. That doesn't mean making everything configurable — a sprawling settings screen can be worse than a few lines of plain code. The skill is telling the changes that are likely and worth supporting from the ones that only seem possible, and building for the first kind.

Know What Success Looks Like Before You Start

I want to know what success looks like before I write a line of code, and I mean business success. Code that compiles, tests that pass and a project plan at 100 percent tell me the implementation can be trusted. They don't tell me whether the problem was worth solving, or whether it actually got solved.

Both kinds of evidence matter, and they answer different questions. Engineering checks tell me the software does what I intended. Business measures tell me what I intended was useful — work that takes less time, a process people can finally see, a risk that's actually under control. When I can, I build that business view into the application itself, so the people who own the process can see how it's going without asking me to interpret it for them. I've written about the difference between features and outcomes in From Features to Outcomes, and it holds just as well for a small internal application as for a large program.

Knowledge Is Meant to Leave the Building

None of this works if I hoard what I know. Knowledge hoarding is the sign of a weak developer. The documentation, the explained decision, the training built right into the product — those are how I get the work done and move on to the next thing.

I learned that from someone who shared what he knew with me for no better reason than that I wanted to learn. He wasn't my manager and wasn't on my team; he just sat nearby, noticed I wanted to get better at SQL, and started handing me problems. The habit those problems built in me, saying "I don't know how yet" instead of "it can't be done," has an article of its own.

What AI Changed, and What It Didn't

For most of my career I've had more ideas than reach. The ideas weren't beyond my understanding. They were beyond my practical capacity — not enough hours to learn an unfamiliar platform, write the code, test it and keep it running. Plenty of perfectly good ideas lived out their lives as notes in a folder.

AI-assisted development has changed that more than anything else I've seen in this profession. I can explore a framework I've never used, get to a working prototype, and test alternatives at a pace that once would have taken a team. I recently built a puzzle game in a game engine I'd never touched, which ten years ago I wouldn't have attempted. The longer version of that three-year shift is in Ithaka Gave You the Journey.

What it hasn't changed is why I do the work. AI made implementation cheaper; it didn't make understanding the problem any less necessary. If anything, understanding became the scarcer skill. When the instructions describe the wrong solution, a faster tool just delivers the wrong result sooner. Someone still has to ask why the work matters, decide what evidence is enough, and own whether the result actually helps. The philosophy was already there; what AI changed is how far I can reach with it.

I've also built tooling for working this way, which I call DevSpark, and I try to hold it to the same standard. Its published philosophy puts it plainly: process "earns its place by improving engineering outcomes." When a process stops doing that, it's just one more problem in the way.

Writing It Down

None of this is new to me. I've worked this way for decades, across consulting, enterprise work and the projects I build on my own. What's new is writing it down as one body of thought instead of scattering it across projects, conversations and the occasional lesson learned the hard way.

The best confirmation I've had that it holds up came years after one project ended. I'd found a problem nobody had hired me to solve and built a small application that let a team run an annual process on their own. Long after I'd moved on, I learned it was still in use, still doing its job, without me anywhere near it. Hearing that someone still uses software you built, because it still does the job, is about the best compliment a developer can get.

So, back to the phrase, with its second sentence attached. Understand the problem. Solve it well enough that the business can run it without you. Then stay close enough to be invited back when the next one comes along.

Explore More

• The Art of Making Yourself Replaceable -- The career side of not becoming a dependency
• Sidetracked by Sizzle -- When the technology starts to matter more than the problem
• From Features to Outcomes -- Measuring what changed, not what shipped
• Ithaka Gave You the Journey -- Three years of AI-assisted development, and what it did to my reach