# Insight Anti-Patterns

## &#x20;**Insight Anti-Patterns to Avoid**

Generating actionable insights from data is a core skill among elite managers.&#x20;

Managers are often assigned tasks which involve generating insights and are expected to return with specific, actionable, and data-driven decisions that will improve quality and productivity.&#x20;

We have compiled a list of the most common mistakes that managers make when generating insights as anti-patterns to avoid. In order to graduate, managers will need to avoid each of these anti-patterns.

**Insight anti-patterns to avoid:**

1. Insights without an action
2. Unclear or hard to understand insights
3. Actions that add complexity
4. A plan to have a plan is not a plan
5. No timeline and owner
6. Insights with no quantification
7. Insight not based on unit-granular data
8. Useless insights that will not yield quality or productivity improvements
9. Addressing productivity before quality
10. Actions that can’t be measured
11. “I told the agents to \_\_\_\_\_\_\_\_\_” insights

## Details and Examples:

### 1. Insights without an action

**Poor Example 1:** Getting access to systems/tools is a very lengthy and time consuming process. This needs to be made easier - I'm only 3 days in and I'm already frustrated with it.

**Coaching:** this has an action to document the process for getting access to systems and tools for an agent and perform it as part of the Go-Live QB.+

**Poor Example 2:** On the productivity part, the team has no backlog. The workload depends on the way of allocating ICs on the shift hours and the influx of tickets.

**Solution:** this has an action to document the process for getting access to systems and tools for an agent and perform it as part of the Go-Live QB.

**Poor Example 3:** The in-depth analysis for all failed units in FTAR in the last 4 weeks shows that [60%](https://docs.google.com/spreadsheets/d/1Ph5tJnhknu-Ew0KH3HfYdHjRuvYU67l3-yH1y7-cpes/edit?usp=sharing) of work units fail due to missed red and severe findings in the code review which results from manual reviews.

### 2. Unclear or hard to understand insights

When you present an insight, it needs to be clear and easy to understand. After writing your insight, imagine someone 3 levels above you will read it; they should be able to understand it.&#x20;

Consider this: an insight is not complete until nothing else can be removed without losing its meaning.

**Poor Example 1:** “The most insightful observation from “Gemba Walk” on CS - QM TR this week has been "zero instances" where anyone was observed working on tickets during team meetings. This was a key finding last week and has been acted on by the team.”

**Poor Example 2:** “The most insightful\` observation from “Gemba Walk” on Central Support - Level 1 this week has been that the bottom performing agent who had the most failures in ITR misses has now had it installed in his system and as of date, he has had 0 failures in ITR running this week. We are expected to gain a 1.14% improvement in FTAR as we see 0% failures in ITR misses.”

### 3. Actions that add complexity

Managers choosing to add lots of requirements to the quality bar is the most common decision that adds complexity.

### 4. A plan to have a plan is not a plan

Instead of planning to do x to find a solution, do x right now and then present the solution.

**Poor Example 1:** The most insightful observation from “Enforce Quality Bar” on MS.SaaS Operations L2 this week has been that 81% of SLA IQB failures (which is 66.7% of total failures) happen because of tickets arrive to SaaSOps L2 engineers with breached or almost breached SLA.

**Action:** We are going to separate SaaSOps process SLA from team/engineer SLA to get better visibility into these failures.

**Solution:** This shows the manager does not understand the root cause. You don’t need to wait to understand the root cause of the problem.

### 5. No timeline or owner

Your reader should always be able to understand when this action will be taken and who will own it.

### 6. Insights with no quantification

Each insight and action’s outcome needs to be quantified with data. Avoid words like “better”, “more”, and “less”.

Poor Example: enforce >30 minute own code review, continuous update on IQB standards; increase week-start buffer

### 7. Insight not based on unit-granular data

**Poor Example:** The most insightful observation from "Daily CiCs" on Central Support - Level 1 this week has been that there has been some confusion on the quality guidelines especially with the new changes coming up on 4/1.&#x20;

**Action:** New updates on the quality guidelines have been discussed in the daily 1:1s.These actions, along with the Town Hall session and L1 Team Meeting held on Thursday strengthened the understanding of the team on the various quality parameters.

Coaching/solution too high level - does the quality bar need to be curated, or do people need to learn it? the action will be different depending on the answer - there is no data here to select the right action.

### 8. Useless insights that will not yield quality or productivity improvements

Don’t fall into the trap of identifying something that has no relation to quality or productivity (unrelated to the core of the issue). These types of insights, if addressed, will not improve quality or productivity.

**Poor Example 1:** Many non-billable tickets still require work by agents. Some agents receive more of the non-billable units (such as missed call tickets) than others based on when their shift start and with those tickets that require work but do not necessarily result in a billable ticket so no recognition on the scorecard.

**Coaching:** what is the action that will lead to better quality from the insight? I can't think of anything actionable = useful coming from this.

**Poor Example 2:** Agent doesn't get credit for some work they do.

**Solution:** 25% of the work agents do is wasted, so we should remove this work from the process and the calendar.

### 9. Addressing productivity before quality

### 10. Actions that can’t be measured

### 11. “I told the agents to do \_\_\_\_\_\_\_\_\_\_\_”: No follow through or enforcement

**Poor Example 1:** “These last two weeks I have been instructing all ICs that if they have no OPEN tickets and/or low ticket volume, to watch the Unassigned queue to see if there are some tickets you can take. Agents are instructed to check the queue and see what is there. If there is a ticket they can work, assign yourself the ticket. Agents are to only take one ticket at a time and not take another ticket until they have finished working the first ticket. This way, tickets will be dispersed by ITR as necessary.”

**Coaching:** Telling people on your team to do something is not a solution. First, the decision needs to be formally documented and then, there needs to be some mechanism of measurement or enforcement.
