Pareto Charts

By a show of hands, who here knows the 80/20 rule?  Anyone?  OK, a few of you.  It’s a simple concept that is amazingly consistent.  It goes something like this…

  • 80% of your defects are a result of 20% of the causes.
  • 80% of your revenue comes from 20% of your customers.
  • 80% of your productivity will come in 20% of your working hours.

…and so on.  It’s not always perfect, but the gist of it is that there are usually a lot of little things and one or two big things that drive results.  And, in theory, it makes sense.  But how do you show it?  Enter the Pareto Chart. Named for Vilfredo Pareto, helps to illustrate this in your problem solving exercises.  Let’s take a look at an example.

Let’s look at the pieces of the chart:

  • The vertical bars represent discrete data.  Each bar is a single cause of the overall effect being examined (in this case, reasons for late arrival).  You can see the count at the bottom of the chart.  Data elements are always listed left to right in decreasing order.
  • The blue line represents the cumulative percentage, increasing from left to right.
  • The left axis is the discrete count of incidents for each cause data point.
  • The right axis is the cumulative percentage of the causes, compared to total events.

OK, so what does it mean?  Well, it’s a simple way to show that most of your issues are caused by one or two main culprits.  Building a chart like this will help you safely ignore a whole lot of little things and focus on the big ones.  In this case, most of the “late arrivals” are caused by alarm issues.  No need to worry about traffic or hot water issues.  Just deal with the big ticket items, and your results will change dramatically.

Simple?  Yup.  A bit elementary?  Indeed.  Powerful?  Sure can be.  Especially if you need to align your stakeholders and resources on a few efforts.  Visually aides are always useful in this regard especially if there is someone really passionate about traffic or hot water at the table.  Pareto charts can help you get them focused, move away from emotional debate, and get your efforts on the right track.

 

From the Archives: Affinity Mapping


There are plenty of tools you can use in implementing a good idea.  And plenty of ways to generate a lot of ideas.  But how do you figure out what to do when you have a lot of ideas and only a limited resource set?  Today, we’ll look at one method to heard your cat-like brainwave, affinity mapping.

Affinity maps, also called affinity diagrams, are all about taking lots of ideas and whittling them down into manageable buckets.  The easiest way to do so is to set up your idea generation the right way from the start.  This means getting a clear understanding of the issue (think “how do we increase revenue 10% with minimal investment?”, not “improve performance!”).  As ideas are generated, put them on sticky notes and post them up on the wall to be reviewed.  It might look a little something like…

Ideally, you’re going to have at least 20 ideas on the wall.  If not, go back to the generation phase.  You need to think more before you start actions.

Next, the  ideas you have generated are sorted into these categories by the entire team, and this is the fun part, without discussion.  Why?  It helps you focus on the idea on the page, not the history (“That’s never worked before!”), the feasibility (“We’ve never found a way to do that!”) or the personal connection (“You just put that up there because you want to hire my sister!”)  It’s fine to move things that have been moved already.  It’s fine to move someone else’s idea.  Just keep going until the sorting slows to a crawl.

Not all notes will find a home.  Some ideas are real outliers.  They are often the really, really good ones.  Or the really, really bad ones.  Either is OK at this point.  If no one can figure out where it belongs, let it stand alone.  If there are clearly strong feelings about placing an idea in more than one group, don’t get hung up on it.  Make a duplicate of the idea and put it in both places.  No big deal.

Once that is done, work as a team to create a headline or summary for each group.  (Yes, it’s fine to speak to each other again.  But if you really enjoy the silence, then keep it up.)  For example, from our revenue question above, we might have groups that include:

  • Staffing
  • Product Innovation
  • Marketing
  • DSOs/Accounts Receivable
  • New Channels for existing product

When complete, your idea board will look more like this…

Now you have a mass of ideas that are somewhat sorted.  You can take the buckets and break them down further, eliminate duplicates or ideas that aren’t feasible, and work toward deciding if any of these are valid solutions to your problems.

If you’ve used this method and have additional thoughts, or if you have any questions on it, please feel free to leave a comment below!

