šŸ“ˆ
Manager RemoteU
  • Curriculum README
  • Background and Context
    • What is Manager RemoteU?
    • Why Should I Take RemoteU?
      • Testimonies (Don't Take Our Word for It)
      • RemoteU Prepares You for the Future of Work
    • What Makes RemoteU Different?
    • Our Coaching Philosophy
  • On Prem vs. Remote
    • Exposing half-truths about remote work
    • Sync vs. Async
    • Managers, Makers, and Deep Work
    • How to Avoid Burnout and Protect Your Mental Health
    • Combat Loneliness with a Great Social Life
    • 3 Ways to Build Trust With Remote Employees
    • How Remote Workers Make Work Friends
  • IC Skills
    • Mastering IC skills
  • Monday Week 1
    • Day 1 README
    • Readings
      • WSPro, the double-edged sword
      • Content vs. Process Insights
      • The Most Common Reasons RemoteU Managers Fail: How to Avoid Them, and How to Succeed (Part 1 of 2)
      • The Most Common Reasons RemoteU Managers Fail: How to Avoid Them, and How to Succeed (Part 2 of 2)
      • How to fix products (how to execute content insights for fixing products)
      • Time Motion Study
      • Tips & Tricks from Graduates
    • Examples
      • Content Insight Examples
      • Process Insight Examples
  • Tuesday Week 1
    • Day 2 READ ME
    • Readings
      • Daily Check-In Chats
      • Creating Calendars
      • How to Be a Great Coach
      • How the WSPro Frameworks Fit Together
    • Examples
      • Daily Check-In Chats - Good Example 1
      • Daily Check in Chats - Good Example 2
      • Daily Check-in Chat - Good Example 3
      • Daily Check-in Chat - Bad Example
      • Create Calendar - Good Example 1
      • Create Calendar - Good Example 2
      • Create Calendar - Bad Example
      • How to translate calendar into the Crossover Activities App
  • Wednesday Week 1
    • Day 3 READ ME
    • Readings
      • How to Enforce The Quality Bar
      • How to Deep-Dive
      • How to improve quality when FTAR is 100%
    • Examples
      • Enforce The Quality Bar Example 1
      • Enforce the Quality Bar Example 2
      • Enforce the Quality Bar Example 3
      • Bad EQB Example 1
      • Deep Dive Example 1
      • Deep Dive Example 2
      • Deep Dive Example 3
  • Thursday Week 1
    • Day 4 READ ME
    • Readings
      • Rank and Review
      • Insight Anti-Patterns
      • Good Coaching vs. Coaching Anti-Patterns
      • Quantifying Impact
    • Examples
      • Rank & Review - Good Example 1
      • Rank & Review - Good Example 2
      • Rank & Review - Good Example 3
      • Rank & Review - Bad Example 1
  • Friday Week 1
    • Day 5 README
  • Monday Week 2
    • Day 8 READ ME
    • Readings
      • Zero-Based Target
      • TMS vs ZBT
    • Examples
      • TMS vs ZBT Examples
      • ZBT - Good Example 1
      • ZBT - Good Example 2
      • ZBT - Good Example 3
      • ZBT - Good Example 4
      • ZBT - Good Example 5
      • ZBT - Bad Example
  • Tuesday Week 2
    • Day 9 README
    • Readings
      • Gemba Walks
    • Examples
      • Gemba Walk Example 1
      • Gemba Walk Example 2
      • Gemba Walk Example 3
  • Monday Week 3
    • Day 15 README
    • Readings
      • Shrink to Grow
      • Building the 2-Slide Deck
    • Examples
      • Shrink to Grow Example 1
      • Shrink to Grow Example 2
      • Shrink to Grow - Bad Example
  • Tuesday Week 4
    • DAY 23 README
  • Wednesday Week 4
    • DAY 24 README
    • Readings
      • The 2-slide Deck and Summary Anti-patterns
      • Quality bar for The 2-Slide Deck
      • MRU Oral Exam
      • Success After Graduation
    • Examples
      • 2-Slide Deck - Good Examples
      • 2-Slide Deck - Bad Examples
      • Oral Exam - Examples
  • Work In Progress (Please ignore)
    • Culture and Diversity
    • Feedback and Coaching
Powered by GitBook
On this page
  • Insight Anti-Patterns to Avoid
  • Details and Examples:
  • 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 or 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 do ___________ā€: No follow through or enforcement

Was this helpful?

  1. Thursday Week 1
  2. Readings

Insight Anti-Patterns

Insight Anti-Patterns to Avoid

Generating actionable insights from data is a core skill among elite managers.

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.

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.

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.

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.

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.

PreviousRank and ReviewNextGood Coaching vs. Coaching Anti-Patterns

Last updated 5 years ago

Was this helpful?

Poor Example 3: The in-depth analysis for all failed units in FTAR in the last 4 weeks shows that of work units fail due to missed red and severe findings in the code review which results from manual reviews.

60%