How I Get Sh*t Done: Part 3 - Solving Complex Problems
If Part 1 was about deciding what to work on, and Part 2 was about actually doing it when life is trying to make a fool of you, Part 3 is about what happens when the work in front of you doesn't have an obvious solution, the path forward is murky, and you're the person people are looking to for some kind of answer.
No pressure, right?
This is where I've had to grow the most honestly, and where I've found the most satisfaction. It turns out that complex problem-solving isn't just about being clever. It's about being structured, being honest about what you don't know, and (this is the bit I really want to dig into) not hoarding the thinking.
First, A Confession
(Cue Usher: Confessions)
For a long time, I thought "solving problems" meant figuring it out yourself and being the clever kid arriving with the answer, waving their hand up frantically. Like the scene in every heist film where that one person has the whole plan in their head and everyone else just needs to show up in their fit. Efficient! Decisive! And also, in practice, a bit of a mess.
It's so rare you'll have all the context to solve most big problems on your own. Someone else knows the customer. Someone else has been sitting with tthe process way longer. Someone else has tried a version of this before and hit a wall you haven't seen yet.
The frameworks I'm going to share - they're not just for solo thinking. They're arguably more powerful when you use them with other people.
The Boxing Method: Contain Before You Solve
The Boxing Method is simple: before you try to solve anything, you cluster.
What's actually in scope here? What's not? Who owns the problem(s)? What does "solved" actually look like? What's the real deadline - not the emotional one?
Drawing the box forces the problem to stop expanding. And it's a surprisingly powerful thing to do with the people involved. I've been in conversations where two people were solving entirely different versions of the same problem and neither of them knew it. Getting everyone to agree on the box first saves hours. Sometimes days.
It also has the added bonus of occasionally revealing that the problem is smaller than the panic suggested. Not always. But sometimes. And sometimes it is good.
First Principles Thinking: Strip It Back
The idea is to strip a problem back to its fundamental truths and build up from there, rather than reasoning by analogy - i.e. "we do it this way because that's how it's always been done."
In practice, it sounds like this:
What do we actually know to be true here? What are we assuming? Why are we assuming it? If we had to build this from scratch, would we build it the same way?
I used this recently when reviewing a truth that everyone agreed was painful but no one had changed. When I asked why it worked the way it did, the answer was essentially "…it's always been like that."
First principles meant I could separate what was a genuine constraint from what was a habit and status quo. I was quite the agent provocateur with the title of the narrative. “Why is the thing so hard?”
Where this gets even more interesting is in a group setting. Asking "what do we actually know?" together surfaces assumptions people didn't know they were making. And it does it without blame. No one's wrong. We're just starting from facts instead of folklore.
Pre-Mortems: Kill It Before It Dies
A pre-mortem is what happens when you imagine it's six months from now and the project has failed spectacularly. Then you work backwards: why did it fail? It sounds grim but it’s actually incredibly useful!
The classic post-mortem happens after something's gone wrong - which is perfect and should be done as much as they do - learning is learning and it's okay to do something wrong (which we will) as long as you learn from it.
But a pre-mortem happens before you start, which means you get to do something about the risks rather than write a retrospective about them. In practice - a planning conversation could prompt: "Imagine this has completely bombed. What went wrong?"
What you get back is gold. People will say the things they were worried about but didn't feel like they could raise. "We didn't have buy-in from X." "The timeline was unrealistic." "We didn't account for Y dependency."
It's also - and this is the bit I love - a quiet act of psychological safety. You're not asking people to be critical. You're giving them a fictional frame to be honest. Different thing entirely.
Navigating Ambiguity (The Part No Framework Fully Solves)
Here's the thing about complex problems: sometimes the path forward isn't unclear because you're missing a framework. It's unclear because knowledge is totally dispersed, the situation is new, and there isn't a right answer yet - or the perfect trifecta of all three, which I often find myself in.
The uncomfortable truth is that there's no framework for "we're all a bit lost."
What I’ve found helps is:
Name it. Say "I don't have full clarity on this yet, here's what I do know, here's what I'm going to find out."
Timebox the ambiguity. Ambiguity doesn't mean indefinite drift. "I'll have a clearer view by Thursday" is a commitment. Make it, then meet it.
Consult the edges. The people closest to the problem. Go find them. Ask the person who's actually doing the thing. They will almost always have something important to say.
Knowing When to Pause
There's one more call worth talking about, and it doesn't get enough airtime: knowing when the most productive thing you can do is slow down… or stop altogether.
Not because you're stuck. Not because motivation has left the building. But because you can see clearly enough that continuing is going to create more problems than it solves. Every step forward is a step you'll need to retrace. The work has stopped being neutral and started accumulating debt - operational, technical, structural - that someone or something is going to have to pay back at a much higher rate in the future.
This is harder than it sounds, because pausing mid-flow feels like failure. Everything around you is moving, and you're the one saying "actually, wait." That discomfort is real. But leaving things as they are when something's wrong rarely makes them less wrong - it just makes the correction more expensive, and the conversation harder.
The questions I ask myself: Is this work creating dependency before it's been validated? Are people starting to build around something that isn't ready? Am I moving at this pace because it's right, or because slowing down feels uncomfortable?
Naming it to yourself is the first step. Naming it to the relevant people is the braver one. But in my experience, "I think we need to take a beat on this" - said clearly and with a reason -- lands better than most people expect. It demonstrates that you're thinking beyond the immediate output. And that's usually exactly what's needed.
Elevating Others: The Part That Matters, And Actually Multiplies Everything
I've spent most of this series talking about how I get sh*t done. And I mean it -here’s the stuff that's helped me stay functional during periods that were absolutely not cooperating.
But the honest truth is that the most impactful thing I do isn't the problems I solve alone. It's when I help someone else solve theirs - or better, when I help or inspire someone else develop the muscle to solve their own.
This isn't altruism (well, not entirely). It's good systems thinking. Especially as I've moved through seniority, I realise that if I'm the only person who knows how to do something, that's not a strength - it's a bottleneck. If I clear a path and don't show anyone how I found it, I'll be clearing the same path forever.
So practically, here's what that will look like for me:
Share the frameworks, not just the outputs.
When I'm working through a problem with someone, I'll try to narrate the thinking. "Here's why I'm asking this question." "Here's how I'd triage this." “Here’s how I’m hanging this shirt up kiddo”.
Not because I think I'm especially wise or good at laundry, but because watching someone think through something is often more useful than receiving their conclusion.
Ask before answering.
Or let the uncomfortable pause roll over you. This one is harder for me, honestly, because I like to pretend I don't like to wear capes. But "what have you already tried?" and "what's your instinct?", before I weigh in or fill the void means I'm developing someone's thinking rather than replacing it. And sometimes - fairly regularly, actually - their instinct is right.
Name the contribution.
Visibility matters. If a peer has done good thinking, I say so - loudly, in the right rooms, in front of the right people. Credit is not a finite resource. Naming someone's contribution doesn't diminish yours. It demonstrates that you're the kind of person who sees good work and says so. Which, in my experience, is the kind of person people want to work with.
Create conditions for others to be the expert.
I've learned more from being put in a room and expected to know things than I ever did being handed the answers. Giving people the chance to be the expert - actually handing them ownership of something, then getting out of their way and being a resource to them - is one of the most developmental things you can do. Uncomfortable for everyone at first. Worth it every time.
Wrapping Up
So! We’re done! Three parts. Prioritisation, execution, and complex problem-solving with a side of not doing it all alone.
If there's one thread that runs through all of it, it's this: good systems aren't about being more productive. They're about being more intentional. About making deliberate choices about where your energy goes, rather than just reacting to whatever's loudest.
And that's equally true for how you grow the people around you as it is for how you manage your own work. The most effective teams I've been part of - and the ones I want to continue to build in my programs - are the ones where people are helping each other get better. Where the thinking is shared. Where silos are the folklore. Where the wins are visible. Where it's less about individual heroics and more about what you can accomplish when everyone knows what they're doing and why.
That's the actual goal. Everything else - the Pomodoros, the PARA, the pre-mortems - is just scaffolding tbh.
Build something good, and build each other up.
✔️ Moves “Complete Productivity Series” to Archive
