Dealing with programmers

During the Smart Shepherd process, I've found myself in an unusual situation in being the industry expert in the team rather than the technical one.  It was eye opening in a number of ways, but chiefly in bringing into perspective exactly how programmers must be seen by non technical partners in a start up.

The business domain expert is the person in the partnership who has all the connections, who carries the goodwill and has a possibly unattainable goal in the back of their minds about how things should work.  It is all too easy to do a bit of hand waving at your technical partner to just "get it done", or even worse, to insist on being a part of a process you don't understand.

In any partnership where you are the non-technical partner, and you're employing a programmer (rather than a hardware person in this instance), it might seem like roses at the beginning but the relationship may break down quickly when you start speaking different languages to one another.  Typically this will happen when you hit a technical issue, or at the end of the project when you are trying to complete that last 5% to get a functional product.  Take a deep breath and hold your nerve.

To give some insight into the things you should be doing, I'm going to start backwards and list the things that as a professional programmer I would expect from a fellow professional.  As a non-technical partner, all of these things should be expected:

Establish trust

There is an old saying that goes "good fences make good neighbours" and it's just as true for business partnerships.  Agree up front who is doing what and kerb yourself from intruding into things that genuinely aren't your business.  If you find the trust relationship breaking down, you'll never get your product launched.  Trust is established when you listen to recommendations from your partner and they respect your ability to execute your side of the partnership.  Keep those boundaries sacrosanct.

Get your process agreed and set up from the start

There is absolutely no reason not to expect your programmer to set up a version control system that you own from the very start.  Github is extremely cheap, the paid versions allow private source code control and both you and the programmer have fine control over the development and (most importantly) over the release of code into your production environment.  If you don't understand the development process, where bug fixes go, what version control does or what something like Git does, get educated fast.

The greatest thing about Github - if your partnership breaks down, you still have the source code available.  Use a shared account.

Get agile

Modern cloud environments like Amazon's AWS and Microsoft's Azure are astonishingly full featured, cheap deployment environments for your prototypes that can scale to a full, million user experience.  Plus they integrate with version control systems so you have control over the entire release schedule from front to back.  In the face of this onslaught, local hosting companies who only offer virtual machines are now obsolete.  If you don't know what AWS or Azure do, get educated fast.

Git 'er dun

This is the hard part and it's up to you, so get going!