Site Navigation

Disclaimer

The views or opinions expressed on this blog are my own and do not necessarily reflect the views or opinions of my current employer. The views or opinions expressed by visitors on this blog are theirs solely and may not reflect mine.

However, Toni draws a profusely positive picture here, or, as my dear colleague Dean pointed out "The blog overly simplifies the realities of a distributed workforce, making it sound like it's all ponies and rainbows".

I left a comment on his blog with my some of my thoughts about this and also forwarded his article to our MySQL-internal discussion mailing list. This resulted in an interesting conversation between my distributed colleagues about their experiences with working from home, mentioning several additional aspects that are worth considering. I'll blend them together with some more thoughts from my side that have been bouncing around in my head after I posted that comment.

1. Your employees will love it. [...] You get the best of working remotely – flexible hours, no commute, a personal work environment, much more time with friends and family – without the typical downsides – guilt about being away from the office, or missing out on hallway discussions. In addition, your employees get to live where they want, not where the job market dictates. [...]

My colleague Gary had an interesting comment on that: "Aside from the horrors of timezones and the occasional person who wants to work from home because it makes it easier to hide, I'd say the major disadvantage of distributed: You miss all the subtle "primate stuff" that humans use to signal affection, approval, camaraderie, and submission. The major advantage of distributed: It's easier to ignore all the not-so-subtle "primate stuff" that humans use to signal aggression, contempt, shunning and dominance."

I personally feel that in this particular case the advantages outweigh the disadvantages, but more on that below.

Later, Gary elaborated on his "horrors of timezones" thoughts in an email to me: "With rare exceptions, time zones play havoc with planning, productivity and team cohesion: they expand the latency between communication and hand-offs; they put pressure on health and personal life because someone (or everyone!) routinely is or feels pressured to work too early, too late or both; and they make it hard to have productive, cohesive phone meetings: one group is just waking up and trying to identify what progress was made on some hot issue while they were sleeping and, on the same call, their colleagues further east can't wait for the meeting to end so they can eat dinner, go to sleep, or go see their kids perform in a school play. As if those challenges weren't enough, some people really do use time zones and working from home as a way to avoid colleagues or communications they don't want to deal with."

So time zone differences can be both a curse and a very welcome asset at the same time. This is especially true if your business has a support organization that is supposed to provide 24x7 coverage on a global scale. By having support engineers distributed across difference time zones, it's much easier to provide this kind of service. But when people within the same group are spread apart too much, it can be quite challenging to come up with a workable meeting schedule. Someone always will have to suffer and you should ensure that this burden does not always fall into the laps of the same people.

Dean raised a number of problems that are part of this package: "Rarely see each other (absence makes the heart grow fonder?), rarely get to go have a beer (or whatever) together, "cabin fever", enormously complicated to conduct "meetings" across global timezones, actually can be difficult to find employees who thrive in such an environment, almost impossible to find management who understand it, some people actually hate it, many people have trouble "closing the laptop", and it's exceptionally easy to damage your health with a constantly sedentary lifestyle if you don't actively manage it."

I agree, these are very important aspects to consider. In the end they boil down to "you have to be made for this kind of working environment – it's definitely not everyone's cup of tea". In fact, we had several colleagues that left us shortly after joining, after they realized that they were missing the personal interaction with their fellow team members. There is a difference between skipping the daily commute on one or two days a week and working in isolation for a long period of time. It's quite easy to let yourself fall into a "black hole". Fortunately we're all in the same boat, so we are aware that this can happen from time to time. The key point is to know about these pitfalls and not being shy about letting your team members know when you're having a bad time. It is usually followed a wave of huge productivity that makes up for the slower period before. Having a stable social background (e.g. a family or partner, animals or hobbies) also plays an important role here.

Andrew replied: "This is also why regular real life team meetings are essential for it to work. You get to know someone's personality far better so get a good feel for the real emotion going on when talking on mediums such as IRC. The problem is many companies do not see value in real life meetings because it may only give a minor increase in performance and can be costly. But it does give a great morale boost and I would not be surprised if it aids staff retention."

Philip, another colleague from the US chimed in by saying: "I agree. We actually really need and will find a way to do the "primate stuff" (really just "social stuff", as some of it is displayed equally well in insects and others particular to us (however you want to define 'us')). Periodic in-person meetings have really gone a long way in establishing the friendships I have here."

I have nothing to add – while it truly rocks being able to work from home, it really makes a big difference meeting your coworkers in real life from time to time.

2. You can hire great people wherever you find them

