LINEBURG


<< . .

 22
( 36)



. . >>

work days to maximize any overlap window for real-time dialogue, such as telecon-
ference meetings to resolve problems. They also learn to bunch-and-batch their work
to be delivered to the distant sites at the end of their day.
Many of these tactics also hint at a hidden bene¬t of time differences: interruptions
are reduced. There are less telephone calls, meetings, and instant message requests.
People can concentrate on “getting their work done.”

Synchronous tactics
The richer set of tactics are those that use overlap time (and hence synchronous). Most
familiar, teams tend to enlarge the overlap window by shifting and expanding work
hours. For example, European staff may start late and work late, so as to have greater
overlap with their American counterparts. Conversely, the Americans may start early,
either everyday, or at least on some weekdays, so as to expand the overlap time with
their European counterparts. Many of the new offshore companies are staffed with young,
ambitious software engineers that work long hours, often late into the night, creating
overlap windows with Europe and America.
In practice, when collaboration crosses many time zones, time window expansion is
practiced by only some of the distributed team, particularly the managers, team lead-
ers, and liaisons. Liaisons help team members interact across sites. For example, in one
case a large software team with members in Britain, Germany and India trained Indian
software engineers in Europe for several months to serve as liaison engineers.35 These
liaison engineers returned to India and then adjusted their work schedules to increase
their overlap window with their British and German counterparts.
One time zone “trick” is to know how to “break the e-mail chain.” The e-mail chain
begins when, in time-separated asynchronous communication, one engineer initiates a
message; the receiver, on the other side of the globe, does not understand it fully and
asks for clari¬cation; the original sender attempts to clarify; the receiver then interprets
it incorrectly and responds accordingly; the receiver then sends another clari¬cation.
Meanwhile, an entire week has gone by. Experienced engineers stop this chain early
“by picking up the phone” to clarify the message.

Awareness tactics
This last of the tactical categories is targeted at younger, less experienced team mem-
bers. They are not used to thinking about their counterparts being asleep while they are
working. They are not used to computing the direction of the time difference (“Is it 7
hours or 7 hours?”). They cannot recall when their counterparts shift to daylight savings
time (it is at different times in different nations). Small reminders and coaching help
163 Overcoming distance and time


address this problem. The distant individual reminds her counterpart that the scheduled
meeting is set for 06:00 local time. A simple tactic is to post hours and time differences
on the common team website.

The soft costs of time-zone differences
Many of the tactics described above are based on time-shifting. Time-shifting takes a toll
on individuals by rupturing the boundaries between work and home life. We all hear from
software engineers spending many evenings, nights, and early mornings, in telephone
conversations across the oceans. With the ubiquity of mobile telephones and other wire-
less gadgets, key individuals are always reachable “ any day, any time, anywhere.
Balanced teams try to rotate meeting times in order to shift the burden of late-night (or
early-morning) conference calls. But, all too frequently the dominant site (headquarters)
dictates meeting times convenient to their normal work day. One familiar result is the
team member who regularly falls asleep in the middle of teleconferencing meetings.
Since many of these tactics involve some personal inconvenience, not everyone plays
along. One collaboration between a British and California of¬ce (8 hours apart) was at
a major American technology ¬rm. During one project phase the team was working on
urgent software ¬xes. The British technical expert insisted on starting the day early,
while his California counterparts liked coming into the of¬ce late and working late.
Neither side made accommodations, resulting in no overlap window for synchronous
communication. All communication with the British expert relied on one e-mail batch
per day which “really slowed down the work.”


Other time differences
While less dramatic, other time differences impede collaboration. We describe them here.

Work hours
Daily work hours vary by country. Here is a sample of such norms. In India, formal work
hours for technology ¬rms are from 09:30“18:00, but “no one goes home at 18:00.” In
China, traditional work hours are from 08:00“18:00 with a two-hour lunch break. Huawei,
China™s most successful technology company, has kept the two-hour lunch tradition, but
most other technology ¬rms have moved to 09:00“18:00 with a one-hour lunch. In the
USA, the work hours are 09:00“17:30 with most lunches beginning at 12:00; in Spain,
workers begin late in the day, have longer and later lunch breaks, and ¬nish their work day
often much later than 19:00. Americans are more likely to plunge into work as soon as
they get to the of¬ce; the French (who also tend to begin the work day late) tend to spend
the ¬rst period of their of¬ce time drinking coffee and in small talk with co-workers.