From the Archives: SIPOC

This one goes out to my man John Nykolaiszyn.  Dude loves him some SIPOC.

SIPOC is one of the least used and least understood tools in the box.  A rudimentary understanding of it can make you look like an expert.

SIPOC stands for Suppliers, Inputs, Processes, Outputs and Customers.  It looks a little something like this…

Pretty simple, right?  The more complex versions are followed by a basic process map.  Let’s break it down and see the how and why of using it.

Why am I doing this?

SIPOC is a great tool for the times you are called in to help someone else fix a problem.  If you have no background with the process, this is where you start.  It’s also a good place to start when the process owners can’t verbalize exactly what they do or how they do it.  The components are pretty straightforward.

Suppliers:  Upstream.  Who do you get things from?

Inputs: What do you need to get the work done?

Process: What is it, would you say, that you do here?

Outputs: What has to happen for you to be “done”?

Customers: Downstream.  Who cares about this process working correctly?

How detailed does it have to be?

Not detailed at all.  The SIPOC is a starting point, not a “fix-it” tool.  Here’s an example of one for talent acquisition:

The nice thing about starting with the SIPOC is that is will prompt discussing with the team around who and what are really involved.  For instance, in the above example, we have only three customers listed.  They all make sense, and they are the people that we often think of as customers of talent acquisition.  And we are likely to build our process to serve them.

As a facilitator, though, your role is to challenge that assumption.  So you might ask “What about the candidates?  Are they customers, too?”  Of course they are.  But if they aren’t listed, you won’t be designing the process for them.  And if the process owners don’t realize it, you need to help them figure it out.

Is that it?

Almost.  We also like to have a high level process map, just to get an idea of what gets done.  This is not a detailed Visio map.  It is a very simple version.  For example:

Easy, right?  But this is the starting point for deep dives.  Remember, this tool is most useful in a situation where you come in with little to no knowledge of the process.  You will eventually want to do a more detailed process review, but this will get you started.

OK, so I made a SIPOC.  Now what?

Once you have a basic understanding of the process and the elements, you can start working on the issues.  But don’t toss the SIPOC aside.  I find them to be most useful stuck on the wall where they are always visible.  If nothing else, you will want to keep that customer list in front of you as work to improve and redesign a process.  That list will help you remember who you are working for, and will often help in decision making when you reach a tough question.

Little’s Law

Um…not Chicken Little. That’s totally different.

**WARNING – MATH AHEAD**

Play around with Lean long enough, and it is bound to happen.  Someone will ask you to do math.  It’s ok.  You can handle it, I promise.

Lean is about reducing waste, increasing speed and efficiency.  The end result should be faster completion of tasks.  How do you know if it is working?  Well, you measure it, of course.  In the manufacturing world, you can grab a stopwatch, walk the line, and see how long it took to produce a particular widget.  Excellent.  The transactional world is a bit different, though.  That’s where Little’s Law can help.  Here’s the formula…

Amount of WIP (Work In Process)

Lead Time =  ———————————————–

Average Completion Rate

Let’s break that down, shall we?

Lead Time

The answer to the “how long does it take?” question.  This is the metric we want to drive down.  You may also see this called “Takt Time.”  It tells your client how long they should expect to wait between submission and fulfillment.

Amount of WIP (Work In Process)

The number of items on which you are working.  Any task you have touched is WIP.  (You can read more about WIP here.)

Average Completion Rate

How many of these tasks did you complete in a day/week/month/year.  A simple counting exercise.  You may not know how long it really takes you to complete a talent development session, but you probably know how many you did last week.

Nothing too scary here, right?  So what does it mean?  First, if gives you a solid foundation on which you can start to calculate how long those tasks actually take.  Second, it tells us that to improve your cycle time, you have to either increase the completion rate or reduce the WIP.  If we go way back to our discussion on the Process Equation, you’ll recall that we aren’t likely to change the completion rate (the Y in this case) without changing something about the steps in the work (the set of Xs).  That takes time.  But the WIP is totally in our control, as we have discussed.

