Managing the Developer Relationship
Managing outside developers is hard - here are some things that could help make it successful.
Personal relationship, personal relationship, personal relationship. Really, that's 90% of it. Build a personal relationship with the shop. Again, there is no way for you to force a dev shop to complete the work on time and on budget. Our dev team once took a rescue project from a multibillion dollar client whose previous vendor just said “we can’t do it so we’re not going to” and not only stopped work, but stripped out 80% of the code because it was “proprietary”. Cultivating a personal relationship with someone senior at the dev shop – knowing where they work, meeting them in person, getting face time – goes a long way towards making sure they will champion your project. You’re an entrepreneur, so your project is not just professional for you, it’s personal. You want that to be true for the dev shop as well, because if your project is more than “just business”, then doing a less than stellar job on your project won’t just be a “risk of doing business”, but a personal failing that most honorable people will do everything they can to avoid. Never let it be “just business”.
- Have clear scope, clear milestones, and stick to them. For fixed scope projects (e.g. $150k over 3 months on an agreed upon set of specs), professional shops will set out weekly milestones up front so you can make sure they keep pace as the project goes forward. If a shop says they can’t do this because things are always changing or they’re “agile instead of waterfall”, be very careful – in order to give you a fixed quote, they already should have architected the product before hand and know what they are building and when they’re building it. If they don’t know what the milestones are, chances are that they don’t really know how to build this product and they’re going to figure it out once they take your money. This is very dangerous because they may not be able to build it at all, but you’ve already given them your deposit.
Do not be seduced by industry jargon like “agile”. A lot of first time entrepreneurs think that “agile development” means changing their minds each week about what they want to build. That’s not agile, that’s stupid. Yes, you should iterate according to customer feedback. However, if you don’t have a product, then you don’t have any real customers to give you the feedback that allows you to iterate correctly. If you’re not sure of what you want to build, make some mockups and get feedback using the lean method, but once you start building your initial product, you need to stick to plan, otherwise the dev shop will have an excuse to charge you more money, delay your product, or even stop building it halfway. Once you have your initial product, you can switch to a fixed hour contract (e.g. $8k/week for 35 dev hours) or even an hourly contract if you’re hiring a freelancer (e.g. $150/hr, billed every 2 weeks) that gives you more flexibility to iterate with actual customer feedback.
- Get a CTO. We put this last even though it’s probably the most helpful thing, because many people don’t have this luxury. You don’t necessarily need a CTO nor do you need one before you start a contract with outside developers, but good dev shops like working with clients who have CTOs because a good CTO can appreciate good coding, it's easier to communicate issues between the engineers, and a client CTO can help keep development on track, which good dev shops appreciate. Bad dev shops generally fear a client who has a CTO because they're afraid to be found out, or they're afraid to be replaced. Of course, if you have a bad CTO (e.g. you're building a mobile app but your CTO knows nothing about mobile), then nobody is happy - bad CTOs will lay blame on outsiders when they themselves fall short, they often micromanage, and because they do not know what is going on, the dev shop has to waste time educating them rather than building the product.
So there you have it. Again, this series of articles is not meant to be comprehensive, but rather to give you an inside view on how a dev shop views the outsourcing process, and insight on some of the issues that we've seen because we probably see a lot more of these projects than the average startup founder, who only sees his/her own. For more information, feel free to contact the author.
Appendix (random tips):
Contract types: so there are two kinds of contracts you’ll usually see with a dev shop – fixed scope contracts (e.g. $150k for fixed specs over 3 months) or fixed hour contracts (e.g. $8k/week for 35 dev hours). Freelancers may give you hourly contracts (i.e. $150/hr for however many hours, billed weekly). We generally recommend fixed scope contracts if you deal with a really good dev shop – those shops generally charge a lot per hour, but they have better devs who can finish much faster than lesser engineers so the end price might not actually be that much higher than if you hired a cheaper-per-hour team.
Ancillary costs: Often times, your development contract will not include ancillary costs, such as an Apple account for appstore submission, server hosting, plug and play backends, etc, which can add up to a couple hundred a month to start but quickly balloon as you scale. Be prepared and ask about this upfront.
Stability, scalability, iterability: a good product is stable over time, scalable with the number of users, and modular, which means that the product is built in small, self contained pieces. This means that if one piece breaks, you only need to debug that module rather than rewrite your whole product. This also makes your app easily iterable – easy to change according to customer feedback because all you need to do is add, subtract, or edit these small modules rather than redo large portions of your app every time you write a new feature. This will allow you to be truly "agile", and not just in the jargony meaning of the word, and that saves you time and money in the long run. To make this happen requires good architecture in the very beginning of initial product development, and good developers throughout the course of your product. If you can read code, you should evaluate the code of your outside developers to make sure they achieve this.
- Set regular check-in times and stick to them. This will prevent too much slippage in your schedule, highlight problem areas early and provide gentle motivation to show regular progress on the project.
- Use a centralized communication tool like Slack to get the development conversations out of email and into one place that supports group and one-on-one conversations.
- Establish ground rules:
- How will you communicate changes?
- How will you capture/manage wish-list or future development items?
- How quickly will each of you return phone calls or emails for escalating issues?
- Think about the friction points you've had with other vendor relationships and have a frank discussion up front
- Use a bug / change management tool to track change requests, problems and issues. This helps you and your team provide standardized feedback to the development team, prevents duplication, keeps your requests in one place and provides transparency to the entire team.
- Define who the subject matter experts are on your team so the developers know who to go to first.
- Try to incporate video into your remote meetings rather than just screen shares and phone calls. Eye contact, body language and facial expressions can add a lot of context to your discussions and help to foster a more personal connection with remote teams.
Timelines and Estimating Effort:
- Let the developer know what your goals are and by when. Then let them tell you what can be done in that time and what the schedule looks like. If you have too large a wish list for too small a timeline, this will help you work together to break the project into smaller pieces with your ultimate objective in mind. For example:
- Do you have a key client demo that needs to happen on X?
- Need to be live in the market by X?
- Need to have a proof-of-concept to show investors?
- Build in time for testing and mistakes. This is especially true if you're building something that hasn't been done before.
Don't underestimate the power of a whiteboard sketch:
- Quick workflow sketches can help the development team understand what you're looking for faster. If writing complex scope documents isn't your strong suit, sketching how something flows can often times help. Supplement the sketch with quick bullet points on each stage of the flow.
- No whiteboard? Use paper and capture the idea with a picture from your phone. Or use a PDF capture app that can turn multiple photos into a PDF that you can later add annotations to.
- Something in the app not working the way you need it to? Sketch out the current process and then how you would ideally like it to work. Posting that support information to a bug ticket can go a long way in reducing the back and forth that happens when troubleshooting.
Say thank you:
- This supports the first suggestion offered, build a personal relationship, but it is more specific. Be sure to say thank you, because developers are not just making you a sandwhich on order. Good developers will add value to your idea and together you are building something wonderful!
- Small gestures like a starbucks card to acknowledge a late night, an uber gift code to say the ride home is on me, or a grubhub code to treat them to lunch can go a long way
- And while little gifts are nice, a simple thank you is in itself a great way to build that personal relationship. You would be surprised how often clients forget to do so.