Written for Portfolio.com

Running a team can be a challenge. Running a virtual team? A bigger challenge. Now imagine running a virtual team with people all around the world, with all of the language and cultural barriers that can arise. Done right, it can be great; done wrong, it can be downright unworkable.

For the last several years, we’ve been working with development teams and outsourced service providers from all over the world—from our own backyard to India and the Philippines. It’s a global economy, even if your company (or maybe especially if your company) is only a handful of people.

Why do we outsource?
We do it for cost reasons, we do it to be able to access “spot buys” of specific capabilities to build our business that we couldn’t otherwise afford, and we do it to create global peace (but that’s for another article). Also, we find a lot of rapport with our partners (and freelancers in general) in the inherent hustle and entrepreneurial attitude in their approach to work. They want it, they are hungry, and there is no sense of entitlement—just like the founders of startup companies anywhere on the planet.

Here are our suggestions for building a great working relationship with an offshore team. You may notice that many of these suggestions apply equally to building a local, in-person team.

Know what to outsource and what to think twice about.

There’s something that we internally call “the specification tax,” or the “requirements tax.” There are some things that can be very easily outsourced because there are well-documented international standards in place, or a task with an easily defined process.

Where there are no such standards, be very careful not to get seduced by low rates—the overhead and opportunity cost for managing revisions and changes will more than make up for the savings. More importantly, you may not ever be able to get it right. Please note that this is not about the skill of the offshore team, but about the ability to communicate.

What’s easy to outsource?

Technical, development, or process tasks that are easy to document. From a development standpoint, database creation and maintenance, open-source installation and configuration. For example, “install Magento e-commerce on our server”—that’s something that requires skill, but there is not a lot of variability in execution. Other repeat tasks, where a defined process can be put in place, such as link building or structured data management and data entry.

Conversely, it’s hard to specify some tasks at a level that will get it done right.

Here are some development tasks that are culture heavy: language/copywriting, brand, usability, and visual standards—even user interface. To get this to work, we really have to slow down and say, down to the button level, what we need. As Malcolm Gladwell pointed out in his book Blink, there are countless “thin sliced” observations and decisions included in any one judgment or thought, especially when the person has a lot of experience in a particular realm. That’s pretty hard to tease apart enough to communicate to someone without that lifetime perspective. The corollary to this: Always be more detailed and specific rather than less any time you’re working with outsourced providers. And use pictures!

Know what you’re getting into—global outsourcing isn’t for everyone.

Physical rapport, nonverbal communication, time-zone issues, and language all pose significant adjustments to the standard way of working. For example, the hardest thing for my business partner was firing up the computer for an 8 p.m. call with India, where they were just kicking off the workday. As he put it, “that’s critical family time, really valuable time with my wife, and the hardest part for me about outsourcing.”

There’s also the immediacy question. If you need a quick answer during the workday, there’s a good chance that your offshore partner may be in deep REM sleep. Many providers have worked around this issue, extending or adjusting their core hours for better client service. It’s a good question to dialogue with your provider about at the beginning.

Get to know the provider’s real skills.

In some cultures, there is a tendency to say “Yes, I have done that many times,” and then to try to figure it out. After a few uncomfortable experiences, we started to approach work with new partners not only by seeking referrals first, but also by putting small projects out as tests, and then putting out bigger and bigger projects until we hit the providers’ capacity limits. These kinds of baby steps build trust on both sides and let you get a sense of how your partner, and individual members on their team, work and think.

Perhaps most importantly, invest the time to understand your partners’ culture.

This could be really simple stuff, like formality of communications. The seemingly casual nature of American communication can sometimes be really off-putting, especially to people who haven’t worked with Americans before. Just by taking the time for salutations and cordial sign-offs, and to inquire how the team is doing, makes all the difference, instead of rapid-fire task notification. When in doubt, be more formal and polite rather than less.

Even simple things, like knowing when your partners’ big holidays are, show consideration. Our Indian partners always wish us a Happy Fourth of July and a Happy Thanksgiving—and we wish them a Happy Diwali or a fantastic Holi , and (probably more importantly!) we don’t expect them to be working on those days.

More seriously, there are real work style issues that can come up between cultures, and those should be addressed from the beginning.

Specifically, some cultures have a more regimented approach to responding to customer requests: Do what the customer says, even if the customer is wrong. Americans tend to like “pushback” and thinking for oneself—and really appreciate it when a developer who sees an edge case or a maintainability issue in any given proposed approach argues back. Make your preferred approach clear from the beginning, and choose partners who are willing to do that.

Finally, make use of the host of Web-based tools available to you.

Things like DimDim, Skype, and online project management or collaboration tools such as Basecamp or Intervals are a global worker’s best friend.

Our conclusion

If you have a well-defined task and can communicate the requirements well, then you’ve got people all around the world who are available to get the thing done on a moment’s notice. It economically speeds the velocity of venture creation and creates interesting new global relationships.

