Working on a digital product or a campaign involves teams of various competencies that include design, software development, content, SEO, legal, and beyond. Those teams need to be involved at different stages of the project and in varying degrees. Despite the size of the company, it is burdensome to keep teams of every field and depth of expertise in-house.
In my 11 years of experience in software development, I've consulted monolithic companies who follow the in-house model, rendering them slow, inflexible, and with high burn rates. At some point, each one has switched to a distributed model or risked going out of business. This is why experienced managers choose to seek help outside of the company for skills that are not essential to their core business.
For the past decade, I've led distributed and remote teams that build digital products. In 7 lessons, my teammates and I will share our findings, optimal structure, and proven practices for achieving success with distributed teams.
It's true that working with a distributed team can be a pain. Why would you go through it anyway? Sometimes, it's because you don't have a choice — for instance, your creative office may be on the other side of the country. But there are a couple of reasons you might make this choice as a good business decision in a consulting or agency setting.
One reason is efficiency. Most companies don't need every skill full-time. When building digital products or campaigns, at different times you need the skills of different teams. If you can effectively rotate different teams between projects, you will significantly increase the efficiency of the business.
Another reason is more flexibility in bidding for contracts. if you are bidding for a program management contract, you might not have all the required skills in-house. Hiring an outside agency to do part of the work will allow you to meet the conditions of the contract.
While it may seem like a widespread practice, only certain methodologies ensure successful collaboration in distributed and remote teams. Back in 2003, Gartner reported that over half of projects involving distributed and remote teams ultimately fail. Moreover, a more recent study conducted by the Standish Group reports that only 29% of software projects across the industry succeed.
Modern resolution for all projects based on the CHAOS report
We still struggle to communicate, and fail to update each other on decisions and thought processes. By the time a problem becomes apparent it is often too late to fix it. Primary issues in distributed teams include communication discipline, improper documentation, and the water cooler effect.
On the surface, there should be no problem working with remote colleagues. The recipe for success seems simple: come up with relevant roles and carefully discuss the results.
This is why teams are often surprised when collaboration doesn't work out. At some point, certain executed decisions don't make sense to a team member, who then starts to wonder who made those decisions, and why. People on the remote team seem to act illogically, or ask questions that have nothing to do with the root of the issue. It can become a very frustrating experience.
Here is where the remote model presents challenges. You cannot merely approach the remote person's desk to discuss the problem; instead, you must send an email, with a bunch of people CC'd, and bring everyone up to speed before you can even ask the question. Communication becomes burdensome and time-consuming.
This is when the failure begins.
In his book Alibaba, The House That Jack Ma Built, Duncan Clark describes the Chinese behemoth Alibaba trying to set up an office in California and ultimately failing due to communication challenges. Both the 15-hour time difference and the enforced usage of English among the Chinese engineers undermined their efforts in coordinating with the Fremont office as well as among themselves. This led to two offices developing two different products, and the ensuing infrastructure upgrade sent the entire Alibaba.com website offline. Jack Ma was in California at that time and personally tried to improve team communication, but it still wasn't enough. Eventually, core development moved back to Hangzhou, and the Fremont development office shut down.
If that example of communication breakdown in distributed teams is not dramatic enough, revisit the eBay China story. Former eBay CEO Meg Whitman had prioritized China as a key marketplace, and was furious when she realized that nobody had informed her about decreased traffic caused by data migration to the US. When the dust settled, it became obvious that Chinese engineers would get stuck in a â€œtrain seatâ€ system as they waited for their requests to be approved. A one-word change on the site took nine weeks, and one feature required a whole year.
Now that we have pinpointed the fundamental obstacle for a workable flow between teams, it's tempting to dive right into a review of communication software and services. This would be a rookie mistake. The software is just a set of tools used by people, and too often we allow the software to dictate our processes, which defeats its purpose. It is important to define processes so that each team can subscribe to and then configure the software accordingly.
Conclusion: The people working in a distributed environment are a single team that may have trouble communicating. To spread awareness about efficient communication practices, in our next six posts we will discuss a structure of communications that eliminates common problems and gives everyone on the team the clarity of purpose, process and method to ensure success. Whether you made a conscious decision to work with a remote team or are stuck in this setup after an M&A, read on — there's a way to make it work for you.
Author: Yuri Kurat, CEO at New Normal. Yuri has helped businesses like Amazon, Southwest Airlines and Toyota create SaaS solutions that grow their business.
Call us. We can answer questions and help you think through your idea.