Technical Trust Part II: Remote Teams

In part I of the series “Technical Trust: What is it and why is it important?” we discussed technical trust and how you build it with a local team. In this article we’ll discuss the much more challenging task of building technical trust with a remote team.

The Elephant in the Room: Cost of Travel

After factoring in labor costs, a domestic trip can reach $2,000 and an international trip can exceed more than $8,000! As such, many companies are reluctant to allow rank-and-file scientists, engineers and technicians to travel between sites. Instead companies typically undertake a combination of two approaches:

  • Concentrated Activities
  • Redundant Organizations

Concentrated Activities

A typical reaction to the high cost of travel is to try to maximize bang-for-your-buck. “If we are spending $8,000 to fly an engineer to China, then we better make the trip count!” This leads to the engineer trying to cram as much as he can into his 1-2 week trip: working 12-15 hour days, lots of face-time with personnel to build rapport, touring facilities and surrounding sites. These activities help to build technical trust, but aren’t ideal because the interactions are forced and artificial.

Additionally, the interaction on a technical level are often between the wrong people. Budget constraints dictate that only one or two representatives from a team will travel to the site. Usually this is a manager or other employee who has breadth of knowledge but not the depth of knowledge of a design engineer. When it comes to specific technical knowledge, the manager’s broad knowledge comes up short.

Further, when someone does travel to the remote location they are often asked to check in on a few things. For example, an engineer on another project might say “while you are Singapore do you mind dropping by XYZ machine shop. They are supplying critical parts for our new sub-assembly and have had trouble meeting tolerances.”

Redundant Organizations

Another approach is to build separate organizations at each site with the burden of travel placed upon the high-level executives who must bridge both organizations. This well-intentioned approach can often result in:

  • Silo organizations that are distrustful and communicate poorly
  • Reactive problem solving: problems ignored until they become a crisis
  • “Throw it over the wall” approach to product life cycle and product development
  • Redundant infrastructure

These bad behaviors often lead to ongoing inter-organizational strife.

Necessary Evils

It’s important to note that the approaches described above are able to get the job done. It’s a constant struggle to achieve goals and deadlines when dealing with distributed technical teams. The approaches described above are used by managers because they’ve been proven to work. However, the approaches are painful and inefficient so leading edge managers and companies are constantly looking to technology to provide smarter solutions.

Smarter Solutions

At Collaborate i/o we are big fans of cutting-edge tools such as videoconferencing, desktop sharing and document sharing. It’s hard to imagine technical teams being able to work together between remote locations without the ability to have a quick chat via Skype or walk someone through a software tutorial using WebEx. These tools have done a great job of making engineers’ lives easier—which is Collaborate i/o’s mission.

As helpful as these tools are, they have been optimized for mainstream office workers and don’t fully meet the needs of technical work. In particular, they don’t provide a method to work together through technical problems from hundreds or thousands of miles away. This capability is exactly what Collaborate i/o brings to the table: seeing is believing. When you watch someone build an assembly or work with them to troubleshoot a problem, you are able to quickly build technical trust.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>