Breaks
Breaks, such as lunch breaks, disrupt overlap windows. A European distributed soft-
ware team at Lucent found that even a one-hour time-zone difference between two
164 Managerial competency


sites substantially affected the team™s ability to communicate interactively because it
reduced their overlapping time by 4 hours: one hour at the beginning of the day, one
hour at the end of the day, and one hour during each site™s lunch break.36

Weekends
While much of the world has standardized on a two-day weekend on Saturday and
Sunday, this is not universal. In Hong Kong, the work week is Monday through Friday
plus a half day on Saturday. In Arab countries weekends revolve around Friday (their
Sabbath) with an additional day off either on Thursday or Saturday. In Israel, the week-
end is Friday and Saturday. For Americans working with Israeli partners, the Israeli
weekend creates a long “blackout period.” The Israelis have essentially left for the
weekend when the Americans come to work on Thursday morning. The reverse hap-
pens with the Israelis, who work for much of the ¬rst two days of the week without
being able to contact their American colleagues.

Holidays
The patchwork of national holidays is bewildering. One American technology ¬rm had
staff in more than a dozen European nations. The Human Resource (HR) director
reviewed the calendar for all these nations and came to the remarkable conclusion that
due to different, non-overlapping national holidays, there are only 50 regular works
days in common in any given year for the purpose of scheduling synchronized meet-
ings (e.g. the entire month of August is not usable in many European nations).


Collaborative technology

No reader of this chapter is unfamiliar with the menu of collaborative technologies
available for distributed collaboration that appears in Table 8.4. The right mix of these
technologies enables effective distributed software collaboration. Too often, though, dis-
tributed collaboration tends to rely too much on e-mail, and too little on other technologies.

Table 8.4 Types of collaborative technology

Asynchronous technologies Synchronous technologies

E-mail Voice telephony/Internet telephony
Voice mail/video mail Audio-conferencing
Online discussion groups Video-conferencing (meeting room)
Calendaring Video-conferencing (desktop/web-based)
Collaborative authoring and commenting Web-audio hybrid meetings
Project Management IM (Instant Messaging)
Production tools and repositories such as Whiteboard/Screen Sharing
con¬guration management systems, issue tracking
systems, work¬‚ow tools, knowledge management
165 Overcoming distance and time


Some people claim that the collaborative technology panacea is video-conferencing.
So, let us examine this assertion. It rests on the premise that “rich” multi-sensory, inter-
active communication is more effective. This is called the theory of media richness.37
The implication is that we tend to reach out and use “richer” media if we can. Accordingly,
the richest technologies are synchronous (real-time) technologies; and the richest of
these is video-conferencing. Video-conferencing is the closest we have, these days, to
face-to-face communication. Indeed, more and more software professionals are using
video-conferencing, at least on occasion, for meetings, or better yet, for more informal
discussions over distance.
As video-conferencing continues to improve, the goal is telemersion. In this form of
virtual reality, you will work surrounded by several cameras capturing your every move-
ment, while viewing 3D images and listening to audio in 3D through surround-sound.
At one end of your of¬ce area, near the espresso machine, will be a live-wall (or video-
wall) in which you will be able to walk up and spontaneously chat with your Indian
colleague, an ocean-away, who just walked over to her of¬ce™s juice bar. She intro-
duces herself: “Nice to meet you. My name is Sudha, and I joined the team here as a
quality assurance specialist this week. I look forward to working with you.”
But fantasies about video-conferencing tend to clash with some realities. Many soft-
ware professionals do not like working with real-time video for a host of reasons: they
are not sure about the correct etiquette of dealing with someone far away, they are afraid
that their interaction is being monitored, they are shy, they really do not see why it is
helpful when so much can be done using e-mail. And, of course, the interoperability
and usability issues of video-conferencing have not been solved.38
There is now better appreciation for the advantages and limitations of all of these
collaborative technologies of Table 8.4. Social scientists have been studying their impact
on work groups and developing a better understanding of the interplay of new features
with behavioral reactions.39 Tom Erickson, of IBM Watson Research Center, led a
group that created a persistent chat tool for distributed teams with the intent of foster-
ing greater community among software developers (“persistent” means that the text is
stored and does not scroll away). The tool was introduced to two distributed teams, one
in the US, and the other distributed globally. Each team used the tool differently. The
American project used the tool as it was intended, that is to generate a sense of com-
munity. On the other hand, the global project only used the tool in the hectic period just
before release. Erickson noted two adaptation differences. First, the time zone differ-
ences do not allow much real-time communication. Second, the global project had
almost no person-to-person history across sites, so it was socially more dif¬cult to use
real-time communication.
Companies can bene¬t from collaborative technologies by investing in a mix: instant
messaging, video-conferencing, high-quality audio-conferencing services, rich appli-
cation-sharing environments, group calendars, knowledge management systems,40 and
integrated repositories.
166 Managerial competency


