Trust me, you don’t want your remote team members to be busy.
Or, at least, you shouldn’t. You should want them to be productive. And busy and productive are two quite different things in most work environments.
If you’re like many organizations, this week is the first week that a good number of your team members are working from home (due to that damned virus).
And if you’re a business owner or senior executive it’s natural for you to worry that your remote team members won’t be productive.
When busy DOES equal productive
Now, there is one context where busy IS a synonym for productive.
Let’s assume that you send an employee home with boxes of envelopes to stuff. Maybe you want them to stuff those envelopes with invoices or promotional materials and deposit them at the post office at day’s end.
This person’s productivity will be (almost) directly proportional to how busy they are. After all, for every moment they sit idle, there are envelopes that aren’t being stuffed.
So, in this context, busy is good!
When busy DOES NOT equal productive
But what if your employee is a member of a team? What if, rather than stuffing envelopes in isolation, you expect them to collaborate with other team members to create something more significant than that which they might create working alone?
What if they are a writer, working with designers and editors to create a publication?
What if they are an application engineer, working with salespeople and production experts to propose solutions to clients’ problems?
Or, what if they are an analyst, working on a legal team to build a complex defense?
In all these cases, productivity is a measure of the output of a team, not the output of an individual. And, importantly, the output of the team is not simply the sum of individual outputs.
To understand why; consider the most simple of teams. A bucket-brigade. The purpose of a bucket-brigade is to move water, one bucket at a time, from one point to another. Obviously, productivity is a function of the rate at which buckets reach the end of the line. It is not a function of the rate at which individuals work.
In fact, we maximize the productivity of the line, long before we approach the maximum work rate of most of the folks manning the line.
In order to be productive, we do NOT want members of a team to be busy, we want them to be responsive.
You want your team members to be responsive, not busy
It’s easy to see that busyiness is antagonistic to responsiveness. The busier a person is, the less capable they are of being responsive.
This point is more important than it seems. The reason is that most work environments are significantly more complex than a bucket brigade.
If you consider your team members, it’s likely they are contributing to multiple brigades simultaneously. It’s as if multiple parties, each from a different brigade, are attempting to hand each team member buckets at the same time.
Given this observation, your reflex, as a manager, should really be to worry that your team members might be too busy, rather than not busy enough!
And there’s an irony here. If your team members are at work, it’s likely that there are more folks trying to pass them buckets than if they are at home. In a sense, you should be pleased to send your team members home. If you have a critical writer, application engineer or analyst on your team they will be a lot more responsive if the only non-critical demands on their time are watching TV, cleaning the pool or walking a dog.
So, how do you manage a remote team member?
The simple answer is, you don’t!
You don’t manage team members (individually), you manage teams.
Let me say that again. You don’t manage team members, you manage teams. The reason is that team members don’t create value in isolation. They create value ONLY in the context of the team.
So here’s a DON’T DO list for you:
- Don’t encourage your team members to be busy, encourage them to be responsive
- Don’t track time and don’t attempt to document all work
- Don’t have one-on-one meetings unless there’s a specific reason why this is required
- Don’t expect software to manage for you (Kanban boards are great, but context is more than a list of tasks — irrespective of how artfully those tasks are visualized)
Three simple requirements for a productive remote team
The three requirements for a productive remote team (or any team, for that matter) are:
- Supervision
- Choking the release of tasks
- Short, mandatory, daily video huddles
That’s all. Just those three things. You can use software to visualize tasks if you like but it’s not critical. But you need to be sure that whatever software you use isn’t interfering with any of those three requirements (particularly number two).
Supervision. There is NO SUBSTITUTE for good supervision. Certainly not software. In a team environment, only the supervisor is responsible for the output of the team and only the supervisor has the necessary context to make task prioritization decisions.
The good news is that most well-intentioned people with reasonable communication skills will do a pretty good job of supervision, so long as they understand the dynamics of the environment they are supervising and so long as they have NO DISTRACTIONS. (In other words, a person who does a mixture of work and supervision is not a supervisor.)
Choking the release of tasks. We’ve already discussed that, where teamwork is required, responsiveness equals productivity. The supervisor’s primary responsibility should be to preserve responsiveness by choking the release of tasks.
Ideally, each team member should be responsible for just one task at a time. Practically, it may be necessary to release more than one task at a time but any more than three or four will result in the system descending into chaos (bottlenecks everywhere).
In addition to choking the release of tasks, the supervisor should be responsible for task prioritization. In fact, other than choking task release and task prioritization there’s really only one other thing that your supervisor should be responsible for, and that’s number three.
Short, mandatory, daily video huddles. For years, short, tightly-choreographed, stand-up meetings have been a standard fixture in all manufacturing and software development environments.
They should be a standard fixture in EVERY team environment. Where remote workers are concerned, your huddle will be a video conference, rather than a stand-up meeting. And the significance of the video conference is that every participant will turn their camera on (in the interests of effective communication).
These huddles should be short. 15 minutes is ideal. Nor more than 20. And they should be mandatory (non-negotiable).
The frequency of these meetings should be proportional to the cadence of the environment (the rate at which units of value are generated). When in doubt, start with daily huddles.
The agenda for these meetings should never change. First, you review the health of the environment as a whole. What is the velocity of the overall system? If it is sub-optimal, what is the status of critical queues? Or are there blockers of some kind?
Then you should do a deep dive into a few tasks (only a few) associated with important projects (or cases). Perhaps the team members responsible for each of those tasks might present their progress to the team for feedback.
The meeting should conclude with a summary of whatever action items arose as a consequence of the discussion.
That’s it!
Focus a dedicated supervisor on systemwide flow, not individual productivity. Where individuals are concerned, preserve responsiveness by choking the release of tasks. And ensure that everyone gets in a Google Meeting (or Zoom Conference) once a day (with their cameras on!).
And if your application engineer wants to walk her dog: fantastic! (So long as she’s available to jump into a call at a moments notice).
