There is no shortage of advice out there for startups. Just Google that exact term and you’ll find guidance on topics ranging from funding to advertising, recruiting to business plan development, and everything in between.
There are also – literally – hundreds of billions of dollars up for grabs as new companies crop up and grow to disrupt huge markets. Startups are often strapped for cash and need to make business decisions with ROI in mind. This is a given.
That’s one of the reasons the offshore development model has become so popular.
In a technology startup environment, that QA group in Bangalore – the one that comes in at half the cost – is very appealing. Your expensive lead architect and UI designers are in New York, so why not have the rest of the engineering team in Eastern Europe, executing at a fraction of the cost?
Variances of this model can also be seen on our own shores. The engineer with the skill set you need is located in Silicon Valley, but the best product manager in the industry is in Boston and neither is willing to relocate, or the company won’t cover the move. The core team sits together in San Francisco, but a few folks always work from home so they don’t have to commute from the East Bay.
After all, it’s less costly and more convenient, right?
This is a classic mistake of being penny wise and pound foolish. Distributed teams can work for well defined and regimented work. But startups working on new, disruptive initiatives don’t fall into that category. There are big and fundamental things to work out. What are the basic UI constructs? What are the first few important features? What are the core architectural components and how are they assembled?
Companies need to examine closely how effective the distributed workforce model really is in a product development environment where creating next-generation technology is the goal. While companies in their infancy may initially see cost savings by adopting an offshore or onshore distributed model, they will undoubtedly suffer from the loss that comes with having their best minds scattered across the globe instead of collaborating in the same room together.
Managing by the spreadsheet will only get you so far. Spreadsheets don’t lie – putting a world-class QA or technical operations team in the same room with the engineering and product teams will cost more, maybe even 100 percent more. Dumping your cheap labor in Eastern Europe and forking out the cash to hire local talent gets expensive fast. Add in some relocation expenses and recruiting incentives, and you’re talking the cost of a few additional heads.
But these “pennies” pale in comparison to the “pounds” gained over the long term to having a centralized team.
I’m not knocking distributed teams entirely. If they’re organized and run well, distributed teams can handle small amounts of change. People often tell me that their distributed development works because they have great project managers. But what I’ve found this to mean is that it can work if you have excellent project management and communication, and your project is fairly static with little change. Even your ace project managers don’t stand a chance for anything more dynamic than that.
Change is constant when you’re inventing something that will radically alter the market you’re in. Things are new, so the plan only works for a few days or weeks before you revise it. No amount of e-mail, text messages, or conversations via Skype will make up for the implicit communication that takes place when everyone is sitting in the same room together. Problems like these are often solved on the way to the water cooler:
- What customer feedback do we have that is making us reconsider our feature set?
- What is the lead architect putting in place for frameworks and what alternatives are being considered?
- What does the UI designer think isn’t working well and how do we change that?
- Why is performance slowing down as new customers are added? Is it the code we just pushed out, or is it an infrastructure upgrade that technical operations just deployed?
Despite the plethora of communication tools we have at our disposal, the fact is people solve these types of problems more easily with the people in their physical environment.
Real-time communication can’t be duplicated when half your team is in another time zone. Each delay in communication for the distributed team – or worse, each miscommunication – results in the loss of precious time to market. Worse yet, it means that the wrong features, inferior UI, poor quality, or bad architecture go into the final product. This compounds over time, leaving you less likely to capture that massive opportunity you’re pursuing.
Maybe you don’t buy this argument and don’t agree that sitting in the same room can really alter your overall success to this degree. If that’s the case, ask yourself if you’re truly gunning to disrupt a market, or if you’re just really going after tons of pounds.
Humor me. Take your spreadsheet and change it to reflect that you are, perhaps, 10 times more likely to win in the market if your best and brightest are all sitting in the same room. It makes the 100 percent increase in cost for a co-located team look like pennies, doesn’t it?
Todd McKinnon is CEO of Okta.