On the softer side, this technology mix needs to be layered with support people: ded-
icated collaborative technology specialists who tinker and customize the tools, train the
users, and help teams to make the tools work. The Tier-1 IT providers have all invested
in creating their own collaboration suites; sewing together off-the-shelf technologies
with some home-grown features.
We have yet to reach the holy grail of collaborative technology: the all-in-one, seam-
lessly integrated suite of tools that are fully interoperable (and secure). The collabora-
tive technologies of the future will likely be composed of three integrated parts:41
shared workspaces, high-quality video-conferencing, and comprehensive event capture
repositories. The Intel case study, below, describes a collaboration vision for the com-
pany™s future.



Case study Intel™s vision for new collaboration technologies
Intel is one of the most globally dispersed high-tech ¬rms, with research and develop-
ment (R&D) facilities in 10 countries (Ireland, Israel, USA, Russia, India, Malaysia,
the Philippines, China, UK, and Spain), 11 fabrication plants, and 4 assembly plants
worldwide. In total, Intel has 236 of¬ces around the world.
The collaboration landscape is complex: manufacturing, design and software engi-
neering, as well as nearly every corporate activity, are all conducted with distributed
teams. Telecommuting is encouraged and quite common at Intel. At the same time,
some of Intel™s facilities, in a handful of countries, do not even have high-bandwidth
communications.
In spite, or perhaps because of its prominence, wealth, success, and history of dis-
persion, Intel still found problems with its collaboration environment. Indeed, the
very fact that the company depends upon remote teaming for daily productivity
raises the bar for collaboration tools.
An internal study42 conducted in 2003 showed just how “virtual” Intel had become:

On a weekly basis Intel was conducting 8300 web-based collaborations per


week and 19,000 audio bridges.43
51% of employees regularly worked with others who used different work


processes.
40% worked with people who used different collaboration tools.


71% of employees collaborated with people who speak other languages.


A long-ignored problem was uncovered and measured for the ¬rst time:


Multi-teaming. Almost two-thirds of Intel employees were members of more
than three teams!
Most intriguing was the ¬nding that distance, in and of itself, did not impact (per-
ceived) team performance, but that the confusing myriad of Intel™s collaboration
167 Overcoming distance and time



tools negatively impacted team performance. Employees were complaining about
too many tools that do not inter-operate well.
The Virtual Collaboration Research Team (VCRT) was formed in 2002 to
address these problems by creating a collaboration vision for Intel. At large compa-
nies such committees often create reports which can easily end up ignored on a
shelf. The VCRT set out to in¬‚uence management thinking by continuously com-
municating the vision upwards, and gaining support to link the vision to mainstream
plans, turning those ideas into practice step by step.
The VCRT was composed of individuals from various internal groups. These were
people who were passionate about collaboration. This is a “rambunctious team” as one
member described it, “full of energetic and creative thinkers.” VCRT had a nucleus of
experts who were involved in in¬‚uencing collaboration in their “real jobs.” For example,
one of the members was the Collaboration Architect within Intel™s corporate IT Group.

