The Most Common Reasons RemoteU Managers Fail: How to Avoid Them, and How to Succeed (Part 1 of 2)
Having over 300 managers participate in the RemoteU training program has provided our team a unique opportunity to analyze manager performance, and to determine the most common reasons managers fail.
The top two mistakes identified as reasons why managers fail the program are:
Lack of Execution
Shallow Insights
This chapter diagnoses Lack of Execution, provides solutions for avoiding this mistake, and prepares you for future success.
Additionally, for each mistake, weâve included two case studies which demonstrate how the best RemoteU managers not only avoided the mistake, but were able to succeed - and how you can, too.
LACK OF EXECUTION: Diagnosis and Solutions
Believe it or not, its possible to generate great insights using the WSPro frameworks, and still be an ineffective manager. Said another way: great insights, alone, are not enough.
RemoteUâs top-performing managers have both. They use the WSPro frameworks to generate deep insights, and they know how to execute. In short, they take the right action at the right time, to produce meaningful results.
Lack of execution is the number one reason managers donât graduate from RemoteU. In fact, itâs far less important what experience youâve had in the past, or how much youâve already accomplished. What matters most is your ability to take action. To affect real change during your four weeks of training.
Insights vs. Execution
The difference between insights and execution may not be obvious at first. However, the difference is a critical one, and we should explore it further. An ancient Japanese proverb says, âVision without action is daydreaming.â
We say, insights, without execution, are near-worthless. For example, if a manager identified an automation improvement which increased productivity by 42%, but she never got it implemented, then what was it worth?
The insight, regardless of how valuable it was, did nothing to actually increase business value. Unfortunately, itâs true that great insights will not automatically foster action. An effective manager is required to bridge the gap between insight and action.
Think of it this way: to generate insights is only 10% of the opportunity; Execution - i.e., implementation - represents the other 90%.
EQB, Deep Dives, and Gemba Walks embed you into your work in a way that allows you to identify key insights.
However, itâs the R&R, CiC, Automation, and goal-setting phases which quite naturally foster actions based on those insights - and, ultimately, affect positive change.
From abstract to concrete
Managers most often struggle with execution because they donât analyze their business problems/opportunities at a deep enough level.
In order to execute meaningful solutions, you must turn an abstract problem/opportunity into a concrete one.
Put another way, great managers will consistently start with a general view of a problem/opportunity, and then transform it into a highly-specific view.
In this clip, Elon Musk expresses, in his own words, the very same concept. Faced with the high-level, fairly abstract problem of too-expensive batteries, Elon broke the problem down into its core component parts and found a path forward.
This is just the type of thinking youâll need to use to take a big, harry problem, and break it down into smaller components which are actionable tomorrow.
In fact, this is the test for whether or not youâve broken down your problem far enough. Can you take action on your smaller components tomorrow. Will you see results within one week?
If the answer is no, then you havenât broken down the problem far enough. Countless managers have gone through our program and made no progress at all because their project stayed too huge to manage.
In the world of remote management, you must continue to break down the huge problems into their smaller, actionable components.
In fact, your list of completed deliverables should grow, weekly, as an offset to the larger challenge youâre facing. To further illustrate this concept, letâs look at two additional, real-world examples.
Example 1:
Imagine that, as a finance manager, youâre responsible for collecting $38,000,000 in uncollected invoices, with only a team of five ICâs available to help you.
Nearly any manager would be overwhelmed by the prospect of such an enormous task. And many might lose their way even before completing a high-level strategic approach.
However, an elite WSPro manager, will generate important insights by breaking down the problem into its core components - in this case, determining why just a single invoice hadnât been paid.
By analyzing a sample of unpaid invoices, the manager can categorize major reasons for non-payment, and identify potential solutions for each category.
The manager can then begin assigning meaningful tasks to their ICs. (*Hint: Youâll know youâve broken down the problem far enough when you can begin assigning simple tasks and deliverables to your team.)
Example 2:
Imagine youâre a QA manager, and you discover that 80% of your teamâs work can be automated. This is a profound insight - and a profoundly actionable one, too.
More technical managers may be tempted to design, code, and implement a solution which addresses all 80% at one time. However, this approach is rarely effective.
Setting aside the fact that, as a RemoteU participant, you are under a four-week time constraint, it would be highly ineffective, under any circumstances, to attempt to address the entire 80% at one time.
Rather, you should focus on a smaller automation that will improve a subset of results, and within one week. For example, an effective next step might be to automate the screen-taking portion of the work.
This would save up to 20% of the teamâs time, could be executed within a week, and would have an immediate, positive benefit.
Hint: One of the most common traps new managers fall into is to biting off more than they can chew. Focus on achieving a positive result within a single business area, rather than attempting to affect change in all areas, simultaneously.
#1: Getting outside the box (Chris)
Chris managed a test writing team during his RemoteU experience, and quickly realized the workflow they were using was far from optimal. His ICs were over-burdened with manual work, and the granularity and style of the tests were not consistent among his test writers.
In an effort to solve these problems, Chris identified an out of the box tool - an in-house POC named ACG - which would address both issues.
However, Chris faced two major obstacles to implementing ACG. First, to integrate such an external tool would take months to complete.
But even more challenging, development and support of the ACG tool had been abandoned, years before, by the team that originally developed it.
It would have been easy, at this point, for Chris to give up his idea for implementing ACG, but he didnât.
On the contrary, Chris reached out to the original ACG development team to see if they would be willing to pick the project back up. Unfortunately, however, this was not something they could do.
So, again, Chris had the opportunity - and a good excuse - to give up on his idea. Instead, he broke down the problem even further.
Chris hadnât coded in 15 years, but he dusted the cobwebs off his programming skills, and sat down to code. Chris downloaded the source code for ACG and installed it on his local machine.
To his dismay, he found that ACG wasnât working at all. Strike three, and another great excuse for giving up. But instead, Chris redoubled his efforts, and spent the next several hours attempting whatever he could to resurrect the program.
Methodically, he worked his way through bug after bug, resolving each as he encountered it, until ACG was nearly ready for primetime.
At this point, Chris was finally able to convince one of the original ACG developers who had initially refused to help, to join his efforts.
Together, they were able to roll out a beta version of the ACG tool by the end of week 3, and it met with successful VP approval! Powered by ACG, Chrisâs ICâs were able to reach the target set by the top performer.
The team more than doubled their productivity, compared to their baseline measurements. And the ACG tool is currently being beta tested by a larger user group within the test writing team.
#2: Making it happen, no matter what (Gabriel)
Letâs look at another example of a manager, Gabriel, who took an abstract problem and broke it down into a concrete one.
During RemoteU, Gabriel managed a manual test execution team, and in his second week, during a Gemba Walk, he realized his ICâs were waiting as long as 20-30 minutes while testing installations.
The ICâs were unable to move on to another task, because testing took all of their computersâ resources.
Initially, Gabriel explored a couple of local virtualization options, but they all provided sub-optimal results. He also tested the âDevfactory testing services,â and a locally installed hyper-V virtual machine.
While each provided benefits, neither provided the solution Grabriel was looking for. His problem was further exacerbated by the fact that, the use of virtualization among the test writing team was not a common practice.
Undeterred, Gabriel reached out to several ICâs within the company and began to discover managers using technology components which he believed would work for him, too. So, he began testing each component.
His first major challenge came when he wasnât able to get an AWS account to test workspaces. Instead of giving up, he registered a personal account, signing up for a trial period.
Using his AWS testing account, Gabriel quickly honed in on his solution. It was the VDI2 service spot instances which worked perfectly for his case.
By week 3, Gabriel had created multiple virtual machine images of VDI2, and instructed his team on how to use it. Instantly, his team realized a 20% increase in productivity during installation testing.
Productivity grew even higher as ICâs became familiar with the tool, and became comfortable performing multiple tests, in parallel.
No such thing as a good excuse
There are three common excuses we hear from managers for not executing on actionable insights, and which you should make every attempt to avoid.
Bad Excuse #1: âThe team room owner didnât approve it.â
In fact, most of the changes you will make in RemoteU wonât need approval. However, if a change does need approval, and the team room owner hasnât yet approved your action, consider that you are still responsible.
Likely, you havenât addressed the heart of the issue, or youâve failed to quantify the value of your proposal. Or, your plan may be too complicated.
If the TR owner rejects your proposal, find out why. Then refine your proposition in the appropriate area in order to get it approved.
Bad Excuse #2: âItâs not up to me. Iâm unable to affect positive change because Iâm waiting on someone else.â
An effective remoteU manager remains in control of the project, even in the face of uncontrollable circumstances.
If you perceive that you lack control, or that youâre stuck and canât progress, then redouble your focus. Youâre likely overlooking actions you can take, now, in spite of having to wait on others to execute their tasks.
In short, if itâs not up to you, then you have done a poor job identifying the right action.
Bad Excuse #3: âThe changes I want to make are too complicated to complete within four weeks.â
RemoteU is designed to produce an optimal result given the time constraints of the program. Simplify your approach to the project.
Craft solutions you can take action on today, and achieve your first milestone within a week.
Letâs take a look at two case studies involving RemoteU managers, Chris and Gabriel, who didnât succumb to their excuses (even though they had some good ones), but executed their solutions, in spite of setbacks, to make a real impact.
Conclusion
In this chapter, we covered the first of two common mistakes managers make - and which result in suboptimal performance (or failure) - during RemoteU.
We highlighted the three most common (bad) excuses managers make for not executing, and provided case studies which demonstrated winning behaviors.
In part 2, weâll address the 2nd most common mistake managers make: developing and using shallow insights.
Data Structure
Last updated