Distributed sucks. Human interaction is far better than virtual, all the more so for teams of any significant size. I have worked with successful distributed and local teams. The local teams were far superior in their ability to improve. I much prefer the lifestyle afforded by distributed teams. But that lifestyle comes at a significant cost that today’s tools cannot even begin to mitigate.
Editors note: Wide Teams is about more than just advocacy for dispersed teams. One of the reasons this site exists is to foster a robust conversation about all aspects of remote work – including the very real challenges involved. In order to get a critical perspective on distributed work, I asked my friend, former coworker, and fellow blogger Chris Strom to write this guest article. As someone who has managed both collocated and distributed teams, Chris is eminently qualified to comment on the issues involved. If you are a remote worker, I hope this post will spur you to think seriously and creatively about the difficulties Chris highlights. — Avdi
Let’s face it, conversations around distributed teams always involve attempts to digitally capture one or more facets of human interaction. A web site may be able to partially mimic whiteboard discussions. A single tool might allow you to read the body language and hear a couple of team members. But there is nothing that encourages ad-hoc whiteboard discussions with multiple team members producing highly visible, easily recorded artifacts. These real-life discussion are fertile ground for team growth.
When I inherited a team back at the beginning of 2007, we were a team of 20+ developers distributed across the US and Canada. There were questionable business reasons for the distribution, but reasons nonetheless. We were sadly dysfunctional.
Over the course of the next three years, there was an incredible amount of change in the business — much for the better, but likely more of it for the worse. The biggest change was that we closed remote offices and shrank to 4 local-only developers. During that period two things did remain constant: how we estimated the work and how much of that work got done.
Think about that.
We went from 20+ developers to 4 — four! — and the amount of work accomplished in a release stayed the same. Many of the developers that left were more talented than the ones that stayed. Many are well known and well respected (and rightly so) in the community. So how could the amount of work accomplished remain constant?
There are two reasons that I have identified allowing the few-left-behind to maintain output. First, the codebase got better. Like I said, we had extremely talented people working on the distributed team and they helped. A lot.
The other reason is that we were no longer distributed. We no longer had to lose context when the phones went wonky or Skype decided to die. We no longer had to take time out to manage off-site buildings. We no longer had to manage off-site personalities or perceived, digitally enhanced slights.
Conversations at the whiteboard were immediately absorbed by the entire team. Digital contention was replaced by analog learning. Artifacts of that learning were visible for all to build upon. Some of the departed were local and, while here, taught the few-left-behind. And the few-left-behind learned because “I think I understand” might be accepted digitally, but lack of comprehension is immediately obvious in-person.
This is not to say that I believe that distributed teams cannot work. I have worked distributed and distributed worked, to a point. The successful digital team was already strong but made little progress to improve — as a team or as individuals. Perhaps improvement was not as important. After all, we were already strong individuals and thus made for a formidable team. We did not need to improve, just execute.
Ultimately, strong individuals committed to self-improvement can make for a successful distributed team. But even they will benefit the more often they get together in-person. I still hope to work on distributed teams in the future, but only if they are small and focused on a well-defined project. Ideally, I will be able to continue working on small, local teams that I can help grow and can, in turn, encourage me to grow.
What do you think? Is is possible to find a large distributed team that institutionalizes growth of the team, the project and individuals?
About the Author: Chris Strom
Chris is a long time Perl programmer who made the switch to Ruby 4 years ago. His broad background includes a degree in astrophysics and extensive work in government, financial, educational and health care domains. Chris is the organizer of the B'more on Rails user group. He is passionate about learning and mentoring others. Chris owns and operates EEE Computes -- a software and software team consultancy. Related Posts
-
Episode #91: Robert Rouse of CrankApps
In this episode, Robert Rouse of CrankApps, talks about managing a remote team, hiring processes, and... -
Episode #87: Mike Hostetler of appendTo
In this episode, Mike Hostetler, Founder and CEO of appendTo, talks about establishing a successful and... -
Podcast #38: Vassilis Rizopoulos of Zühlke
Vassilis Rizopoulos, of Zühlke, talks about what it is like to handle equipment that can be remotely...
Subscribe in iTunes
The Distributed Workplace – how many companies force the exact same model on their employees. Often in the name of “urgency and need”.
I worked for a number of good companies that have allowed “distributed workplaces” to appear in their local work groups.
Often employees work separately, and are not there to aid each other nor take advantage of each others different styles. They can be in the same office space just one cubicle over. But essentially spend most of the week working independently except for the occasional meeting.
Meetings seem to fall into two categories: the first is the periodic scheduled (ie: weekly morning meeting) which is focused on reviewing what people are working on, and how much progress is being made, and to discuss problems and delays that have reached a critical mass (ie: enough that non-IT management requires an update).
The second is the impromptu meeting. Which often arises due to an issue of delay or problem. In these meetings discussion often revolves around the problem and what can be done to help. Sometimes a few suggestions are made, a recommendation to try this or that. And then a return to ones desk. The result, said solution and ideas do not work and the project is bogged down. The programmer becomes discouraged. Often being held back on completing a task by one aspect (procedure, methodology, bug in the API/language, or an almost unnoticeable typo).
Often the problem could have been resolved much more quickly without a 45-90 minute meeting. But a sit down with 1 or 2 other developers.
—
In my own experience. I was beset by a problem. The problem wound up wasting near a week of time. I was told to utilize a certain language component; but it was not behaving as expected. When I couldn’t get it to work. I was told that I just didn’t have a good enough grasp of the component life cycle, and if I just took the time to understand it better than I would get it to work.
Days later I still have not made any progress. Now I was a week late on my task. Battling with a language component unsuccessfully. What I didn’t know was my co-worker had the same problem, and had to use a different component and method, because there was a issue/bug on the framework level.
The same thing I concluded “Something must be wrong with this component and how it functions in this situation.” Meanwhile, I wasted days trying to over-come a low-level problem when we had an in-house solution already present. The result – one discouraged programmer, now days behind.
Now, let’s not take away the fact that one can argue that I could have found the alternative, and probably should of. But at the time I felt boxed in. Being told this is what I should use and that I needed to make it work. Put me off from exploring alternative paths.
Had we merely had more interaction as a team and on a developer level I think the results could be very different.
I’d love to try a paired programming some day. As I believe I am a bad single programmer. You see, my brain works a little differently. I’ll often find solutions from a different angle than the norm, but likewise find myself bogged down on some syntactically complexity. Where as I know other developers who often excel at getting the code to work. But are not as intuitive on interface or creative implementations.
I believe that the programming world suffers, because programmers like me do not excel in it. We’ve lumped many aspects onto the programmer’s plates. Some of those are complimentary while others are in opposition. We want the programmer to communicate with the computer on computer terms and then turn around and communicate to the average office work on human terms. We expect a programmer to be able to deal with a multitude of rote syntax and critical debugging while at the same time we want them to excel at creativity and thinking outside the box.
These are tasks that are in direction opposition. And yet pairing two types of developers can, I believe, create a very powerful and dynamic team. With one programmer who excels at the syntax level with another who is more creative and/or thinks differently. The result is a team who can build a better mouse trap when working together.
The problem is the corporate thought. We need to get this done yesterday. We have two developers, so clearly the fastest way to get this done is to have both developers work on parts of the project – because 1 + 1 = 2. The result is each developer must suffer the delay of their own weakness with no one there to bounce ideas off of, to point out simple typos, or brainstorm when hit with a roadblock. The alternative is to put two developers on one task. I’d liken it to 2^2 = 4. The two developers can cover each others weaknesses as well as fuel each others strength. But this does not compute to a traditional business philosophy. Two workers working on the identical task equates to inefficiency to the minds of management. And few developer teams are willing to take the risk and expend the people energy to see the potential benefit of team development.
I am on a distributed team. We have 3 main work locations. But there are other locations where developers are sometimes stationed.
Sure this is a disadvantage. It would be much easier if we were centrally located. But not all of our problems stem from co-location.
I’d say we might get anywhere from a 1.5 to 2 times productivity gain if we all moved to the same location. Cannot imagine getting the 5 times gain the author talks about here though.