Alex McPherson bio photo

Alex McPherson

Software Developer in Boulder, Colorado

Email Twitter LinkedIn Instagram Github Stackoverflow

###Mirrored from

Before You Start

Deciding if you want, need, and can afford to hire outside technical help can be a quick decision fueled by a need to firefight, but there are some strategic choices that can make the experience more successful for your company:

  1. Get team buy in. Either explain to them why outside developers are needed, and that it’s not a reflection on them as a delivery team (good) or let them come to the decision that they need help on their own (best). These are the people that will be on the ground and in Slack, Hipchat,, and Jira together. A cooperative, non-antogonistic relationship is key.

  2. Decide if you want an implementation parter or a consultancy. Many times you just need code to be written. That is fine! But unmet expectations of being able to provide value through process advice, development best practices and team mentoring can lead to trouble (not to mention unrealized improvements on your team).

  3. Define success for the contractors. Vague notions of success don’t mesh with signed contracts which can leave both parties unsatisfied. “Ship 1.0 of our API, exposing these endpoints by end of Q2” is a great SMART goal. “Help our team with front end cleanup” isn’t quite as good.

Finding and Interviewing

You might already have a short list, but here are some tips that can help you prune down your options from a larger pool:

  1. Use your network, ask around. Happy clients are always eager to share their successes. Don’t just Google “rails development company”.

  2. Don’t get hung up on specific technical fit. Having experience with a particular jQuery plugin is useless compared to experiences in your problem domain. Ask about how they have done complex data visualization, made performant mobile apps, or used their knowledge to help pivot a product strategy mid cycle.

  3. Look for companies that will push back from the get go. Removing scope during an RFP process shows that they have realistic expectations as opposed to “yessing” their way through discovery just to get a contract signed.

During the Project

  1. Stick to process. You have set expectations for the duration of an engagement, and an easy way to waste time is by training everyone on a new way to accomplish something.

  2. Make time for meta conversations. In addition to writing code, consultancies can offer neutral observations about your team’s process, culture, and product that your own employees may not be able to see clearly.

I’ve made a checklist of questions to ask while you interview technical partners:

Download it here