Somehow everyone thinks that modern product executives should live and work in Silicon Valley. That every successful start-up has an onsite team behind it from the early days. That software outsourcing or offshoring is evil and you won’t get a great product in the long run. Start-ups are too innovative. Blah-blah-blah…

For a long time I’ve been intending to express my own thoughts in this regard because honestly I’m upset to hear people saying these unreasonable things and lumping facts with unsupported stereotypes.

It is not my goal to convince everyone of the necessity to outsource but rather

to inspire and advice on how to better proceed with selecting the right company for it.

Sometimes people draw seat-of-the-pants conclusions, others hear something from friends or read stories on the web and take every word on trust, and finally some have had a bad experience in the past.

In fact, every vendor has unhappy customers. Make sure to find out if previous clients’ complaints are reasonable enough!

In addition, a single case is not yet a pattern. And often people are more likely to share their unpleasant experience rather than enjoyable one.

You might think it’s quicker and easier to assemble an effective and cohesive team by yourself. But the right partner already has it. There is already a set of well-established principles and approaches to their work. The people speak the same language and are willing to help each other. Besides, everyone knows their own and their colleagues’ abilities and strengths.

Moreover, even being called a tech start-up, an organization may not have a technical capability to deliver its vision, and that’s where technology partners can help out.

Intro

Let me summarize a couple of assumptions beforehand so that you better understand the train of my thought. ‘Cause there are exceptions to every rule.

I absolutely do not claim that the majority of vendors are professionals, it’s rather the opposite. Yes, a company needs to take pains to find the right outsourcing partner.

Do research, not just search!

By default I assume that a software outsourcing partner is a company/agency/studio/firm or to a lesser degree an individual freelancer. Why? A bit more in Team vs Solo article.

I also assume that these people are interested in business development, their portfolio, their brand awareness and not just a side job. I can not imagine a company interested in growth and success in such a competitive market and not caring about reviews and references. As for us, if we are not confident of our abilities and the time frame, we’d rather give up the project than sell the client short and as a result bring on troubles and discredit ourselves. We always try to understand the adequacy of clients just as they try to understand ours. Yes, clients can also be different.

I’m also not talking about sub-contracting schemes. I only consider companies that do all the work by themselves. One possible exception is probably design. Not all agencies have an in-house designer (except for design studios). But the whole development process is a must! Sub-contracting creates a longer chain of intermediaries which increases the risk of failure. By the way,

there are lots of “one-man” agencies in the US. So the fact that a person is technically located there does not mean that the whole team is in the US as well.

I do not consider medium-sized companies between 50 and 100+ people. Not to mention giants with 500+ or 1k+ employees. They have their own kitchen, bureaucracy and attitude. And of course the competence level of their staff is very varied. Only large companies can afford to recruit juniors and train them.

I can’t also say anything about outsourcing of such activities as marketing, sales, SEO, SEM, etc. Remember, launching a product is just the first piece of the puzzle. Most start-ups fail in marketing. I’m only talking about web development and I do not believe in an all-in-one approach.

Myth :1 — Miscommunication

Developing a product requires a deep understanding of customer needs and extensive user interaction.

I completely agree that building great products results from deeply understanding what clients want and from great communication. Our team cannot work on a project/product, if we don’t understand and feel the idea of it. With each project/product we work on, we end up adding a lot of value by offering a lot of new solutions, tweaking features that would be relevant to users and so on. But please stop complaining if you hire a junior, graduate or (sorry) some Asian guy for $2/hr and then get surprised by why he is not interested in innovating your project.

Often the problem lies in expectations. If you start with unrealistic and overstated expectations you often end up with disappointment. So I would recommend to discuss your project plan in detail right from the start and keep discussing current progress and problems on a regular basis.

Nothing is obvious. Telepathy does not work. Be explicit!

We believe in creating small agile teams where a product owner is an integral member. Members of a software-development team need to work closely together. A product owner usually interacts with the engineering team for several hours every day to review deliverables and provide constant feedback. Modern communication and development platforms have made distant collaboration easier.

BTW, a good command of English by sales specialists doesn’t guarantee great results. At some point it also applies to developers.

Myth :2 — No Creativity

In addition to the above written.

I believe start-ups should look for smaller tech companies to outsource to, because they are agile, responsive, willing to learn and establish a long term relationship. The level of experience of each team member is much higher and the background is more diverse.

Working with bigwigs is unlikely to be very effective for start-ups.

Some other things that adversely affect creativity:

  • Micromanagement; Read Micromanagement and its Drawbacks
  • Fixed price; I hardly believe that anyone will be eager to improve a project, if the customer always reminds of the budget and does not want to pay more. Of course, this does not mean complete absence of estimates
  • “Last minute” deadlines. If the main focus in the project is placed on tough deadlines, it’s all the team will think about.

All of it also affects quality. There is no way to practice TDD, Pair programming, Unit testing, constant code review and refactoring.

Our team has the opposite problem — abundance of creativity and ideas ☺

Myth :3 — Pricey

If your goal is faster product development + quality, then try not to squeeze the pennies, but focus on getting the best engineering talents to do the job.

