23 Mar 2023

How do you approach a problem?

We dive into: The 4 Archetypes of a Generalist, a framework for squiggly career progression, I'll then spin these into real-world examples of what a *delightful* generalist career flow could look like

And then... a pinch of spice 🌶️ I'll be busting the myth that generalists can't reach mastery

💡 Life is basically a continuous series of problems to be solved.

I wouldn’t be writing, and you wouldn’t be reading, this sentence if we couldn’t solve problems. It’s the crux of human survival and growth.

This got me thinking… How do others approach problems? Especially in the Generalist World community, it’s chock-a-block full of expert problem solvers. I wanted to understand how they, and others, think about this essential life skill; problem-solving.

I’ve turned it into a collaborative article, so you can steal your faves and apply them to your own life and work. You can leave your own suggestions in the comments section at the bottom of this page.

To kick us off, after reading through the community’s responses, Cathy Ferrell summed it up best:

“It struck me that this group might be really selling ourselves short here.. while it seems like we 'just know' or the solutions come to us, I think we're actually using a complex set of skills and knowledge that we just might not be aware of.. things like lateral thinking, pattern recognition, critical thinking, strong imagination, and the ability to connect seemingly unrelated ideas... I think we have superpowers!”

Every person is credited, so if you enjoy theirs — do drop by and say thanks! 🙂 

🕵️‍♀️ How do you approach a problem?

Robert Berris: I would say, until the last ten years of my career, I would not be able to articulate how I solve problems; I could say I see patterns, anti-patterns, love problem solving, and eventually sketch what’s happening in a system (a system could be a process, a website, writing a script etc).

Today, because I work in innovation and it’s deeply consumer/user-focused, I have an endless supply of methodologies I use to create what I would frame as foundational knowledge to understand, identify and define problems. It started with the double diamond framework, which is largely viewed as an innovation tool to connect design thinking with problem-solving and iterative solutioning.

But, as I would interview people over the years, I realized I need to understand how people thought about thinking (meta I know, right?) and I’d ask people to help me and then walk through how they think about solving challenges, using flawed problem statements to collaborate with them.

Today, the way I think about it: one of my abilities is structuring uncertainty. And if I can empathize with the people involved, understand the context of what’s happening, identify elements that stick out to me and define what seems to emerge… there’s a whole host of methods I can use to visualize that information, well-before I ever started to create prototypes or solutions

Laurie Richards: I hadn't tried to lock down my framework until my job search a few months ago when I got this question repeatedly, so I spent quite a bit of time trying to look for the patterns and methodology I took. I ended up with two takeaways that I used in my answers.

I used to have "work the problem" (the seal's mantra) on my whiteboard, meaning stay focused on the actual problem you're trying to solve and check back in on it so you don't get off track, and so everyone is working on the same problem. the second is putting some names to my approach, which were: assess (research, interview, etc), plan (prioritize, communicate, change mgmt planning), execute, integrate, and re-assess. it's not perfect, and it isn't exactly what I do every time, but it helps me communicate to others the buckets that I use.

In reality, I almost always start by creating a Google sheet, and jotting down notes, links, metrics, or an agenda for a conversation and eventually it morphs into something.

Sakshi Shukla: Here are a few thinking elements I use while solving problems:

  1. Imitation: Empathy is the first step to solving any problem. Who am I solving for? What are those persona/personas like? Being able to step into people's shoes and almost feel their life and struggles helps me ideate better. Whether it's my client or my client's client, or my audience or product users that I'm writing for - without knowing who they are - I cannot solve for them.

  2. What differentiates an avg problem solver from a great one? First principle thinking. For me, this has meant breaking down the problem into its constituents. I often zoom out of the problem to look at the macro impact and then zoom into each constituent to understand how they impact each other. It's almost like building a user experience wireframe. I typically do this using mind maps on Miro.

  3. The elevator-pitch solutioning. Marketers are obsessed with making things concise. So I figured, what happens if I simplify a problem into a single line. (The best pitch decks do this) - this works because helps me (and VCs) be SO clear about what the exact missing piece is.

  4. Where's the most fun? I like to optimise for fun, so when I think of solving problems from a fun POV - it helps me think creatively too.

Lucy Ignatiadis: Quite often I find if I read/research/understand the issue, and have a rough idea of the solution needed, my brain will work on it while I am completely unaware and quite often presents itself to my conscious mind at inopportune moments.

Nic Errol: My overarching context is looking at it like an emergency, ie what is the most time-sensitive and critical thing that needs to happen, and from there, prioritise needs. Then that allows me to figure out what/who I need to involve and then break down the elements.

Often it is “what's the most difficult part of the equation?”, and is that in itself something doable or not. It's no point spending energy on other less critical elements if that 1 crucial must-have can't be progressed. Other tactics, I often find leaving the problem, going for a run, and asking people who aren't in the know to get perspectives is also really helpful. And I play a game that Tim Ferris talks about, which is akin to 'if this was easy, what would it look like'.

Richard Brookfield: In general my brain is trying to maximize the probability of a desired outcome. Our brains aren't naturally good with statistics (thanks Thinking Fast and Slow) but we are absolutely hard-wired for comparisons and you can leverage this trick to dance with probability.

First by analyzing and trying to understand the problem, goal, etc. What are the elements that it consists of. What are the levers that have a material, causal, etc impact. Generative thinking. I call this spiderwebbing. My brain sort of starts generating a number of pseudo solutions around various levers. Some are feasible/viable and others are terrible. While generating these potential solutions, you start to uncover ways to weight ideas or parts of an idea. These could be things like effort/impact, feasibility, likelihood of happening, etc. And while I can't give a probability of success here, I can use the filters in conjunction with multiple solutions to start comparing one solution to another. It's easier for my brain to say "this is likely better than that" From here I start to better define the few remaining concepts and play-test them in my head. Like the uncovering of filters, I start to uncover additional indicators for measuring the efficacy of efficacy of a solution. I tend to bounce back and forth between this stage and the previous stage as I further refine..

Eventually I start to get to socializing and further refinement based on additional thinking and perspectives. 

Adam Field offers up his Miro framework, which he calls The Rubber Duck

Stephanie Hammer: I use the Design Thinking process (on important problems) because it ensures that I focus on users instead of my own (biased) solution.

In Design Thinking there is a bias on action and the timed aspect helps me get going. Design Thinking is NOT a panacea for everything, but it works especially well at the start of a project (when you're first approaching a problem) because it helps you "go wide," understand, explore, and interview before starting to solve anything.

Tig Campbell-Moore:

  1. Reflect on symptoms

  2. Attempt to diagnose the cause of the problem

  3. Decide if I am currently equipped to solve it

  4. Reflect on who else may be better equipped to solve it

To sum up, I had to finish with Tara’s ever-so-elegant description 👇🏽

“It’s encouraging to see other people saying they do a bit of an idea-vomit-and-then-add-structure process, that’s very typical for me, it’s just that the structure differs depending on the problem”

Touché Tara, touché 😅

📚️ Further Reading

Till next time,

Milly 👋🏾

Subscribe our newsletter to never miss an essay

Subscribe our newsletter to never miss an essay

Our content is brought free to you, courtesy of the Generalist World community memberships.

Our content is brought free to you, courtesy of the Generalist World community memberships.

Subscribe our newsletter to never miss an essay

Our content is brought free to you, courtesy of the Generalist World community memberships.