The vision
After extensive deliberations, and drawing on some prior work at Intel, VCRT™s ambi-
tious vision coalesced. Speci¬cally, VCRT decided that collaboration must focus on
two thrusts: multi-teaming and work across time differences. First, support for multi-
teaming means that all of the employee™s projects and tasks must be on the same desk-
top. Cross-project activities need to be arranged into composite views. Second, in order
to address the “time warp” problem, of multiple time zones, Intel employees would be
able to join “the meeting” asynchronously, whenever they wished. The vision also
included a “desired user experience” as its organizing principle: interoperability of
applications for seamless, one-click navigation and transactions. Finally, given that
most global team members at Intel never meet face-to-face, the vision includes some
kind of socializing interface to allow expressivity in a multi-cultural environment.
The components of this vision were then formulated into a layered architecture.
At the top layer is the individual workspace of each Intel employee. In the layer
below that is the core architecture made up of four tool clusters:
1 Co-authoring, including document and web content, software coding, and inline
annotations.
2 Project Management, including task tracking, issue tracking, and resource
management.
3 Team Management, including team building, discussions, and team member data.
4 Meeting Management, including calendaring, meeting structures and work¬‚ow,
and conferencing.
The last cluster of functionality became the most radical in its social engineering
goals and the most controversial within the VCRT: to get Intel employees to change
behaviors by expanding the notion of the meeting. In essence VCRT were rede¬ning
the de¬nition of a meeting. In this vision employees would do more tasks before the
168 Managerial competency



meeting and after the meeting, or even instead of a real-time meeting. Each Intel
team will drive more and more structured activities into pre- and post-real-time
meeting sessions through an asynchronous meeting participation mode that spans
each team member™s range of available working hours. Activities will be completed
anywhere within the time window that the (rede¬ned) “meeting” takes place.
Individual team members will be assigned activities with pre-conditions and dead-
lines. An intelligent work¬‚ow scheduler will suggest possible open timeslots that will
allow individuals to drag and drop the activities onto convenient timeslots in their cal-
endar. Many collaboration activities lend themselves to such asynchronous meetings:
preparing assigned sections of content for documents; document review and annota-
tion; as well as gathering and summarizing information that the team needs to take into
consideration.
Team members will see everyone™s progress towards completion of the asynchro-
nous activities through a status monitoring view. Personalized reminders will go out
automatically relative to each individual™s time zone and calendar prior to each
employee™s own settings for the task start time.
While VCRT™s focused on transforming the notion of the “meeting” into asynchro-
nous activities, it did not preclude real time interaction. For example, if two team
members will happen to notice that they are both online in the asynchronous team
workspace they will be able to easily switch to an ad hoc, real-time meeting for a
quick real time dialog. The more traditional real-time meetings will be scheduled for
a speci¬c timeslot and will be supported by structured tools. But even though these
real-time meetings will be structured, participants will be able to switch on any
ad hoc elements they wish during the session, such as deciding to invoke data sharing
with a single click that joins everyone together immediately.

In¬‚uencing the many stakeholders
VCRT members understood the dif¬culty of communicating a new collaboration
vision into mere words on a page. After all, everything sounded to others like some
existing collaboration environment. Rather than create text to capture the vision, they
created an illustrative four-minute demo video, using multimedia and a professional
announcer.
The demo video showed the Intel employee of the future utilizing a 3D inte-
grated, multi-perspective desk-top and collaboration environment. The audience
sees the employee™s screen with workspace, colleagues, timeline, work products,
and meeting lists. A project that requires immediate response is blinking. To address
the need to support the Intel reality of multi-teaming, the demo shows how the
employee can see all his responsibilities for all his teams on one timeline. He can
drag and drop any of them into convenient timeslots.
The inspiring animated demo and the compelling virtual survey data became
tools for changing the corporate vision. It was a vision that resonated with Intel
169 Overcoming distance and time




