WSPro, the double-edged sword

Two real-life case studies about a success story of a trained manager and the failure of an untrained manager trying to satisfy their VP's requirement of using WSPro

“Technology is a double-edged sword for sure. You can use it to get in touch with somebody, to get to know somebody, to have really meaningful conversations, or you can use it to hurt and bully people.” ~ Shannon Purser

The very same fact about a thing can be both the good and the bad thing about it.” ~ Mokokoma Mokhonoana

Introduction

WSPro is a double-edged sword.

When used properly, WSPro creates a culture of transparency, continuous improvement and trust. It is an insight machine that will provide limitless improvement opportunities for your team. You’ll also have the appreciation and support of your team because as they implement your feedback they’ll not only become better in numbers/metrics but also as professionals.

When misused, WSPro creates a horrible culture of distrust, paranoia, and fear. When perceived as a tool for bullying and firing people, your team will feel only disgust and disdain toward you and the whole company.

The following two case studies provide insights from real people and real teams working within Crossover.

Positive case study

Melly managed a complex team that never had a full-time WSPro manager before. Therefore, her ICs felt like Melly was interfering with their work by having them perform non-critical tasks, like answering questions about their TMS recordings.

Also, instead of weekly meetings, Melly held CiCs with her team, daily. Team members became annoyed by Melly’s constant questions about granular details of their work. Additionally, they were frustrated because they believed their TMS targets were unattainable.

Melly worked for three days on her first TMS, so she clearly understood the details of the work. Among other things, she discovered the reason why the team could not reach the pre-set TMS target. It was due to the extensive manual and repetitive, non-value added tasks which the process required.

The ZBT Melly performed was awesome. Through it, she learned that no less than 35% of her team’s processes could be automated. She wrote thousands of lines of code over the next week and a half.

When she finally rolled it out, the ZBT contained not only her own ideas, but ideas from her ICs too, including a way to check the status of tasks waiting for another team’s top-performing best practices.

The team became very excited and began using the tool for every new work unit they produced. One IC used the tool to more than double their throughput, and reached 100%.

Melly was also able to standardize the output template used by business-unit (BU) managers to review and approve their teams’ work. The BU managers were quite happy with the revised format, which improved the overall interaction between the team and its customers.

This huge contribution demonstrated to her team that Melly’s efforts weren’t taking their time, afterall. Rather, she was able to leverage their investment of time by a factor of ten! Two of her ICs were so inspired that, in the weeks following, they continued to submit great ideas which Melly was able to implement.

Keeping the structure of the CiCs allowed team members to easily understand the requirements of their work. And Melly’s unit-level, precision coaching continued to provide insights so the ICs knew exactly how to continue improving.

The full usage of the WSPro framework, combined with the practice of listening and genuinely caring for each team member, created an environment of mutual respect, trust, and motivation for continuous improvement.

Negative case study

Garen received a team of five architects in an area where WSPro hadn’t previously been utilized. He was not a certified WSPro expert, yet he received direction from his VP to use the standard tools, anyway.

Garen held a daily group CiC with his new team members where they reported their statuses and, when anyone was behind schedule, Garen attempted to unblock them. However, if he was unsuccessful in his attempt, Garen resorted to shouting and threatening fire the entire team.

But Garen’s leadership demeanor wasn’t his blind spot. His task-orientation also became problematic. For example, a task on Garen’s team normally kept an IC busy for one or two days, in spite of their target metric being five days.

Garen performed a TMS, but he failed to watch the videos, personally. Instead, he asked each IC to fill in their times for their activity using a generic list. This was not a good use of ICs’ time, as they had to go through their day, from memory, in an attempt to remember how much time each step took.

From his TMS, Garen was able to determine his team's top-three most time-consuming tasks:

  • writing backend code

  • writing frontend code

  • writing unit tests

Because these numbers were higher than expected, he coached his team to utilize their previous experience to write code faster. He also tasked each of them to find “some sort of unit-test generating tool.”

His team spent the next two days performing research on the unit-test generating tool. However, Garen proceeded to scold them for falling behind in their metrics. Even more frustrating, Garen took the ideas from the team, but never came back with a decision. So, the team continued performing their work with some of them (partially) using the tool they’d found, while others didn’t even bother with it.

While performing Gemba walks, Garen discovered two ICs checking their phones multiple times throughout the day. Rather than coaching those ICs, Garen wrote an email to the whole team, again scolding them, saying it was no wonder they were behind in metrics since they were all Facebooking during work hours.

Crossover pays very well, relative to each team member’s countries, so team members were willing to work long hours, purely out of fear for their jobs. (Two ICs had newborn babies, at the time.) However, this isn’t the type of motivation we’re striving for.

Mistakes

A month later, Garen’s team reached the target metric, and with 100% quality. However, along this journey to “success,” mistakes were made.

Garen’s first mistake was that he didn’t utilize TMS and ZBT properly. Rather than using these powerful tools to unlock optimization on his team, Garen delivered vague, high-level insights which only wasted the team’s time. Garen didn’t provide any unit-level insights, nor did he provide any real value back to the team.

Instead, CiCs were simply status updates, including the regular public humiliation of team members. Most ICs attended each meeting, literally, not knowing whether or not they were about to lose their job.

Effects

The overall impact on Garen’s team (and his own career) was incredibly negative. Within two months, two out of five team members voluntarily exited the company. The remaining three switched teams within Crossover and, tragically, still hold deep beliefs that WSPro is a tool for micromanaging, if not terrorizing your people. Similarly, they believe Gemba walks are used to spy on, rather than to help team members. In the end, they were left feeling insecure, apathetic, and disgusted by a system they simply no longer believe in.

To see an example, firsthand, of this negative impact, you only have to visit Glassdoor.com. In doing so, it becomes clear that, at times, our management (from frontline managers, all the way to SVP) have failed to apply the WSPro system properly.

Conclusion

Elite remote managers, who have experienced WSPro, understand how powerful it is for managing ICs remotely and at scale. However, it’s important to realize, too, that WSPro can be misinterpreted, misused, and even abused.

The responsibility for using the tools - and using them correctly, and with good intention - is the job of us all. Unfortunately, you can still find both kinds of managers within our (and every) company. So, it becomes our responsibility to elevate our culture in order to shine a light on the way forward.

Last updated