A few weeks ago, I wrote about the Distributed Teams Presentation and offered two items for followup. I’ll address the first here.
First, what does someone hiring a member of a distributed team look for when interviewing? How would one know indicators of success, or potential for success in that role?
To address this, we discussed the need to identify people who have a some traits which will give them a higher chance of success in a distributed team:
- Prior experience with distributed teams
- History of accomplishment in delivering on project work
- Self-motivated attitude and approach to work
- Exceptionally strong written and oral communication skills
When performing the interview, determining if the candidate can at least perform in the distributed team will probably come down to their past experience – have they worked in teams where they were acting autonomously, delivering on individual tasks and requirements, or were they a dependent contributor to a larger team?
The candidate’s background will be telling – if they’ve been working independently, or at least with some self-direction in a larger team, they likely have the basic experiences necessary to either be the distributed resource (remote, etc.) or part of the supporting team for a distributed resource (they are working with someone who is remote). Both parts of the equation are important, as a distributed team won’t work unless all parties support each other.
If the candidate was only a dependent contributor to a larger team, they may not have the basic skill set to allow them to integrate into a distributed team well – not knowing how to operate independently nor knowing how to support others in the team.
Worse yet is if the candidate has little to no work experience – a recent college graduate, for instance. If hiring for a remote worker, keep in mind that there will be no ability to mentor the individual – essential for the young employee.
As important as the past work experience is the level of communication skill the candidate has. Being able to speak and write effectively is important for any team member; it is doubly important for all members of a distributed team. Look for a strong speaker who can both support a position and accept the position of others. Communication skills will be tested regularly because of the barriers the team faces. I’ve written about this before a bit here.
If I were interviewing a candidate for a distributed team role, I’d focus on the above two facets in my interview, as they represent the core necessities for every member of the team – experience and communication.
One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.
There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.
When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.
Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.
Read the whole thing – really, really good.
The presentation on Friday, Distributed Teams and the Modern Company, was a great success. Jack Harvey of litl.com and I had a good set of items to cover, along with some humor and philosophical tangents; add in the great questions and post-presentation followup and I think we succeeded in giving people a good idea of how to succeed with a distributed team.
A couple of questions were interesting, and deserve some more consideration.
First, what does someone hiring a member of a distributed team look for when interviewing? How would one know indicator of success, or potential for success in that role?
Second, what kind of tools are available to tie team and project status together into a single overview that can be used to track and manage disparate and distributed team members?
More about each of these in upcoming posts.
The presentation is available as a PDF:
Will Bullock, of SLANT in Charleston, asked the following:
Hi Brian – we have been doing quite a bit of virtual collaboration ourselves lately (international client, west coast dev team). Certainly technology makes this much easier, but one thing I feel is often missing from the emails, wiki posts, and even conference calls is that emotive element: reading the client’s face, even through an iChat camera, is a poor substitute for true face time. I feel like this disconnect sometimes leads to misinformation.
Have you experienced this, and if so what do you/your distributed teams do to overcome it?
This was asked in reference to the talk Jack Harvey of litl.com and I are doing on Friday at the Charleston Digital Corridor about Distributed Teams and the Modern Company. I asked Will if I could post his question and my response, and he kindly agreed. Minor edits were made to fit this post’s context.
Great question, and a great point to raise during the talk so that others know you’re facing this issue.
I’ve written about this a bit on my blog:
But I’m still not sure I have the right answer.
Yes – I have experienced it, often with very negative results. The inability to use vocal and physical cues in the conversation makes it far less “rich” than if you were in proximity. Where a simple eyebrow raise, or a smile, or a lean forward in the seat can make all the difference in conveying thought and emotion, it is *totally* lost in the distributed situation.
I’ve been in a few situations where persuasive arguing was impacted quite a bit, where heated discussions probably ended prematurely or at least unresolved (emotionally) and where it was simply just hard to communicate. All are situations that could still be present when the team is together, but when apart – very hard to deal with.
Dealing with it, at least in my experience with my coworkers, takes real, foundational understanding that:
- the remote resources (in either direction – at “home” or “away”) are equal team members.
- everyone needs to work to ensure that the communication is clear (especially on the side where more of the team sits – they don’t get a pass because they’re “all in the office”).
- there needs to be a *much* higher degree of preparedness all around – send out drawings before meeting, emails detailing positions being taken, etc. It is very easy to lose that data in a distributed meeting than in a local meeting because of the probability of communication issues.
- you need to have some strong connection to your team members to make the relationship work.
I’m going to be talking about the last item on Friday as it relates to trust. For a preview:
I’ve found that having some connection stronger than simply coworker or entity/contractor/remote or similar results in a *much* better result.
A common case for a distributed team is that much of the team only knows each other via email, IM and phone calls. While this works, it isn’t optimal. The team needs to gel together (as any other team does) for success. The *only* way to accomplish that is by establishing trust between the members. Where can that come from?
- prior relationships with each other
- interconnected, shared relationships (mutual former coworkers, friends, etc.)
- prior successes with each other
Trust, of course, is best built by forging good relationships between the members of the team, and often the only good way to do that (and maybe the most economical in the long term) is to put them together. While it might be expensive initially to hold an on-site meeting, the ability to grow trust and relationships within the team in a short amount of time is simply so strong. Even sending a group to a conference together builds the connections they would otherwise be missing. Speaking from experience, the times when my company has held on-site meetings, in conjunction with some team-building activities and great meals together, we’ve made huge strides in establishing trust that envelopes our distributed project teams.
A recently released study of just under 25,000 IBM employees across 75 countries measured, among other things, the “tipping point” at which workers felt their work hours interfered with their home life. The results may surprise you:
For office-based workers the tipping point at which staff felt that their working life started to interfere with their home life came after 38 hours of work a week.
However, for those offered a flexible working, including from home, the length of time that employees could [work] without feeling the pressure was much longer.
On average they could put in 57 hours a week without feeling such a conflict.
No, really? When will society realize that for a large number of workers, there is no need to be sitting at desk doing something that can be done more efficiently, for less money and with better health for employee, employer, environment and society?
Also, this reminds me of The Trouble Tree. Don’t let work interfere with living.
I received a great call yesterday regarding an opportunity to speak about remote and distributed teams.
I’ve been asked by Ernest Andrade at the Charleston Digital Corridor to speak at June’s Fridays @ The Corridor about the topic. I’ll be joining with another person who is also part of a distributed organization.
Mark your calendar if you’re in Charleston on Friday, June 18th.
My hope is to give people real insight into not only ways to make a distributed team work but also the simple fact that it can work.
Ernest asked me to frame the topic:
Distributed teams and the modern company: is this the new way of getting a business off the ground? It this the new way to grow an organization when the local talent pool is isn’t sufficient? If not nearby, you can get what you need (talent, skill, experience, etc.) elsewhere and still reach success.
I’d like to talk approaches for success: trust, communication, connectedness, enabling technologies. The trust factor is an interesting one; I’ve written about it recently (Trust and the Distributed Team, More on Trust); I don’t think it is something people without experience in distributed teams are familiar with as a critical point for making it all work.
More as I figure out how to best present; if you have any ideas please comment.
I really how no idea how many visits this site gets, either directly or via RSS. My host’s control panel gives some information, but it is a bit hard to digest.
I’ve started using Google Analytics for some other sites I’m managing and find it quite a bit better to deal with (especially with the awesome Analytics app for iPhone!). I’ve just enabled it for wahlog.com, so I’ll know better what the heck people are doing here!
I was thinking this morning of how geographically distributed my coworkers and I are right now:
Charleston, SC; Ann Arbor, MI; Poulsobo, WA; Marietta, GA, Los Gatos, CA.
In the past, add to that list:
San Diego, CA; Firestone, Colorado; Eaton Rapids, MI, Branford, CT; Mexico; England.
For projects in conjunction with other companies, add people and teams in:
Mountain View, CA and Redmond, WA (among others).
The amazing thing, which is a testament to the people I work with and for, is that it works day in and day out. Not to say that there have been issues (I’ve mentioned them in the past) but we get it done quite well.