You should not outsource your product development only to cut the cost. It’s important to find a team that not just builds products but most importantly feels why and for whom they do it. Such teams are more pricey!

Many outsourcing companies will offer you their best-in-class talents provided you agree on a milestone based payment, that is more than just # of engineers x standard average charge out rate per engineer.

Please do not forget that you do not offer remote developers the same benefit package as to local employees. The former do not have the same protection implied in the employment contract, health care benefits, they must also have their own hardware and office equipment and other necessary things. Not to mention rent, team buildings, lunches, creative office stuff, wasting time on interviews as well as competition in Silicon Valley.

Do you really think 30-50$/hr is too expensive for a terrific person working remotely?

Though it is possible to find local talents, the pool of good developers is limited, and the demand is really high.

Maybe it is better to work with a remote developer who can get problems solved, than with a hypothetical good local developer you haven’t hired, or with a local developer who creates more problems than solutions.

Once again. Do not buy the cheapest. When we’re evaluating our coming project we are trying to prepare a very detailed work breakdown, which defines the number of hours for each activity. Of course, this estimate may not be 100% accurate, but the more we know about the project, the more precise we’ll be. We also often add a buffer on top of our assessments to cover various risks. This does not necessarily mean that the price will be as stated. Invoices are issued de facto and always supported by detailed reports. In the optimistic scenario the price will be lower, not higher. Many “dirty players”take advantage of it and underestimate the project or exclude some items (as if they hadn’t been discussed) to provide an attractive price relying on the fact that after a certain period of time the client will not be able to change the vendor and the company will profit from that trick.

Myth :4 — Extra Management

Some people would simply state that

it is a lot more challenging to manage teams at multiple locations and in different time zones than to manage them onsite. Additional layers of management are often required.

I’ve already mentioned that I take only robust teams (at a single location) and a client in another timezone into consideration. In such case it is always very easy to achieve a 3-4-hour overlap. To me, it even makes you more organized.

Do you have a clear vision of your venture? Do you have an overview document and mockups? And for the record, management of these resources is a non-issue. Managing developers is as simple as writing good requirements and working according to your time line. If you suck at both of those things, you are going to struggle any way you slice it.

Some other positive side effects of it:

  • management is forced to cut the crap and make specifications as clear as possible
  • it means that you have a lot of time to concentrate on solving critical problems, instead of debating on the color of a link or having meetings about the next meetings you’ll have

According to 37signals Meetings are Toxic.

Even when working with local developers, it’s always a good idea not to interfere with the workflow, unless it is an emergency. If you have to fix the specs, or set new directions, and you have to do that often, that means you suck at being a manager. That’s why Scrum sprints take 1 or 2 weeks during which developers manage their own schedule, and if something happens and changes the priorities / specs, the sprint must be restarted (throwing away unfinished stuff, starting from scratch later) … that’s a little extreme from my point of view, but there are good reasons for why some people prefer this way.

There are also good tools for managing remote developers such as bug and feature trackers, or GitHub or Pivotal Tracker. Read about our stack.

Really big open-source projects, such as Linux, have grown like crazy with contributors from all over the world. So I really can’t see the point of nor dealing with remote partners.

Myth :5 — Intellectual Property

I believe that there are always some risks involved when doing anything, anywhere, and with anyone.

The risk of IP theft is never 0% even in the US. But many firms have concluded that the only true protection for their IP is moving faster than competitors, and we can certainly help them do that ☺

There is simply too much at stake for any respectful firm to fold its hands just because of this risk.

Moreover start-ups need to think globally (i.e., become a micro-multinational) and seize an opportunity to create products that can be used around the world. Therefore, it’s not enough to focus only on what US consumers want. Having a global team is a great way of ensuring that you’re creating a product that can address global needs.

In addition, nowadays many outsourcing providers have their offices in US. In case you really think it matters.

What you need anyway

I believe that at some point you will need an in-house team. But building a team is not easy. So you can do it gradually and simultaneously with the ongoing development. I think any competent outsourcing company understands that and will help you up with knowledge transfer. Personally, we are always open to help the onsite team to jump in. We have already done it a couple times.

From the very beginning you can concentrate on business, networking, seeking for investors, events, etc., and not engage in micromanaging your own staff.

I recommend to start with an in-house specialist (CTO or team lead) who will properly manage the development process (your way) and step in when things are not implemented to your standards.

Try to gather maximum information about your future vendor. Is there aLinkedin profile? Are there any references? Track activity on their blog, check out Github profile. Do they have a Twitter account? Check it. Have they been involved in open source projects? How have they contributed to them? This will tell you a lot!

Stay away from ‘Yes men’.

The ability to say ‘No’ is a sign of maturity. You need to look for a partner that can be honest with you from the get-go, even if it means losing you as a client. Setting up realistic expectations is critical to building a long and fruitful vendor-client relationship. Moreover, software development is a vast field and no company can be an expert at everything. It is always better to look for companies that are focused on doing a few things and doing them well.

That’s it. Good luck in your search and endeavors. Any questions? Do not hesitate to ask us!