Dean commented on this: "Opening yourself to major language barrier issues, potentially unwieldy country-specific labor and tax laws, perhaps creating ill will where employees cannot experience "equality" in such areas as paid vacations or compensation, and of course you have to find open minded and tolerant people because insults are all too easy in a multi-cultural environment."

Indeed, there are a lot of gotchas involved here. From the things Dean noted above, I feel that language barrier issues are the most important ones to be aware of. In most distributed organizations, English is the "lingua franca". However, for a majority of employees it might not be their native language, which makes it easy to trigger misunderstandings. Especially us Germans are said to be "brutally honest" when expressing our thoughts. Sometimes it's just a lack of appropriate vocabulary that makes something sound overly negative or offensive. Also, there are differences in countries on how they observe and react to leadership and following orders. Being open-minded and aware of such cultural differences should be a key asset for people managing distributed teams. And in case of doubt, the best way to resolve such misunderstandings is by picking up the phone and having a friendly chat!

Also, you need a top-notch HR team that is knowledgable about things like the labour laws in different countries or how to handle tax implications when distributing money all across the globe to pay your employees. Depending on how many employees there are in a given country, it might make sense to set up a local legal entity, just to ease the handling of administrative issues (e.g. vacation, salary, etc.).

Also, the hiring process becomes slightly more complicated: how do you perfom interviews with potential candidates, if they live on the other side of the globe? How do you judge their personality and skills? In the Open Source world, this is actually somewhat easier, depending on what you are looking for. Developers usually have already displayed their coding skills by contributing code or patches as members of your community. If you're looking for support people, you might be able to judge one's communication and problem-solving skills by following their forum or mailing list posts. If they are capable of working in the distributed environment of an OSS community, they already have some of the required skills and capabilities. But this can not replace a personal conversation. It's clear that the hiring process is definitely different and you need to take extra care of making sure that the candidate is being kept in the loop and that progress is being made, e.g. if several members of your team are supposed to have a conversation with him to provide their input and impressions.

As an employee working for a distributed organization, you will likely be self-employed and work as a contractor. That usually means that you have fewer rights and much lower job security in comparison to being a regular employee. Since you're sending invoices instead of receiving a salary, there is more work involved in getting your paycheck. As an employer, you also need to make sure not to treat contractors as second-class employees. They should enjoy the same benefits (e.g. stock options, vacation days) as everyone else. At MySQL, you usually did not know (or care) if the person you're working with was a regular employee of some MySQL entity, or if he was a contractor.

3. You will use better communication tools

I concur with what Dean had to say about this: "Many non-distributed companies use these as well, although they seldom overuse them as badly as distributed companies can (1300+ emails a day, all needing some degree of attention or awareness on my part, is out of control). And all of that logging of course creates "interesting" legal complexities for your company."

Nowadays, most of these tools are utilized by "regular" companies, too. However, in a distributed organization you make use of these on a much different scale and you actually depend on them – they are the only direct link between your teams and colleagues. Do you want to use third-party infrastructure for that or would you rather like to set up your own communication systems? Also, you should ensure that even the less-technical people have easy access to these tools. Make sure they are properly trained and open to using these technologies.

Another important aspect to keep in mind here is platform-neutrality: don't rely on tools that only work on a particular operating system or that require the installation of proprietary applications. The same applies to document formats: you should always prefer open document formats like PDF or ODF when creating or exchanging documents. This makes it much easier for everyone to work with the content and does not make you dependent on a single vendor. Also, "keep it simple, stupid" should be your mantra – is it really required to email a text document or spreadsheet, if the same information could be conveyed by using plain text or by posting it on the intranet instead?

Also, having IRC logs and mailing list archives is nice, but they are no replacement for proper documentation like e.g. meeting summaries or project plans. New employees should not have to wade through raw discussion archives to obtain important information relevant for their work, it needs to be condensed and structured. A Wiki can be an excellent tool for that, but it must be properly maintained, structured and kept up to date! In general, your employees need to be much more aware of basic netiquette and communication rules and how to properly use the tools provided. Expect to spend much more time in communicating and documenting discussions and decisions than you would in a regular organization. The positive side of this: once everything has been discussed and written down, everybody should be playing on the same sheet of music.

4. You can still be social

Dean countered that one by stating: "Many non-distributed companies have offsites, social events, etc.". That is true. However, these social gatherings play a much more important role when you're distributed. Back when I joined MySQL, I was invited to attend a all-staff meeting in St. Petersburg (Russia) in my first week, to meet all of the ~40 employees that worked for the company back then. The personal contacts I established there really helped me a lot to find my way around and get started and they are still valuable nowadays. I have very fond memories from all the staff meetings that I have attended since then – they were essential to build up the bonds and work relationships that allowed us to be more effective when going back home again.

