Conventional wisdom is wrong. Or more precisely the people espousing the benefits of distributed startups teams are often distributed and therefore self rationalizing it. Been there.
The reality is that a certain magic that happens when you’re in person is critical in a startup. You attend five customer meetings together over a two-week period and after each meeting you replay the results in the office about what it meant. The CEO weighs in with his perspectives, the head of product management disputes his conclusions and the marketing VP has a different take.
We spend hours of seemingly “wasted” time just in these informal chats simply shooting the shit. With all the recent obsessions about “pivots” most people don’t realize that the more powerful pivots are the unnoticeable ones we make every day through these exchanges. The conversations bleed into the sales messages the next time, they wend their way into software designs and form the plan of attach against competition.
These incremental adjustments are made between people who see each other daily and are so below the surface of even our consciousness that distributed teams can’t see what they’re missing. In a world where 90% of communications is non-verbal imagine what is lost on conference calls.
And from all the office chatter come norms and beliefs. The sales rep that brings back news from the front line that is shared with the office adds to our collective knowledge about customer needs, product design flaws or partnership opportunities. And that rep doesn’t just send an email to his boss – he has coffee with the head of customer service. He downs cold ones with the head of biz dev. He gossips with the office manager who tells 3 software developers.
And it doesn’t stop there. The best companies are built on common beliefs and culture – a common sense of purpose. Those cultural normals are established through human connections: the night we all stayed late to get that release out the door, the day we celebrated our funding round or the day we landed our first big account. The culture is forged through office parties, poker, paintball or film nights. And slowly, over the years, those crazy stories about Danny passed out in the company bathroom after the Summer party get replaced by weddings, births and family picnics. We become more than dispassionate colleagues – we’ve been in the trenches together and survived.
I’ve seen it go full cycle. There is a core that exists in human connectedness that no amount of technology can replace. Just watch companies that grow rapidly in even a single physical address and start to span multiple floors and you’ll know what I mean. The culture starts to change and companies need to work harder to keep up the physical connections – even within the same building.
I’m not arguing that 100% of a team need to be in a single location although that would be ideal. Here are my personal biases:
1. CEO, VP Products and CTO must all be in the physical location. If they’re not I won’t fund. Because the formation of a business is so dependent on “product / market fit” these are the critical roles for me. Also, founders who pitch me when they themselves live in separate locations don’t get very far with me. I’ve heard the line a million times, “one of us will move after we’re funded.” I know, I know. But if your business is super important to you then have the hard discussion up front and one of you should consider moving.
2. I don’t like distributed development teams in early stage businesses. This is a topic that comes up often in Los Angeles because many CEOs are tempted to hire their tech teams in the Bay Area. I think this splits up critical resources and builds separate cultures in two locations. I often advise these CEOs to make the tough choices early in the company’s history – either move up North or build your tech team in LA. There are pluses and minus for both cases. Yes, I know some Herculean CEO’s that commute every week and make everything alright. But I still believe that they would be better off whole.
3. I prefer the first sales hires to be in the home office. I understand the need to have geographic coverage. If you’re a West Coast company you need people on the East Coast. If you’re a UK company you’ll eventually need some local sales talent in Germany and France. When your first few sales reps are in your home office there is a clear tradeoff that you’ll spend more on travel and your sales team will feel like ping-pong balls but I feel this is a better trade off than a sales team that is out of the loop. As your company develops you’ll obviously need to hire sales talent in multiple locations.
4. I’m fine with key developers being in a remote location. If you have the core of your team together but a few key developers live in Oregon, Ohio or New Mexico and don’t want to move to a big, expensive city I’m fine with that but make it a small minority. In a perfect world they’d be in your home office but this is one area where I feel remote tools can help bridge gaps. As long as you have a great product management function and the remote people have established norms of being good independent workers these situations usually work well. Make sure that you spend the money to have them work in the home office for a few days each quarter. Even if they feel it gives them some less productive time it will pay huge dividends down the line in human connectedness.
5. What about call centers? It’s true that call centers often employ tons of employees who are often lower cost per person than your development team or other staff members and therefore it’s often effective to have call centers in lower-cost cities away from your home office. But in the early phases of your company you’re not likely to scale up the call center so until that time comes I’d have them at the home office.
6. What about outsourcing? For me outsourcing in a pure startup is the kiss of death. I’m against it in almost all situations. I believe that startup tech companies need to develop a technical DNA and this doesn’t happen when you outsource. Outsourcing early often happens when you have non-technical founders who don’t know how to get code out the door. For me one of the tell tale signs of a real entrepreneur is that they know how to network well enough to find technical talent to join them. If they can’t, I doubt it will become a big, important technical company.
7. What about offshoring? First, many people confuse outsourcing and offshoring. Outsourcing is when somebody else builds your software. Offshoring is when you have your own team build it but your own team is located a separate location where wages are significantly cheaper. This is sometimes done in a cheaper part of your country but is more often done in a developing country rich with technical talent and smart people such as the Ukraine, China, India, Bulgaria and the like.
I prefer that early stage companies not offshore development. In the world of agile development I believe that rapid output of code and the ability to constantly make changes trumps having a few extra bodies at a cheaper rate. I’ve lived this directly through both outsourcing and later offshoring parts of our development at my first company and was proven wrong by our chief architect, Ryan Lissack, who argued that at our stage of development we were better off with a smaller, locally-based team. When you’ve got offshore people you end up needing longer specs and less changes so it begins to feel like waterfall development.
Will I make exceptions? Yeah, in some cases. But where I make exceptions I expect the VP Engineering and the Chief Architect to all be located in the home office. I expect the VP Engineering to be from the same culture and speak the same native tongue as the offshore location.
I have another exception. There are times where you’re building a non-core piece of software in which you don’t have the in-house skills and likely don’t need them in the short-to-mid-term. My example is that at my second company we build an exclusively SaaS platform except that we needed to build hooks into some Microsoft Office applications. We put the spec out on RFP on a contracting site and received bids from skilled people all over the world. So I’m not opposed to using oDesk in the early stages of your company (to the contrary – I’m a big fan of oDesk). Just don’t use them early in your startup phase for your core development or for the majority of your coding.
In summary: I know that it’s trendy to espouse the virtues of distributed teams. I also know that many of you reading this will work for such an organization and may be remote yourself. I’m not saying your companies can’t / won’t succeed. I’m just saying that I believe distributed teams for the key management members are suboptimal and less productive in the long run. If that’s you – acknowledge it and pay attention to what you can do to lessen the inefficiencies and culture drift.
Or better yet – where possible – do something about it.