Blog

Perspectives on entrepreneurship, startups and venture capital from K9 Ventures.

Startups: Just say NO to outsourcing, contracting, and distributed teams

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

One of the 5 necessary but not sufficient criteria I use for evaluating investments for K9 Ventures is that the entire team must be together and be local to the Bay Area. In fact, I have an explicit exception for companies that rely on outsourcing, contracting, or those that have distributed teams. The reason why I want the teams to be located in the San Francisco Bay Area is the subject of a whole blog post in itself (coming soon!). For now I wanted to talk about why I am so opposed to any outsourcing, contracting and distributed teams for small (< 10 person) tech startups.

The simple guideline is this: If you are a tech startup, where the technology is your business and not just supporting your business, then you shouldn’t be relying on any outsourcing, contracting, or distributed teams for developing your core product.

Okay, so now that that’s out of the way let me move on to explaining why:

My opinion on outsourcing, contracting, and distributed teams is based on a very simple desire of removing as many points of friction between the core tech team and trying to facilitate as much face to face time as possible. The best work, IMHO, gets done when the core tech team is all in one room — within shouting distance of each other. If I have to type up an email or enter a bug report in order to get something fixed, that’s simply not fast enough! Instead, I want to be able to tap the guy who wrote the code on his shoulder and tell him, “Dude, your code is broken, fix it!” For a small startup, the overhead of managing a remote or distributed team far outweighs any cost advantages that may be exist.

In the very early stages of a company’s development there is a lot of fast-cycle learning that should happen and needs to happen. If the founding team is not capable of building its own product, and instead of building the team locally to do it with them, relies on outsourcing or contracting, then that learning is a) not happening in as tight a loop as it needs to, and, b) is not being fully captured in the company. The job of the founders is to build expertise and capture it within the company — that is what adds value for a tech company.

This can be seen in the early M&A / talent acquisitions that are common these days, where the value of the company is typically a multiple of the number of engineers in the company. (Note: This should not be construed as an opinion for or against on talent acquisitions — but simply an observation to support the point that to capture the value in the company, you have to build the team.)

This also what makes reliance on contractors dangerous, since the learning is not really being captured within the company, but is leaking out to a third party. If the long term intention is bring the contractor on board full-time then that may be a reasonable path. However, that expectation should be set up front, so that the company knows that the contractor would at least be open to the option of joining the company full time in the near future.

Having the team together in one location is important not only for the tech team, but also for the business team. In fact, in most early stage startups the technology, the product, and the business are intricately tied together and also happen to be done by the same core team. Sometimes the best idea and the best work doesn’t happen when you’re sitting at a desk, but happens when you’re walking to lunch with your co-workers and someone says “You know what would be wicked cool…” Those serendipitous moments are lost when you have a distributed team.

I know there are several people who will give me counterexamples to this post. I acknowledge that there are cases in which outsourcing, contracting and distributed teams have produced outstanding work. However, I believe that the chance of success of a team is an order of magnitude higher when the entire team is local, in one room and working closely with each other.

Bottom line: “When you put a couple of smart people in a room together good things happen”

You can follow me on Twitter at @ManuKumar, or, follow @K9Ventures for just the K9 Ventures related tweets.