It’s worth noting that your cycle time starts when any given request enters WIP.  Work in the holding queue isn’t WIP, so the clock starts when you touch the request.  Some of you may be crying foul at this idea.  If I don’t count the time a request waits for me to work on it, of course I’ll finish it in less time.  Yup.  And you’ll do it in such a way that you free up the time you spent trying stay organized, and you can focus on production.  That time adds up to more work completed, which also drives down cycle time.

This will require you to create a baseline cycle time based on your WIP capacity.  Otherwise, you will be comparing an unlimited WIP to a limited one, which are not the same thing.  Don’t get caught up in that.  Lean Accounting goes through the same thing when first starting.  You are changing your measurement system and your work system.  You can’t compare the old system to the new one with metrics that only apply to one of them.  Try, and you’ll get some messy, misleading data.

You have to change your way of thinking, and start measuring differently.  I promise you though, you’ll see a difference as you use the WIP queue and measure your cycle time consistently.  Get your quick wins here, then start pulling apart the Xs of your Average Completion Rate.  This is a great tool to help you understand your workload and get it under control.  And remember, measuring your cycle time isn’t just a good idea.

It’s the law.

 

Crack the WIP

WIP is a fundamental Lean concept, and in general is the biggest obstacle to productivity in your life.

WIP, or Work In Process, is the queue of emails, call, requests, forms, approvals, and other assorted minutiae of your daily routine.  WIP encompasses all the work that is on your plate at any given moment, regardless of how much attention you can spare.  As humans, we have a limited about of GAC (give-a-crap) to go around, so we have to make decisions on the fly about how to parse it out.  We also know that the more important work often gets pushed aside to deal with the loudest demands.  It’s suboptimal, but it’s life.

Wouldn’t it be nice to have a little more control?  Of course it would.  But to get there, you have to take a path that is a bit counterintuitive.

To make your life easier, you need to reduce the WIP.  You can’t control the requests for your time in most cases, but you can set up a system to control the flow of the requests.  And believe it or not, doing so will help you work faster and reduce the time it takes to get to each request.  But that’s another post.

Your filter will require a few things.

Define Capacity

There are some fancy formulas you can use to calculate your optimal workload.  But for the sake of simplicity, think about how many tasks you can actually do at any given time.  For example, I’ve talked with recruiters who tell me they can work on twenty requests at a time, but more than that slows us down.  This is part of that counterintuitive mindset I mentioned.

Think of your work like a highway.  Plenty of research has shown that a road has a certain capacity at which it can optimally function.  Adding just one more car slows everyone down.  That’s why you see stoplights for cars entering the highway in areas with high congestion.  They are controlling the cars entering the road, which are essentially WIP.  They are items in transit from point A to point B.  Adding too many slows down each item.

What’s your capacity?  We’ll talk about those formulas another time.  For now, just realize you can’t do everything at once, and trying to do so will hurt each and every item in queue.

Selection Criteria

So if you don’t work on everything at once, how do you know where to start?  It’s probably fair to say that not every request you receive is of equal value or need.  Some are more time sensitive, some may have a greater impact on the organization, so may just be really difficult.  It’s up to you to determine how you handle each of them, and which one needs your attention.

You can’t evaluate them individually to decide how to queue them, though.  The moment you do so, they are WIP, which defeats the purpose.  Not to mention the fact that the time you spend evaluation is waste.  And that’s not OK.

Instead, you need to establish selection criteria, your own personal triage unit.  For a handy tool, refer back to the piece on building a Weighted Decision Matrix.  Build your criteria and add the weights.  Don’t forget Time In Queue.  Otherwise there is work that might never get done, and that’s not likely to make for happy customers.  In the end, you should have a simple tool that will tell you which item enters your WIP next.

One more thing, though.  People are not WIP.  A customer standing at your desk can’t be asked to stand to the side until you have capacity for one more thing.  Lean is about providing value to your customer.  They get your attention.  That’s why we don’t run at 100% capacity.  But that’s another discussion as well.

Holding Area