executives, particularly those whose divisions suffered most from time zone differ-
ences. These executives became most excited about the collaboration vision. The
VCRT challenge was to create momentum for change from managers who had
many other objectives. In fact, it was only after VCRT™s vision gained acceptance
outside of their home base in the IT Group that their cause was taken seriously.
From the beginning VCRT saw their mission to in¬‚uence four audiences rather
than just one. Of course, the ¬rst was to in¬‚uence collaborative work inside Intel
including all business units and functions. The second was to in¬‚uence the software
marketplace to support their vision. In particular, leading software product ¬rms in
of¬ce products and collaboration tools were key targets. The impressive demo
became a visual means to convey the vision to these critical ¬rms. Multi-teaming
was not supported adequately by any product on the market. Instead, all current
tools assumed a fairly traditional organizational view of one hierarchy, one project
per person, with no matrixing. VCRT emphasized that this needs attention.
Third, VCRT wanted to in¬‚uence the marketplace for Intel™s own high-speed
chips as well as chip design. By understanding the needs of high-end collaboration
Intel chip architects could facilitate the needs of the future generations of collabo-
ration platforms. These platforms will include support for rich media and parallel
processing in order to be responsive to the social and multi-tasking requirements of
collaboration tools. Finally, VCRT wanted to in¬‚uence Intel™s strategy in invest-
ments and alliances by directing the company towards ¬rms with promising collab-
oration solutions.
By 2004, VCRT could boast of a few successes. The latest Intel long-range plan-
ning document included the VCRT vision as part of the planning process. VCRT™s
170 Managerial competency



vision was now embedded in management™s conversation and, as is the barometer
these days, into management™s slide shows. It was also visible within an internal Intel
program called eWorkforce which supports knowledge work throughout the organiza-
tion. VCRT applied for a US patent on their collaboration concept. The Virtuality
Study became an annual tracking tool that may also be turned into a corporate
benchmarking tool. Outside industry analysts featured VCRT™s vision in industry
gatherings. These analysts pointed to Intel as a global corporation that rigorously
identi¬ed its needs as a globally distributed company and as one that, therefore, will
be a trendsetter in collaboration solutions.




Selecting the right people for distributed collaboration

Those who know how to create social capital face-to-face are often those who
know how to create social capital online.44
Beyond technical and managerial skills, selecting individuals for distributed software
development should also be based on their ability to work over distance.
There is now a set of best practices in choosing desirable skills and talents for dis-
tributed collaboration.45 First, the individual needs to possess good communication
skills, such that she can not only send a message which is understood but can solicit
feedback across distance. Some empathy is needed to head off the quick spiral of anger-
mail and bitterness that may emerge via e-mail exchanges. A history of using a mix of
multiple technologies (e.g. teleconferencing, video-conferencing, work¬‚ow systems, team
repositories) is essential. Since there is more isolation in distributed work, individuals need
to be capable of self-management.46 Because of cultural differences, heightened cultural
awareness is needed. For example, an Asian team member remained silent when he dis-
agreed. Will your Western manager be aware that this was done in order to save face? Will
he know to interpret this silence and to politely prod further for points of disagreement?
Leaders are especially handicapped when they become virtual leaders because their
success was achieved through face-to-face contact. In order to compensate, many virtual
leaders practice Management By Flying Around (MBFA). Thus, one necessary condi-
tion for a virtual leader is tolerance for frequent ¬‚ying.47 MBFA is essential for most
offshore projects.
Conversely, too many virtual managers resort to management by e-mailing around
(MBEA), or managing by (ever more detailed) contract, or managing by milestone.
These approaches may work for straightforward projects with experienced staff, but
fail in other instances. Asking a remote team to get a task done by a certain deadline is
not nearly as effective as ¬‚ying there to make sure that they get it done on time.
171 Overcoming distance and time


Undoubtedly, the virtual leader cannot rely solely on MBFA because of time and
expense. Using a mix of technology channels he must communicate his messages:
inspire his engineers; convey and then reiterate the project vision; become the team
“glue” by reminding people who is doing what, and who needs something, and
when. Successful leaders also coach their subordinates. In sum, virtual leadership is
an even more demanding position than leadership in the traditional co-located work
environment.
From the HR management perspective, the ability to work over distance needs to

<< . .

 22
( 36)



. . >>

Copyright Design by: Sunlight webdesign