One thing that we realized at some point is that it's very expensive to assemble all people at one location at the same time, which actually resulted in us not having a full staff meeting for several years (except for smaller team meetings).

There are many aspects to keep in mind when arraging such meetings in a distributed organization:

Visa issues. For employees coming from the eastern countries (e.g. Russia), there are some hurdles they have to take before they can travel to certain countries. You have to prepare invitation letters and work with embassies.

Ensuring business continuity: If your company provides 24x7 support, you will have to ensure that this service does not get disrupted because of your ongoing staff meeting. So either some colleagues have to stay at come to provide the required coverage, or you have to set up a functional "support center" on site that can handle incoming requests. This requires a certain level of connectivity and bandwith – most hotels don't fulfill these requirements by default.

Finding a reasonably cheap and easy to reach location can be a challenge, depending on the season. On the one hand you don't want your employees to spend too much time travelling there. On the other hand, venues located around the major air hubs are usually much more expensive then going out to the countryside somewhere.

Also, you should consider to distribute the burden of travelling evenly among employees. Europeans don't always want to travel to the US, just because it's convenient for you and your HQ happens to be located there

5. Your offices will be more fun

As Toni wrote: at some point it becomes unavoidable to set up a "regular" physical presence somewhere. In the case of MySQL, we decided to establish a head office in Cupertino, close to Silicon Valley, where a large number of customers are located. Especially when you're concentrating your decision-making people in one place, don't forget about the employees who are not present and don't have the opportunity to participate in the hallway discussions and meetings that take place there. Ensure to maintain and improve your documentation and communication practices – avoid building an ivory tower that loses contact with the employee base.

I'd like to close this blog post with another nice quote from Gary: "I can't exactly recommend a fully distributed team. Having a distributed organization is like monogamy or democracy: they are fatally flawed in concept and practice but, uh, what are the alternatives again?"

Re: unexpected multi-cultural challenges, it's not just language barriers that pose a challenge. I remember how surprised the management team was when a monthly news email singled out a few people for special appreciation and then invited nominations for the next month. The rules were completely flexible, and the process was flat--anyone could nominate anyone else (except yourself). This was not a zero sum game: there could 1 or 1,000 people thanked--there was plenty of email "ink" to go around. Textbook "easy win" for company culture, right? Wrong. Some pockets of employees objected quite strongly. Eventually we were told that, in some cultures, there's a prohibition on (or at least an inhibition for) public praise of this sort. Why are some called out but not others? Why are people being praised simply for doing their job? So this simple idea of informally or even whimsically expressing public gratitude actually rubbed some people the wrong way. (Hint: they were not from California.) In this particular case, the manager, who is European, listened but ultimately disregarded the complaints and these public thank you messages still continue years later (and being mentioned is actually regarded as an honor by many no matter how long or short the list is).

Lenz, you thoroughly dissected Toni's post. You touched on virtually every concern I had.
Realistically, as a young company, I will try this employment and management model, again. I am not optimistic. I primarily employee Internet marketers, and they have a tendency to drift off course, as our job in marketing is less focused then coding or customer service and project management.
I have never employed anyone out of the US, but the US people I have employeed have done 2 things, which are unacceptable.
1. Goof off. They are simply not available when we call. God knows where they are, or what they are doing.
2. They freelance. Operating off of company servers, we see when they have something that is not Arcade in development, and they have it on our server. When we are behind on a project, and you discover someone is looking for another job, it is frustrating.
When you decide to be distributed, I think you need to vet the potential employee as much as possible, and give yourself a way out, without disrupting the project or the client.
As a bootstrap start up, it isn't easy. It is still fun.
Great post. Thanks,
John

Hi John, thanks for your comments. Sorry to hear that you had bad experiences with this model in the past. Agreed, it may not work for everyone and there are cases in which it makes more sense than in others. One thing that is truly essential for this to work: you need to have a lot of trust in your employees and they have to be passionate about what they do. This is probably easier for developers working on an Open Source project than it is for internet marketeers. If people love what they are working on and have a clear vision in front of them, they usually don't need close supervision or control. Actually, if you apply too much control and monitoring, it's more likely that people will feel observed and under pressure, which will eventually lead to poor performance or attrition.

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.Enter the string from the spam-prevention image above: