3 Tips From a Smartass on Problem Solving Basics for the Office

May 7, 2018

Having trouble getting your organization’s problem-solving skills to take hold in the office? It can be challenging.  Office work (strategy, innovation, administration) is invisible and often not highly repetitive. It usually requires creativity and collaboration across disciplines and departments. The three tips below, all of which I’ve learned by not following them myself, can help:

Tip 1: First, Write Down the Problem

My favorite response to someone who proposed a new initiative (usually my boss) was, “That sounds like a good idea, but what’s the problem you are trying to solve?”  This question forced a conversation about the specific data and underlying rationale that prompted the idea. It sometimes labeled me as a smartass (likely justified), but it also reset the discussion resulting in a more effective plan or the quick end to an eye-rolling, follow-until-further-notice, dumb idea.

Before initiating any new activity, write down the problem it is supposed to be solving.  The act of writing it down engages the conscious, thoughtful part of your brain, slows you down a bit, and may keep you from jumping to a bad solution.  When I forced myself to take the time to think carefully and write a good problem statement, it became easier to explain it to my colleagues and to engage them in helping to design the fix. It yielded better solutions and the ownership that I was so keen for them to have.

How do you know if you have a good problem statement?  Here is our checklist:

  1. Is it important? Tie it to a real business metric.
  2. Is it neutral? Don’t assign cause or solution.
  3. Is it quantified? If you can’t measure it, don’t start fixing it.
  4. Can you show current and target performance? Showing the gap helps drive change.
  5. Is it properly scoped? Even big, strategic issues should be broken down into 30 to 60-day pieces that can create more learning and faster improvement.

Tip 2:  Take a Hike

The most eye-opening exercise I ever did as an executive was to put aside what I thought was going on and, instead, I went to see what was actually going on.  Don’t start with tabletop exercises in the office, fishbone diagrams, process maps, brainstorming exercises or survey data reviews. Take a hike!

When you take your hike, don’t just listen to what people tell you, ask people to show you what they do, to show you issues, to show you what they have tried to fix and where they need help.  You can make invisible office work visible by following the path a piece of work travels. Trace the inputs and outputs through each specific person (not departments, real people). I guarantee that you will be surprised by what you find.  Not only will you be embarrassed by the problems, you might discover some cool methods your people have figured out that are not captured in your documents. Take your hike, then use the myriad of tools available to sort, analyze and understand the data you found. Then update your documents based on what you learn and what you fix.

Start with something simple and repetitive, like invoices or receivables, and work your way to tougher issues that are more complex and require ongoing creativity, like product development, or strategy implementation. Use the Four Principles of Dynamic Work Design as a framework to analyze what you are seeing.

When I did this, people doing the work always appreciated the time I spent listening to them and understanding their real issues; I invariably learned a ton. If you doubt any of this or think your work is too strategic to bother with the details of how things really happen (trying to be helpful here, not a smartass), watch a few episodes of “Undercover Boss.”

Tip 3: “Not having a process” is not the problem

We constantly see problem statements that include, “We don’t have a process for…”. This a bad problem statement because, in a very sneaky way, it steers you away from taking a serious investigative hike.  Subtly hidden in the statement, “we don’t have a process,” is the solution of “let’s have a meeting and design a process”, violating item 2 in Tip 1. As a result of starting with the solution, congratulations, you just talked yourself into a big project; a process design effort or new initiative, likely complete with expensive change management, fancy new language, and maybe some software. Chances are it will do little to resolve the real issues people are suffering through and, depending on the software, may make the work more onerous to complete.  I am pretty sure this failure mode is trademarked by Scott Adams (author of Dilbert). I am also pretty sure most of you reading this have been on both the sending and receiving end of this dynamic.  When I was an executive at Harley-Davidson, we cynically called these “AFPs”, Another F..fine Program!

The big idea: there is already a process or you wouldn’t be in business; it just is not written down and it probably has lots of problems that aren’t that hard to fix. Use Tip 2 to go find them, fix them, and quickly put some points on the board. Fix the hidden delays of work stuck in piles of email, lack of connection between departments, and poorly designed meetings that don’t deliver decisions.  Your colleagues will appreciate that the boss actually helped them (that’s an example of a smartass comment).

As a friend once advised me, “Having a leaky faucet doesn’t mean you need a new kitchen.” Rather than launch an expensive initiative or software program, follow these tips and find simple, fast solutions. Articulate a good problem statement.  Take a hike to learn what is really happening.  Genuinely engage people in resolving the worst issues and put some points on the board.  Celebrate what is working well.  THEN document what you have learned.  Repeat as necessary…frequently and forever.

I can personally attest to the pain some smartass I know suffered by not following these three simple ideas!

Don Kieffer

Don applies his significant depth of experience to solving client problems and further developing and bolstering Dynamic Work Design through his work at MIT.

Read Bio