Managing the Developer Relationship
Managing outside developers is tough. Here’s how to go about it the right way to ensure success for your business.
Never let it be “just business”—it’s personal. Really, that's 90 percent 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 percent 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, and 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.
Have clear scope and clear milestones—and stick to them. For fixed scope projects (e.g. $150,000 over three 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 beforehand and known what they were building and when they plan on actually building it. If they don’t know what the milestones are, chances are 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.
Don’t 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 build 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 build and rebuild correctly. If you’re not sure what you want to build, make some mock-ups and get feedback using the lean method. But once you start building your initial product, you need to stick to the 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. $8,000 per week for 35 dev hours) or even an hourly contract if you’re hiring a freelancer (e.g. $150 per hour billed every two weeks). That gives you more flexibility to iterate with actual customer feedback.
Get a Chief Technology Officer—you won’t regret it. 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. This is 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 often micromanage, lay blame on outsiders when they themselves fall short, and because they don’t know what’s going on, the dev shop spends time educating them, rather than building the product.