Originally published on Portfolio.com , 12/19/2010

When you start a business in an emerging market segment, chances are you’re trying to solve a problem that a lot of other people are trying to solve at the same time.

As we’ve hit various milestones in our development process at ClickMarkets, and the closer we get to market with our WideAngle metrics product (an online software designed to manage the vast world of social media for businesses and organizations) there seem to be new competitors popping up every day with brand-new solutions.

You can write it off as healthy entrepreneurial paranoia- but this anxiety about whether our cake is good enough to win the bake-off, or whether we’ve been toiling away on something mundane–has actually prompted me to codify when we will take a deep dive evaluating a competitor, and when we will ignore them.

We’ve been working on our software in stealth mode since early last year. It’s been a thoughtful process: First, we worked with real customers to document needs and best practices, then developed manual processes and reports to test out the value proposition. We tried to mitigate risk by selling the manual reporting service to measure market demand and price sensitivity before we wrote a line of code. Then, in the fall, we took the plunge and began designing databases and user interfaces, and hired the right developer. In the last month, we’ve began to use the product internally for our social media customers, and are now finally going into quality and security checks for a broader release, doing demos.

Every time I’ve been in this prelaunch position, the same nagging thoughts arise: What if someone else’s product has more pizzazz? More usability? More value? More of that certain hip “je-ne-sais-quoi” that takes it viral? That certain something that just makes it smell like a winner? Sometimes I even let my mind wander a little further: Even if the competition isn’t better now, how much cash, how many connections, how many smart people do they have, that may allow them to close the gap faster? If I’m trying to build a leader in a segment, I should worry about that stuff, right?

Generally, my philosophy is to serve the customers you have extremely well; satisfy them; listen deeply; respond; work hard- and don’t worry too much about the competition.

There are two major categorical exclusions, where we really do pay attention:

The obvious one is Sales (companies we will run into directly in the sales process).

Another less obvious reason we look at competitors is so we’re not blindsided by something that could stop us from Winning Big. So often, the winner in an emerging market is a matter intangibles (who knows who, who architected for a sale, who had better PR). If I have a better-funded competitor, they may not only beat us on deals, but they could get my VC money, hire better people, or simply create market/buyer uncertainty even if the product is worse.

With that in mind, for the startup phase, here is the approach we’re applying to “competition watching.”

We monitor the competition by running programmed searches of social media, news feeds and blogs from our industry, as well as venture blogs and the web at large. The terms we search include company names and keywords and phrases. Because we have a small staff, we review these every couple of weeks to see if there’s anything new we need to know about.

If there is something new, we do a quick scan of their web presence and put them in three buckets:

• Barking-at-the-Gate (same target market, same problem, same go-to-market approach)
• Neighborhood Dog (differs on one or more of the above criteria)
• Cat (not a competitor, may be a partner, knows something about our segment)

We do a deep dive on the Barkers, from a sales and product development perspective. Here are the questions we want to answer:

• Will we overlap in the marketplace in the short term? As a startup, I want to know if we’re going to run into them in our early sales calls, so I can have my answers ready. One of the first screening questions in deciding to invest in digging into a potential competitor is: Does this company appear to be going after the same type of customer? If we’re selling to small and medium sized businesses and agencies and this company is reaching out direct to big enterprises, they are not going to get my attention right now. If they are selling to a different market, I may take a moment to think about why they pitched that segment and its value, and whether there’s any reason to put that in line for later evaluation.
• Are they trying to solve the same kind of problem? If not, we may take a cursory glance at the way they are positioning, to understand what aspects of the problem they might have seen that we haven’t seen. Sometimes, someone will approach the same problem with a totally different lens. What can we learn from them? Have they been able to solve a more difficult problem than we have?
• If the company is still looking like we need to take notice, we’ll go a step further, and ask: Are they credible? Who’s behind them? How user-friendly and design-savvy is their self presentation? We may look for evidence of credibility from the market, too. What’s the trend and tone of their mentions in social media?

If we are still going and the prospective competitor hasn’t been dropped into another category by this stage, then someone is going to have to do some work, and that someone will be sales support. The question they are looking to answer is:

• What will a prospect see, and how will we respond if this competitor comes up in a call?
• What are the strengths and weaknesses of the product /service offering a prospect might see neck-in-neck with our offer? What’s good about them, what’s weak? What about pricing? Is there anything in the marketing language that we need to be aware of? If possible, this is the stage where we do a free trial (of the competitor?) and evaluate the offer. Are there any features that could be dealmakers that we’re missing?

Mostly, I just want to know my own customers, know what they need, focus on what they need, and solve their problem in the most elegant way. But never to the point of refusing to learn by what other creative problem solvers are putting out there. We’re in the final days of core development now, stay tuned.