How to work with developers when you cannot code

I do not review my developers' code. I could not do it meaningfully and pretending otherwise would waste everyone's time.

What I can do — and what turns out to matter more — is hold the line between what the client meant and what got built.

What the non-technical founder is for

A good developer will build precisely what you describe. That is the danger. Muddy description, muddy software, on time and on budget.

So my job is to arrive with a specification that has had the ambiguity beaten out of it. Not technical detail — behavioural detail. What happens when the field is empty. What the user sees when the sync fails. Which of these two rules wins when they conflict.

Things that have saved me

• Write acceptance criteria before the build starts, in plain English, as sentences the client could read and agree with.
• Ask for something demonstrable early and often. A screen you can click beats a status update.
• Agree how much of the developer's time is meetings, in writing. Good developers guard their focus and are right to.
• Never let a change request travel by conversation alone. If it is not written down, three people will remember it differently.

On paying people properly

Pay on time, every time, without being chased. It is the cheapest reputation you will ever buy. The developer market is small and it talks, and being known as someone who pays promptly gets you better people than being known as someone who pays well.