Welcome

What works and what doesn't work in software development? For the first 10 years or so of my career, we followed a strict waterfall development model. Then in 2008 we started switching to an agile development model. In 2011 we added DevOps principles and practices. Our product team has also become increasingly global. This blog is about our successes and failures, and what we've learned along the way.



The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. The comments may not represent my opinions, and certainly do not represent IBM in any way.

Wednesday, August 21, 2013

How to make life easier for your remote employees

I've already written one post about setting up teams with remote workers.  However, I didn't really focus on cultural changes that employees who are in the regular office can accept to make life easier and more efficient for their remote colleagues.  Cultural changes are always difficult, but these are worth the effort if you want your entire team to be productive:


  • Be available for communication.  People are going to have questions, and if they're remote, they can't walk down the hall to ask them.  Be available via chat, instant message, text message, and phone.  Check your email.  Respond to messages from remote employees at least as quickly as messages from locals, and remember that remote employees can't just stop by if it's urgent.  It's great to set aside a couple of hours each day when you won't be interrupted, but make sure there are plenty of hours when your remote workers can reach you.  Set up your "do not disturb" time so it's either a time when your remote employees are not working, or when they are also on their "do not disturb" time.
  • Be available in off hours, especially when working across time zones.  Most remote employees will be very respectful of your working hours, and will only call you in off hours if they're stuck, and then they'll keep it quick.  If they do not have the freedom to call or text message you in off hours, they will lose hours of productive time on a regular basis.  They will learn to stop asking questions, and either spend the time trying to figure it out themselves using the Internet, or implement something that may or may not be what you want, and ask for feedback on it the next day.  Worried that you'll end up working too much in off hours?  Cross that bridge if you come to it, and allow for flexible schedules.
  • Allow for flexible schedules.  If someone ends up working late one night, they should be able to leave early or come in late another day that week.  Also, consider whether people in different time zones should work a shifted schedule.  For example, I've worked with teams in India that worked from 12-8 PM every day, so they would be at work for at least a few hours when the U.S. employees were at work.  Now that I'm living in California, I'll work an hour very early in the morning to sync up with people in Europe and on the east coast of the U.S., then I'll take a couple of hours off to get the kids off to school, then I'll finish up my work day.  My "do not disturb" time is in the late afternoon, when my colleagues are not working.  I also try to schedule all of my personal appointments late in the day.  Sometimes I work from 10-11 PM to sync up with people in China.  Flexible schedules are great as long as people are available for communication when the rest of the team is working.
  • Be careful about setting meeting times.  Keep meetings short, small, and focused.  Set meetings during everyone's working hours, or take turns having meetings during your off hours and during others' off hours.  Consider whether it's better to schedule a meeting or pick up the phone.
  • Be careful about who you invite to meetings.  Again, keep your meetings small.  But if you're having meetings where your remote colleagues have something to add, then invite them and make sure you provide facilities for them to join in (such as a good conference calling phone system, plus screen sharing).  Retrospectives and planning meetings, meetings where you set team policies, and town hall meetings are good examples.
  • Avoid using the mute button during conference call discussions.  If it's a one-way presentation, then it's fine for everyone else to be on mute to block background noise.  But if it's a discussion, don't put people on mute while you have a side discussion.  It's disrespectful, and people know it's happening because the sound of the background noise changes.
  • Be very clear in your communication.  Write carefully, especially if it's an email message rather than real-time communication.  Also, be explicit about work that is required, and work that is optional.  Are you assigning a task, or are you tossing around ideas?  Do you need a lot of help with something, or do you want to be pointed in the right direction?  Is anything blocking you?  Are you getting pulled away from your main tasks to work on something else?
  • Be smart about communication modes.  Use email when you have to carefully consider what you write, or to report on your status and hand off work at the end of the day.  Email and mailing lists are terrible ways to have involved discussions.  Use the phone (either an impromptu call or a meeting) when you have much to discuss.  Use instant messages or texts for quick questions.  If your instant messages or email messages are getting long, it's time to switch to the phone.  Use mailing lists for broadcast messages that need to go to a group of people, but if it turns into a discussion, move the discussion to a forum or wiki, send the link to the mailing list, and politely move the discussion off of the mailing list and into the forum/wiki.  If discussing a work item (defect, feature, etc.), discuss it via comments on the work item, for future reference.  Get all of your tips, setup information, and troubleshooting information into a forum or wiki, or write documentation that stays with the work item.
  • Have blameless retrospectives.  Every week or two, get together as a team to discuss what is working and what is not working, in an honest, blame-free environment.
Anyone have more ideas to add?  As always, I welcome your comments!