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