So you’ve figured out how much you can handle, and which items you will work on next.  What about the rest?  Where does it go?  Where is this “queue” we keep talking about?

It depends on your situation.  In some cases, such as a large department with a central workload, there may be a gatekeeper who doles out the work as you are ready for it.  Central staffing teams can work this way with a lot of success.  If you are on your own, though, you’ll need to be your own gatekeeper.  Of course, you’ll have to do it without actually touching the request.  Because that makes it WIP.

This is a great area to leverage technology to help you.  Build a request or ticket system.  Have an automated response system to let your requestor know you evaluate items as they come in and will add them to your workload to give them the optimal return time, and keep them updated on status.  If you have your selection criteria ironed out, ask the requestor to fill in the criteria so the request can triage itself.  Then take them as they come.

Yes, you’ll have to look at incoming requests occasionally.  But you don’t need to look at each one.  Use your holding area to gather them up and review them in batches.

You will be amazed, I think, at how much time you spend telling people you don’t have time to get to their request right away.  Building a queue that can triage itself and feed you work as you are ready for it will free up that time, and allow you to focus on the “value added” work of fulfilling those requests.  By reducing the number of things you are working on, you can spend more time on the real work, complete tasks faster, clear out the queue and provide a better overall customer experience.  Counterintuitive, but it works.

 

From the Archives: Transactional Lean

With ILSHRM11 in the rearview mirror and HR Florida quickly approaching, I thought this a great opportunity to share this primer again.  If you were in the session in Chicago, this is some extra information for you.  If you are joining the session in Orlando, this will get you in the right frame of mind.  Enjoy!

If you haven’t worked in operations or quality, Lean Six Sigma can be a daunting prospect. How does a manufacturing style apply to HR? What’s it all about? What does it mean for you and your job?

The good news is that LSS can be applied in the transactional world with great results. As part of a new effort to focus on education and tool sharing, I’d like to open with an overview of value and waste, the two primary components of any process.

What is Value?

We start with looking to separate “valuable” activities from waste. How do we define value? We don’t. The customer does. But an easy way to think about it is to imagine your customer’s reaction if your activity appeared on an invoice. For example, your customer, a hiring manager, says “find me a great mechanical engineer!” Let’s break down some of the activities in that process…

Value Added Activities:

  • define the right parameters for the job search
  • reviewing resumes
  • presenting well qualified candidates

These are important things that the manager wants to have take place. The two days that passed prior to starting the search while waiting for an approval by my manager on a form that outlines HR’s responsibility in this task is not. And no customer would willingly pay for that time.

Seeking Waste

When we start looking for improvement opportunities, we start with the classical definitions of waste. You can find these in all workplaces, all work types, and all parts of the organization. There are traditionally seven wastes:

Overprocessing - Working on a task or product beyond the customer’s specifications

Waiting - idle hands

Motion - having to turn, twist, lean or stand in order to complete your task

Inventory - as Taiichi Ohno famously said, inventory is death. Any time you have inventory, your money is tied up sitting on a shelf.

Transportation - walking from place to place or, more common, moving work-in-progress from place to place so it can be completed

Defects - mistakes, rework, or unusable final products

Overproduction - making more units than needed to satisfy customer needs

And, a special bonus eighth waste:

Underused people – whether it be idle time, lack of work or just not realizing the potential of your team members

Once you understand your process and have identified the waste, the next step is to understand which activities are truly not “value added” and work to streamline the activity, integrate or automate the process, or eliminate the waste wherever possible. As an example, here is a typical transactional event from everyday life, fast food pickup. This is, of course, an example of a process gone wrong.

  1. Arrive at restaurant (Elapsed time – 0:00)
  2. Wait 5 minutes in drive-through line (Elapsed time – 5:00)
  3. Wait on cashier to be ready for order while cashier accepts payment from another customer (Elapsed time – 5:30)
  4. Place order (Elapsed time – 6:00)
  5. Cashier reads order back (Elapsed time – 6:30)
  6. Wait in line to reach drive through window (Elapsed time – 8:00)
  7. Pay for order (Elapsed time – 8:30)
  8. Receive change (Elapsed time – 9:00)
  9. Wait for food (Elapsed time – 11:00)
  10. Receive food (Elapsed time – 11:30)
  11. Check order; If mistake found, park, return order, wait for correction (Elapsed time – 12:00, more if mistake is found)

