How to manage remote employees
Notes from the field: First, some links to comments by people who have actually done remote managing of workers:
10 Essential Tips for Managing Remote Employees
How To Manage Remote Workers Like They’re Right In The Office
How to Successfully Manage Remote Employees
How to Effectively Manage Remote Employees
8 expert tips for managing remote workers
Note that many of these contain the same tips - provide good hardware, regular (but not nagging) communication, very clear instructions, clear, objective acceptance criteria for work done. Web cams and Skype can help a lot.
Absolute essentials for remote management: These are: initial tooling and access, learning curves, written instructions, written acceptance criteria, time constraints. Although obvious, they are omitted or ignored often enough so that there are frequent failures in the use of remote workers, most famously Yahoo! under their final CEO. These failures, likely due to management rather than workers, gave remote work an undeserved bad reputation that persists today. All the essentials are necessary from the beginning.
Initial Tooling and Access: Make a list of everything a remote worker might need, including hardware, software, access to systems. Check it with current team members for completeness. Don't be cheap: for example, there is no excuse for providing a laptop that does not have a large, high-quality SSD as well as a conventional hard drive for backups. See to it that the delivery of any hardware and/or software is on time.
Understanding learning curves: One of the most important, and most misunderstood, aspects of employing anyone is the learning curve. All jobs have learning curves. Heuristically, a typical learning curve looks like this:
Somewhere in the steep progress part of the curve, it switches from concave up to concave down, and that is the measure used to discuss the curve. That point is (erroneously but commonly) called "the learning curve". It should actually be called the learning time. Note that real mastery comes at about twice this amount of time.1
Measurement of progress and competence in such a situation is tricky, especially in a remote worker. A good manager needs to find good workers, and should try hard to avoid throwing the baby out with the bathwater.2 The longer the learning time, the more valuable the employee, the harder to replace. Retention is critical for employees in long learning time roles.
There is a simple, objective solution to the measurement issue. The work load and difficulty given to the worker should look like the learning curve above. Start by giving them simple, very clear things to do, give them a chance to build up a track record of success, then ramp it up as mutual confidence and understanding grows. Eventually, a limit is reached for any particular individual. So long as that limit is in the ball-park, keep the employee and continue. If user stories are uniform enough, for example, a plot of user stories processed per week should look very much like the graph above.
Written Instructions and Acceptance Criteria: The other aspect to using remote employees cannot be emphasized enough: brief, clear, written instructions including a complete and objective list of acceptance criteria. This is both an art and a science, and it is possible to under-do as well as over-do. The Agile concept of user story is a good model to use as an initial example. It can be customized and modified in many different ways and adapted to specialized needs. This skill (writing clear, unambiguous, actionable and validate-able instructions) is so important, I'll go through it in a separate post in the near future.
Likewise, written acceptance criteria should be clear, unambiguous and objective. A knowledgeable third party should be able to read the acceptance criteria and come to the same understanding as both the manager and the worker. NB: a newbie cannot be expected to be familiar with data, especially legacy systems data (where the data is likely to have internal logic and structure that cannot be easily learned without long experience). Supplying enough quality data for testing is the responsibility of management until the worker knows the data. This is another frequent failure item. NB: There is a good reason first normal form for relational databases requires almost zero internal structure for data beyond place value.
Time constraints: Deadlines are standard operating procedure everywhere. Initial deadlines for a newbie should roughly follow the guidelines expressed above - difficulty should be scaled to a learning curve until the worker is up to speed. That can be measured at about the learning time for the job (examples: six months for a developer, about a year for a DBA). If the worker isn't improving rapidly by that time, then it is fair treatment and good practice to consider a replacement. Of course, this presumes the learning time was correctly estimated in the first place.3
Notes:
1The current job I do had a learning time of about a year. It wasn't a matter of personal competence, it was the sheer volume, size and complexity of the systems we build and maintain - many tens of TB of data, many, many applications, and very fast pace.
2Amazingly, this simple concept is widely misunderstood or ignored. For example, if a job has a learning time of six months (most developer jobs), taking a provisional candidate on a two-month contract-to-hire basis will almost certainly result in an (unfair) rejection of the candidate. The entire exercise is a failure from the start. Note to job-seekers considering contract-to-hire situations: anything less than six months is almost certainly a loser for you and should be politely declined.
3On this topic, several caveats are in order.
a. There is an industry-wide meme called "hit the ground running". For anyone who buys into this silly notion, try hopping off a moving vehicle (5 mph) backwards and running behind the vehicle. The hapless wanna-be stunt man who tries this will likely fall flat on his face, right into the pavement. It just doesn't work physically, and really doesn't work in the workplace either.
Experienced contractors routinely deal with this expectation in new jobs by (1) assuming the employer has a low threshold to terminate, (2) really, really pushing themselves, (3) quietly and skillfully querying their co-workers for bits and pieces of information needed to to their jobs, and (4) lots of trial-and-error experimentation. They can often produce the illusion of "hitting the ground running". They will have to chill after they have "proved themselves" in order to prevent burnout. NB: Doing this correctly is stressful. Nobody likes it, but it is a valid and necessary response to the "hit the ground running" narrative.
b. Learning times can vary a lot. In a very fast-paced, highly chaotic workplace, mere survival is about the most an average worker can manage. The stress eases slowly with time, but never goes away entirely. The learning time for such an environment is much longer, since each new worker is pulled from one topic to another, willy-nilly, and never has time or opportunity to practice. Expectations should be lower in such cases, since the alternative is high turnover.
c. Last, every single manager, from team leads to CEOs, involved in a business where time-to-market is the single most important criteria for success, should be intensely aware of this fact, and do absolutely everything in their power to minimize chaos.
Want people to work as fast as they can? Great! Use only experienced personnel (and pay for them), minimize meetings, minimize e-mail, use a single, good work-flow system, cut the tasks into small, rapidly workable bits (Agile! Continuous development!), always let them finish the last task before starting the next task, don't micromanage, provide regularly scheduled, fair feedback, and praise them for good work. Make money doing it, and spread a bit around as surprise success bonuses. It works!
10 Essential Tips for Managing Remote Employees
How To Manage Remote Workers Like They’re Right In The Office
How to Successfully Manage Remote Employees
How to Effectively Manage Remote Employees
8 expert tips for managing remote workers
Note that many of these contain the same tips - provide good hardware, regular (but not nagging) communication, very clear instructions, clear, objective acceptance criteria for work done. Web cams and Skype can help a lot.
Absolute essentials for remote management: These are: initial tooling and access, learning curves, written instructions, written acceptance criteria, time constraints. Although obvious, they are omitted or ignored often enough so that there are frequent failures in the use of remote workers, most famously Yahoo! under their final CEO. These failures, likely due to management rather than workers, gave remote work an undeserved bad reputation that persists today. All the essentials are necessary from the beginning.
Initial Tooling and Access: Make a list of everything a remote worker might need, including hardware, software, access to systems. Check it with current team members for completeness. Don't be cheap: for example, there is no excuse for providing a laptop that does not have a large, high-quality SSD as well as a conventional hard drive for backups. See to it that the delivery of any hardware and/or software is on time.
Understanding learning curves: One of the most important, and most misunderstood, aspects of employing anyone is the learning curve. All jobs have learning curves. Heuristically, a typical learning curve looks like this:
Somewhere in the steep progress part of the curve, it switches from concave up to concave down, and that is the measure used to discuss the curve. That point is (erroneously but commonly) called "the learning curve". It should actually be called the learning time. Note that real mastery comes at about twice this amount of time.1
Measurement of progress and competence in such a situation is tricky, especially in a remote worker. A good manager needs to find good workers, and should try hard to avoid throwing the baby out with the bathwater.2 The longer the learning time, the more valuable the employee, the harder to replace. Retention is critical for employees in long learning time roles.
There is a simple, objective solution to the measurement issue. The work load and difficulty given to the worker should look like the learning curve above. Start by giving them simple, very clear things to do, give them a chance to build up a track record of success, then ramp it up as mutual confidence and understanding grows. Eventually, a limit is reached for any particular individual. So long as that limit is in the ball-park, keep the employee and continue. If user stories are uniform enough, for example, a plot of user stories processed per week should look very much like the graph above.
Written Instructions and Acceptance Criteria: The other aspect to using remote employees cannot be emphasized enough: brief, clear, written instructions including a complete and objective list of acceptance criteria. This is both an art and a science, and it is possible to under-do as well as over-do. The Agile concept of user story is a good model to use as an initial example. It can be customized and modified in many different ways and adapted to specialized needs. This skill (writing clear, unambiguous, actionable and validate-able instructions) is so important, I'll go through it in a separate post in the near future.
Likewise, written acceptance criteria should be clear, unambiguous and objective. A knowledgeable third party should be able to read the acceptance criteria and come to the same understanding as both the manager and the worker. NB: a newbie cannot be expected to be familiar with data, especially legacy systems data (where the data is likely to have internal logic and structure that cannot be easily learned without long experience). Supplying enough quality data for testing is the responsibility of management until the worker knows the data. This is another frequent failure item. NB: There is a good reason first normal form for relational databases requires almost zero internal structure for data beyond place value.
Time constraints: Deadlines are standard operating procedure everywhere. Initial deadlines for a newbie should roughly follow the guidelines expressed above - difficulty should be scaled to a learning curve until the worker is up to speed. That can be measured at about the learning time for the job (examples: six months for a developer, about a year for a DBA). If the worker isn't improving rapidly by that time, then it is fair treatment and good practice to consider a replacement. Of course, this presumes the learning time was correctly estimated in the first place.3
Notes:
1The current job I do had a learning time of about a year. It wasn't a matter of personal competence, it was the sheer volume, size and complexity of the systems we build and maintain - many tens of TB of data, many, many applications, and very fast pace.
2Amazingly, this simple concept is widely misunderstood or ignored. For example, if a job has a learning time of six months (most developer jobs), taking a provisional candidate on a two-month contract-to-hire basis will almost certainly result in an (unfair) rejection of the candidate. The entire exercise is a failure from the start. Note to job-seekers considering contract-to-hire situations: anything less than six months is almost certainly a loser for you and should be politely declined.
3On this topic, several caveats are in order.
a. There is an industry-wide meme called "hit the ground running". For anyone who buys into this silly notion, try hopping off a moving vehicle (5 mph) backwards and running behind the vehicle. The hapless wanna-be stunt man who tries this will likely fall flat on his face, right into the pavement. It just doesn't work physically, and really doesn't work in the workplace either.
Experienced contractors routinely deal with this expectation in new jobs by (1) assuming the employer has a low threshold to terminate, (2) really, really pushing themselves, (3) quietly and skillfully querying their co-workers for bits and pieces of information needed to to their jobs, and (4) lots of trial-and-error experimentation. They can often produce the illusion of "hitting the ground running". They will have to chill after they have "proved themselves" in order to prevent burnout. NB: Doing this correctly is stressful. Nobody likes it, but it is a valid and necessary response to the "hit the ground running" narrative.
b. Learning times can vary a lot. In a very fast-paced, highly chaotic workplace, mere survival is about the most an average worker can manage. The stress eases slowly with time, but never goes away entirely. The learning time for such an environment is much longer, since each new worker is pulled from one topic to another, willy-nilly, and never has time or opportunity to practice. Expectations should be lower in such cases, since the alternative is high turnover.
c. Last, every single manager, from team leads to CEOs, involved in a business where time-to-market is the single most important criteria for success, should be intensely aware of this fact, and do absolutely everything in their power to minimize chaos.
Want people to work as fast as they can? Great! Use only experienced personnel (and pay for them), minimize meetings, minimize e-mail, use a single, good work-flow system, cut the tasks into small, rapidly workable bits (Agile! Continuous development!), always let them finish the last task before starting the next task, don't micromanage, provide regularly scheduled, fair feedback, and praise them for good work. Make money doing it, and spread a bit around as surprise success bonuses. It works!
Comments
Post a Comment