The Most Common Reasons RemoteU Managers Fail: How to Avoid Them, and How to Succeed (Part 2 of 2)

Part 2: SHALLOW INSIGHTS

Controlling the “uncontrollable”

The second most common reason managers fail is that they generate - and take action on - shallow insights. Clearly, the WSPro frameworks yield deep insights, so this failure is a matter of managers improperly executing a handful of WSPro frameworks.

Simply, the easiest way to ensure you generate great insights with WSPro is to rigorously follow the instructions given for each framework, and to work closely with your coach to ensure you pass each deliverable.

In this section, we’ll observe two more RemoteU managers who avoided the temptation to make decisions based on shallow insights and, instead, used the WSPro frameworks to discover the right level of actionable insights.

#3: Coaching the "uncoachable"

Many managers fall for this, or similar, shallow insight:

Manager: “My IC keeps making simple mistakes by missing the SLA and quality bar items. I keep coaching him/her to not miss the SLA or miss important parts of the quality bar. Since the IC keeps failing, I now know that they are not coachable, and it’s out of my power to control that.”

The manager might repeat the same ineffective coaching before starting to push the IC even harder.

When the manager sees the IC making the same mistake the next week, the manager concludes that the IC is not coachable, or simply not responding to coaching.

But not all managers make this mistake…

#4: Right tools, right behavior (Anton)

During his first week in RemoteU, Anton realized that his top performing IC was using a Jira query to proactively monitor potential SLA failures.

Seeing the immense value of this simple tool, Anton coached his remaining IC’s on how to use the same query.

However, during week 2, Anton’s bottom-performing IC was still having SLA failures.

Instead of simply reiterating his previous coaching, Anton performed a deep-dive, only to realize the IC was monitoring tickets using his own (incorrect) query, rather than the query he had been provided.

So Anton improved upon his solution by creating a dashboard for the IC to use (in which the query could not be changed), rather than the direct use of a query (which could be changed).

This allowed Anton to expand the impact of his coaching, too, as he trained the IC on how to effectively use the dashboard.

Not surprisingly, the following week found the IC’s IQB score raised from 81% to 91%. However, in spite of this improvement, the IC was still having quality failures.

It would have been easy for Anton to conclude that the IC was simply uncoachable and to send him to RU.

Instead, Anton again took a deep dive and discovered that the IC was simply reviewing the dashboard too quickly, resulting in his overlooking tickets which were going to soon fail the SLA.

Anton provided written coaching to the IC explaining why he was failing, and what new behaviors were expected from him. But Anton didn’t stop there.

He also improved his enforcement of those behaviors by creating a tracker sheet which IC’s were expected to use.

Anton coached them to use the dashboard, and for each review, to add a screenshot to the tracker, along with a summary of the dashboard's current status.

This forced IC’s to slow down and really contemplate the content of the dashboard. Anton then reviewed the tracker sheet with his IC each day during his CiC’s.

The following week, the struggling IC actually became the top performer with regard to quality.

Anton didn’t choose to believe the shallow insight, nor did he pursue the easy (but wrong) solution.

His insight was not simply, “this IC is uncoachable.” Rather, his insight was, “the IC is failing because my coaching, and its enforcement, haven’t been good enough, and I need to improve upon both.”

As a result, Anton completed his RU assignment with a perfect score, and with all of his IC’s hitting their goal.

#5: Too little (data), too late

A common issue we see is managers who report that IC’s are failing on productivity targets because there is not enough backlog.

They complain, again, that since this is a factor which is out of their control, there is nothing they can do to resolve it.

However, this is a terrible insight, and one which signals that the manager has chosen to stay blocked by the first challenge they faced, instead of going further and diving deeper.

Better managers will realize that some IC’s do, in fact, have a backlog. Through a deeper dive, they’ll learn that the product portfolio of those IC’s may be different, or larger, than the ones without enough backlog.

They may conclude that more training is needed for their IC’s in new products, so they’ll have an equal backlog. Initially, this sounds like a good insight, however, it is still not deep enough, and likely won’t work as the manager expects.

The truth is that some IC’s, even with identical product coverage, won’t get the same number of tickets.

However, weaker managers won’t realize that this as the actual problem until week 4, after the training is already over. However, at this point, it is too late to take action and fix the problem.

Let’s look at a counter-example...

#6: Data-driven decision-making (Jill)

During her first week of RemoteU, Jill discovered the true nature of the backlog problem by way of her check-in chats. She consistently compared her IC’s to the top performer and, therefore, understood the need to quickly improve product coverage.

Jill knew that more training was needed. However, before jumping to conclusions, she performed a deep-dive to uncover critical insights.

Through her investigation, Jill realized that her IC’s were picking products randomly, and that they had no access to data about ticket-flowthrough, on a per-product basis.

So, she created a report in Zendesk that would determine which products delivered the highest number of tickets. And she didn’t stop there.

From the data she gathered, Jill could see that each product created a different number of tickets, depending on the time of day.

This was a meaningful insight because all of her IC’s worked at different times, according to their assigned shifts.

Jill created a report which highlighted the products that created the highest number of tickets, by shift. Then, she could reference the shift an IC worked to determine which products would generate the highest number of tickets for that particular shift.

Using these key insights, Jill created a data-driven learning plan for her IC’s, the result being that Jill completed the RU with the productivity rating of her IC’s having improved 55% over 4 weeks. A staggering success, by any measure.

Final thoughts

In this, and the previous module, we covered the two most common mistakes managers make which result in sub-optimal performance (or failure) during RemoteU.

We highlighted the three most common (bad) excuses managers make for not executing, and pointed out the perils attempting data-driven decisions using too little data. And we presented multiple case studies to support these insights.

The keys to your success in the RemoteU program will be found in your willingness to deep-dive, and in your unwillingness to make excuses, or settle for sub-optimal results.

Follow the given instructions, meticulously, and at every step of the way. Stay close to your coach - remaining coachable - and success will surely follow.