Now, here’s an example of a revised process with a few minor changes and the impact:

  1. Arrive at restaurant (Elapsed time – 0:00)
  2. Wait 3 minutes in drive-through line (Elapsed time – 3:00)
  3. Place order (Elapsed time – 3:30)
  4. Wait in line to reach drive through window (Elapsed time – 4:30)
  5. Pay for order (Elapsed time – 5:00)
  6. Receive change (Elapsed time – 5:15)
  7. Move to second window (Elapsed time – 6:00)
  8. Receive food (Elapsed time – 6:30)
  9. Check order; If mistake found, park, return order, wait for correction (Elapsed time – 7:00, with fewer mistakes overall )

Notice the overall time has been reduced from twelve minutes to seven, an improvement of more than 40%.

What is that improvement worth to the business?

Intuitively we know that the improvement is significant, but the changes we suggest will have a cost to implement, so how do we quantify the value of the improvement? Here are where good metrics and valuations come into play. How much is a 40% improvement worth? Assuming a twelve minute cycle, you will be finishing five transactions per hour. If each transaction has an average sale total of $10, we are producing $50 of revenue per hour. Assuming twelve hour days for a full year, that equates to $18,250 in revenue per year.

If we reduce the cycle time to seven minutes, our hourly transactions jumps to just over eight. (We will round down for simplicity.) This brings our yearly revenue to $28,800, an improvement of nearly 60%. Simple answers, powerful results. The times in this example are clearly a “worst case” scenario for a restaurant, and are intended to show how you can apply Lean thinking in the transactional world.

What’s coming up in 2011?

This overview should set the stage for this year’s focus on on tools and learning. Moving forward, expect to see more about how to use and when to apply the very simple but powerful tools that LSS can provide.

From The Archives: Metric Waste

I’ve been working on a project to create standard processes for the global HR community with my organization for the last two years or so. One of the questions that always comes up is around measurement. How do you measure adoption rate of the processes? How do you know when people aren’t using them? And what are you going to do about it if someone doesn’t want to use them?

We’ve developed a self-assessment to see if a location is aware of the processes and if they are using them, as well as gather their feedback. But we are after more than compliance, we are after the usefulness of the processes and improvement opportunities. We can record adoption rates from there, if we really want to, but it’s all based on self-reporting, which we all know can be spotty at best.

More to the point, though, the question is why would we care? Because we would only want to invest the time and effort into measuring and reporting if it was important. Isn’t it important to know if our process are being used? More and more, I’m convinced the answer is no.

Standard processes are, in most cases, a building block toward something else. In our case, they are pre-work for an HRMS and self-service implementation. We will build upon the basic framework with regional/country adaptations that outline the changes needed for local laws, and then build out the technology and tools on top of that. The use of the standard processes is, to me, secondary. If it were the end goal, then it would certainly warrant reporting. But as an intermediate step, I’m not so sure.

As I’ve said before, new processes/tools/widgets are only going to be successful if they are better than the old version (or at least are perceived by the user to be better). If our long term deliverable, including those systems and tools, aren’t better than the manual way of doing work, we will have failed, and no one will use them. If we do present a new system that is an improvement, people will flock to it. And then the measurement of that interim point isn’t as important.

Trying to measure the success of an intermediate step is, I think, a distraction. Feedback is good, of course, but should be gathered in the context of preparing for the next step. More importantly, trying to measure usage of a manual process would be far more resource intensive than it is worth. And once you know that, why would you spend any more time working on it?

If we are building a system to the needs of the user, it should be their feedback (or lack thereof) that should matter. So keep your communication lines open, listen to them, and give them what they need.

Solve Problems Like A Five-Year-Old

 

