I Have No Idea Yet. Give Me 20 Minutes.
I might not have seen this exact problem before, but I have probably seen most of its pieces. On solving things on the fly — and knowing which shortcut is safe to take.
One of my favorite types of problems at work starts with:
“So… we have a problem.”
Perfect.
What kind?
Sometimes I know the system. Sometimes I barely know the system. Sometimes someone is explaining a process to me for the first time while I’m already mentally rearranging the pieces.
And somewhere around minute five, my brain starts going:
“Okay, but what if we just…”
This is probably one of the things I’m best at: coming up with workable solutions on the fly.
Not because I magically know everything.
I absolutely do not.
It’s because I’ve spent enough time across different systems, teams, processes, APIs, databases, websites, and assorted technological nonsense that I’ve built a pretty big mental box of Legos.
I might not have seen this exact problem before.
But I’ve probably seen most of its pieces.
I Don’t Need to Know the Final Answer to Start
I think people sometimes get stuck because they believe they need to completely understand a problem before they can start solving it.
I don’t really work that way.
Give me the constraints.
What do we have?
What don’t we have?
Where is the data?
Who needs it?
What happens today?
What should happen?
And, very importantly:
“How quickly do you need this?”
Because there’s a huge difference between:
We need the perfect long-term architecture.
and:
This process is broken and somebody needs something by 3 PM.
Those are different problems.
They deserve different solutions.
Temporary Doesn’t Have to Mean Bad
Some of the solutions I’m proudest of were not beautiful.
They were useful.
Sometimes the right answer is a fully engineered product.
Sometimes it’s an API integration.
Sometimes it’s automation.
And sometimes it’s:
“Okay. Give me Tableau, an HTML email, and two hours.”
There’s a tendency in technology to over-engineer things because we know we can.
But the goal isn’t always to build the coolest system.
The goal is to solve the problem.
Then, if the solution proves valuable, make it better.
My Brain Is Basically Running a Prototype Before the Meeting Ends
When someone explains a problem to me, I’m usually already building a version of it in my head.
Where does the information come from?
Can I access it?
Can I transform it?
Where does it need to go?
What is the fastest path between those two points?
And what part of this entire process is actually necessary versus:
“Well, that’s just how we’ve always done it.”
Ah.
My favorite sentence.
Because there’s usually something fun hiding behind it.
AI Has Made This Even More Dangerous
This is one of the places where AI has completely changed how I work.
Before, I could come up with the solution quickly.
Now I can come up with the solution and start proving whether it works almost immediately.
That’s a massive difference.
I can explore an API I haven’t worked with.
Prototype a workflow.
Generate a first-pass interface.
Write a transformation.
Test an architecture.
Throw half of it away.
Try something else.
All before we schedule the follow-up meeting to discuss scheduling another meeting.
Beautiful.
But Speed Isn’t the Actual Skill
Being fast is useful.
But speed by itself isn’t what makes someone good at this.
The real skill is figuring out which shortcut is safe to take.
That’s where experience matters.
You have to know the difference between:
“We can absolutely hack this together for now.”
and:
“If we hack this together, accounting will somehow be on fire by Thursday.”
Not every problem needs production-grade engineering on Day 1.
But you need enough technical understanding to know which problems eventually will.
I Like the Messy Problems
Give me the thing that doesn’t have a clean answer yet.
The process everyone hates.
The system that doesn’t talk to the other system.
The manual workflow somebody has been doing for six hours every Friday because nobody stopped to ask why.
Those are my favorite problems.
I don’t need the answer handed to me.
I need the problem, the constraints, and a little room to tinker.
I might not know exactly what I’m going to build when you start explaining it.
But give me 20 minutes.
I’ll probably have something.