14 Comments

  • GabrielMtn
    Posted May 20, 2011 at 10:02 pm | Permalink

    Thanks for this! It’s nice to have some support in avoiding the pitfalls of development and entrepreneurship. This was very illuminating, and I’m looking forward to the follow up! Thanks again!

  • eugmandel
    Posted May 21, 2011 at 8:02 am | Permalink

    Manu, I agree with your point about outsourcing and contracting (although, I’m sure there are founders who figured out how to use them effectively). I have personal experience with distributed teams and they can work great, you just have to know how to do it. It takes more effort to make them work – create the right culture from the beginning, make sure that there is constant communication and an easy way to reach everyone. The most challenging thing was to recreate the serendipity of an office, and we found a way to do it with Skype, SocialCast and Google Docs. One can either say no to a challenge or find a way to make it work and turn it into a unique advantage.

  • pgatour29
    Posted May 21, 2011 at 9:07 am | Permalink

    Good post. but this article would be more appropriate and probably more useful if we were back in 2001. Fast forward 2011, with the appropriate utilities and management skills getting everyone on the same page from 4 different regions is not a drawback, it’s an advantage, when you factor in (Accountability and Responsibility). As you have stated in your article which is always true, if you put a couple of smart people in a room good things can happen. But allowing these smart people to work independently is just as important. Letting smart people work and manage their own schedule is far more efficient and productive than to be in the same room where in most cases, smart people do not like being micro-managed. With the up-tick of the economy, along with the surge of startups to getting funded so quickly, bringing on good coders from one region and then paying them as to what they are worth is far more difficult than most people think. If you were one of the lucky startups to score $2-5M, then go nuts and pull people from other startups or existing entities, otherwise go out and get those people where ever they are. As the article states, if you can get those contractors to commit for a long term or permanent status and eventually relocate them to the same region at a later point in the project then great. Unless you’ve done multiple projects and where it helps is that you should be a programmer to be able to manage offsite development. Even most cases, if the founders can’t code and have a bunch of developers in one room, there is no guarantee that it’s going to go smoothly. Do your research and know what you are doing.

  • Tagmotion
    Posted May 25, 2011 at 6:18 am | Permalink

    My tech team is on contract and I wouldn’t have it any other way. I have them because they’re amazing architects & developers, not because they’re cheap: it was largely a question of talent.

    We make up for the tyranny of distance by meeting regularly on Skype & I fly to them for major planning meetings etc.

    It was also a question of fixed vs variable cost:

    I have a self-funded startup & couldn’t afford to have developers on my payroll. So a contract with a hot team of developers made sense. They get a % of any outcome in return for giving me a discounted rate. So they get a slice of the action without any liability. And I get great talent I couldn’t afford to have on my payroll. Yet.

  • manukumar
    Posted May 28, 2011 at 8:15 pm | Permalink

    @eugmandel There are ways to make it work, but all of what you describe is what I would call “overhead.” It may make sense for an established company, but having this much overhead in a startup isn’t something I like to have. Startups have enough challenges to overcome already, they don’t need any more.

  • manukumar
    Posted May 28, 2011 at 8:24 pm | Permalink

    @pgatour29 I agree that hiring is a huge problem — especially in the Valley. Several of my portfolio companies have ended up hiring people who are not in the area and then having them move to the Bay Area.

    With regards to utilities and tools — no amount of technology can make up for the face to face discussion on a whiteboard or over lunch. I’ve built collaboration tools and having done so has only made me a bigger fan of not having tools limit my communication bandwidth with other team members.

    Having people co-located doesn’t mean that they’re being micro-managed.

  • n3n
    Posted June 1, 2011 at 6:35 pm | Permalink

    Ín general I agree with you, but in very specialized fields (device drivers, system internals) it can be better to contract experts who has teams with strong experience and difficult to build on your startup.

  • 1111111
    Posted August 5, 2011 at 12:05 pm | Permalink

    False. Leveraging a community of minds across the world provides for a far greater advantage – having the ability to unlock this truth is the key.

  • luislorgio
    Posted April 7, 2012 at 5:41 pm | Permalink

    It is important in these companies take into account thetechnology and innovation, when you want fast results @

  • susanf
    Posted October 18, 2012 at 12:33 pm | Permalink

    The following is highly inaccurate. 
     
     “This also what makes reliance on contractors dangerous, since the learning is not really being captured within the company, but is leaking out to a third party. If the long term intention is bring the contractor on board full-time then that may be a reasonable path. However, that expectation should be set up front, so that the company knows that the contractor would at least be open to the option of joining the company full time in the near future.”
     
    Contractors add a wealth of knowledge to a potentially stale and unoriginal development environment.  Most contractors are not unreliable.  The management that hires them are; as is are the recruiting agencies that help eliminate them and profit off of layoffs.  Thus,  the focus that  temporary labor is just “human capital”, the flexibility and benefits of contracting have diminished along with the attitude that the contractor is a valuable asset through the years.

  • susanf
    Posted October 18, 2012 at 12:35 pm | Permalink

    The following is highly inaccurate. 
     
     “This also what makes reliance on contractors dangerous, since the learning is not really being captured within the company, but is leaking out to a third party. If the long term intention is bring the contractor on board full-time then that may be a reasonable path. However, that expectation should be set up front, so that the company knows that the contractor would at least be open to the option of joining the company full time in the near future.”
     
    Contractors add a wealth of knowledge to a potentially stale and unoriginal development environment.  Most contractors are not unreliable.  The management that hires them are; as is are the recruiting agencies that help eliminate them and profit off of layoffs.  Thus, due to  the focus that  temporary labor is just “human capital”, the flexibility and benefits of contracting have diminished along with the attitude that the contractor is a valuable asset through the years.

  • Posted August 25, 2013 at 7:59 pm | Permalink

    My strong belief is that you cannot find the right speed of business if you do not distribute your company between let’s say US (headquarters, commercial departments), Ukraine (software development), China (hardware and manufacturing), India (call centre and operations).

    Another thing is the cultural difference or proximity between different parts. It is not possible for employees make all decisions based on procedures. You have to make sure people are of the
    * same passion (selection of right personalities and structure of motivation);
    * same approaches (appropriate inception into business idea and goals; general corporate trainings);
    * high talent and work ethics (for example a company raised a round but could not perform for more than 6 months because they were looking for developers locally before they went to us);
    * open information broadcasting (everyone knows about everything that happens around the business even if they are not business guys).

    Would I choose between local and distributed team, having all the parameters equal, I would choose a local option. But there are other parameters into count which state that world will not be local any more…

  • Piotr
    Posted September 26, 2013 at 6:56 pm | Permalink

    “Dude, your code is broken, fix it!” makes me think of micro-management. I worked in an office and I worked remotely. I always was more productive on my own. You know us introverts who need to be away of humans to get things done. :)

  • Saurabh
    Posted October 2, 2013 at 9:19 pm | Permalink

    I am not sure why people try to force an experience which worked for them down the gut of generality. Manu whatever you said might have been worked in your context but might not be the only possible way to look at things.There are loads of models where development teams are based cross geographically and the product shipping cycles are doing great.There are loads of companies that hire contractors for specific modules of a product to benefit from the intensive knowledge and experience the contractor has had working on similar technologies and domains.I am not sure if you have heard of Fog Creek software.Check out how they operate and they have been profitable ever since they started.Credit of course goes to Joel Spolsky but other than that to their policies of cross hiring across multiple geographies.Sometimes sitting in the same room micromanaging a bunch of uninterested developers can exponentially increase your burn out rate.

Post a Comment

Your email is kept private. 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>