Ah, the wisdom of youth.  Did you know that five year old children know the secret to root cause analysis?  True story.  It goes something like this:

“WHYWHYWHYWHYWHY?????”

Small children ask “Why?” up to approximately 18,000 times per day.  It is also a question Sakichi Toyoda used to ask a lot.  Toyoda was one of the brains behind the Toyota Production System (TPS) that helped the automotive giant become the gold standard for process excellence.  I heard the reports were something to see as well, with really great cover pages.

This method, generally known as “five whys,” is a simple way to get to the root cause of a problem.  I think we can all agree that the first answer you get is likely to bring you another question if you care enough to keep asking.  For instance:

“Why do you write about comic books characters instead of Google+ like everyone else?”

“Well…I like comic books more than Google+, I guess.”

OK, fair enough.  But that’s not the root cause of the issue, right?  It’s just another layer down.  So we keep going…

“Why do you like comic books so much?”

“I read them a lot as a child, and have always enjoyed keeping up with the character development.”

Huh.  Interesting.

“Why did you read a lot of comics as a child?”

“My family owned a drug store, and I was forced into hard labor as a pharmacist at the age of three.  Comics were my only real friends.”

After just three questions, we are in a much different place than where we started.  But that’s what root cause analysis is all about.  You go where the questions and answers lead you.  And until you get to the root of a problem, you’ll never really fix anything.

Why five?  Because, that’s why.  Will five always get you the root cause?  Nope.  Sometimes three will do, sometimes ten.  But you have to start somewhere.

There are a few drawbacks to this tools.  First, you can’t come up with root causes you don’t know about, so you are limited to the knowledge of the person answering you.  That’s OK.  You shouldn’t ever rely on one person to answer the question anyway.  Also, you’re likely to get a different set of answers from each person you talk to.  That’s OK, too.  It widens your net.  Most big problems have a lot of contributing factors anyway.  Getting input from several stakeholders can help you scope the issue appropriately and keep you aware of the related issues that may come up later.

What about templates for this tool?  I have good news.  There aren’t any.  You can use Five Whys in lots of ways.  Just about any work you are doing, be it a case study, fishbone diagram, benefits design or group therapy can benefit from dropping in the occasional set of Whys.  Try it out.  You may be surprised at where the questions lead you.

PowerPoint 101

As we gear up for the fall conference season, I’m starting to get the sneak previews of presentations that will be used in various places.  There are a few simple rules to building good presentations, but they clearly haven’t been shared with everyone just yet.  So, as a public service, here are a few of the lessons everyone should know by now.

Colors

Colors are good.  But let’s not get garish.  Keep them muted unless you are really looking to draw attention.  Also, colors evoke emotions, and you can use that to your advantage.  If you remember nothing else, remember this:

  • Green means good.
  • Red means bad.

That first rule of finance will help keep you in line.  Even if you aren’t reporting on financial data, stay with it.  Business leaders, which hopefully means your audience, are programmed to respond in certain ways to those color.  Help them stay in the right frame of mind.

Words

Words are bad.  Words are hard.  But most importantly, words mean reading.  And if I’m reading, I’m not listening, am I?  Don’t ask your audience to divide their attention.  Keep the words in your notes and off the screen.  OK, a few words is fine, but keep it to a minimum.

I have seen people at conferences who pick up a copy of the presentation material when they walk in the door (as is often provided), glance through the slides, realize all of the content is included, and walk out.  When you can read the notes later, why stay to have them read to you?

A good rule of thumb as a presenter is that if the slides tell the whole story, they don’t really need you.  And we all like to be needed, right?

Bullet Points

Some people will tell you they are forbidden.  I disagree on this one.  I use them for effect, but I try to limit them to two or three words each, and no more than three in a list.  Even then, they have to really mean something to make the page.  But if you remember the point above from Words, you can use them effectively to pull attention to your point.

Images

Images evoke feelings, just like colors.  Only more.  So get good ones.  Make sure they are high quality, relevant to your point, and interesting enough to look at for a few seconds.  DON’T use grainy pictures.  DON’T use stock pictures that still have a watermark on them.  DON’T use the ubiquitous smiley faces on every slide.  Do any of those, and your audience will hate you, and you’ll look like a rube.

Length

There’s plenty of arguments here as well.  I’ve been told twenty slides for sixty minutes is right.  I generally do double that or more.  But I move through slides quickly because I want the presentation to be visually interesting. In the end, the number of slides you use will depend on your topic and your style.  But I would have a hard time staying on one slide for more than a minute or two without feeling like I am boring the audience, unless it is a tool or technical piece I am working through and I have the audience engaged.  But if in “lecture” mode, you can bet I’ll be moving on before then.

Animation

Good animation can make the presentation less dull.  Great animation can help you make your presentation sparkle.  Bad animation can sink you.  How can you tell the difference?  If the animation draws attention to something you are saying, it is good.  If it distracts, it is bad.  If you can’t tell, you should probably do without.

What else?

I’m sure there are other great tips out there.  If you have one, feel free to share in the comments.  Together, we can stamp out bad presentations.

Honing your BS Detector

truth-detector

Papa Hemingway once said, “The most essential gift for a good writer is a built-in, shock-proof, shit detector.  This is the writer’s radar and all great writers have had it.”  It doesn’t matter if you are a great writer, a hack writer, or have never written so much as an email, that shit detector is one of your most valuable tools.  I won’t pretend to be an expert on reading body language, facial micro-expressions or detecting changes in breathing or skin temperature from across the room, but there are a few sure signs that the person with whom you are conversing is completely full of shit.

1) Non-committal answers

No one likes a soft response.  And most people give them when they have nothing else to say.  But answering a question without saying anything is a skill that all good bullshitters will deploy without thinking twice.  Professional athletes are the best at this.  Listen to any interview Ozzie Smith ever gave during his playing days.  You’ll hear phrases like “one game at a time” and “try my best to help the team.”  He worked really hard to say nothing.  There’s a reason for it.

2) Long, meandering response to a simple question

We’ve all had to tap dance around a topic, and try really hard not to say what we were thinking.  Once you’ve done it, you can tell when your conversation partner is doing it, too.  And just like you, they are doing it to avoid saying something they either can’t say or just don’t want you to hear.

3) Answering a question other than the one you asked

Ever asked one question, only to get a wealth of knowledge about an unrelated item?  You may get plenty of information, though you may not care about any of it.  But with this “accuracy by volume” approach to conversation, the true bullshitter often gets away with saying nothing by saying a lot.

4) A straightforward answer, followed by a hedge

This is the most frustrating of the bunch, I think.  You’ll get an answer, think you’ve made progress in your search for meaning, only to meet with a “at least, as far as I know.  But that could change.”  Then, once their bullshit is uncovered, they have the benefit of plausible deniability on their side.

 5) Really big, really technical terms

Anyone who litters their conversation with irrelevant jargon or prodigious verbosity can be  almost assuredly full of shit.  Or a Wharton graduate.  Or both.

 So, what can you do about it?

Nothing.  Mostly, anyway.  Sure, you can try to trap them in written communication, but there’s no reason to think they will be more forthcoming.  You can ask for clarification, but they aren’t likely to suddenly decide to give you the information they have so carefully suppressed.  More than likely, if you call them on using tactic #3, they will switch to tactic #5 and hope you don’t notice.

As an HR practitioner, of course, you’ll see more of this than most people.  More shit gets slung at HR than any other profession, on topics that range from why Dave missed work to Betty’s third grandmother dying this year(six in the last two years, if you are counting).  People managers are known to sling a little as well, of course (“I did all my performance reviews on time!  The computer must have lost them!”), as well as the occasional executive (“This is the last round of layoffs, for sure”) and candidate (“Counter offer?  No, I can’t see accepting a counter offer from my current company, even if they offer one.  It’s not about the money, I really want to work for your organization!”)

Your best defense is to hone your detector so you can tell when the bullshit is being flung in your direction, and then learn to duck.

Lean HR is using WP-Gravatar