10 tips for non-technical founders
The web offers boundless resources for developers. It also offers a sea of business advice for founders of all backgrounds.
What about concrete advice for non-technical founders? Often, the advice distils to:
Find a CTO or technical advisor. Without such a person, you are lost.
That advice is sound advice. But founders march on. They will not wait for that trusted individual. They spend money on developers and agencies. But for many business founders who go on to build fantastic companies, their early encounters with software development are painful.
As many others have written, grit in the face of adversity determines many successful business journeys. However, non-technical founders can avoid much of that pain by following a few tips.
Software development should have milestones at least once a week.
A founder should have weekly visibility on progress being made. If a chunk of work needs to be done which requires more than a week, break it down into smaller chunks. Having that discipline can be difficult, but larger blocks of work bring trouble.
Big aspirations are great. Big budgets are not. More often than not, big budgets lead to big waste.
Don’t think that developing software is a one-off investment. It isn’t. It always needs to evolve. So spend in small increments.
Do not buy enterprise software. It is not meant for you.
Enterprise software is neither free, nor open. That means it cannibalizes your development budgets, and is often time-consuming and expensive to customize and integrate. Spend that time and money elsewhere. Use open source.
Control your startup’s code. Watch what your developers are doing. Be paranoid. Use version control.
Do not assume. Assumption is… well… bad.
When managing developers, be explicit. Use written contracts. Strive for unambiguous specifications. If a feature, no matter how small, is not agreed in writing, do not assume it will be completed as you wish.
Servers are cheap. Use them only when you need them. Don’t pay for what you don’t need.
Your README should be beautiful. Remember, this is your code.
Everyone who touches your code should summarize what they’ve done through your README. It is the gateway for new developers to be productive with your code. Without it, more time and money will be wasted.
Don’t use email.
When communicating with developers, use the right tools for the job.
If it’s about the project, then use a project tracking provider like Trello, Pivotal, Assembla, or Basecamp. Or just switch on the issue tracking on your version control repo. Supplement with instant messaging via Skype, Gmail, Slack, or Hipchat. Use face-to-face or phone calls for the important, personal stuff.
Although individuality is great, you want basic standards for your code. Although there are countless differences of opinion on picayune points, without consistency your code will be a mess. It will drive new developers to distraction. Consistency of architecture and dependencies are also important to minimise frustration for all!
Your code will need to be refactored.
It is unavoidable.
That fact is a simple byproduct of the organic nature of code. A founder cannot expect that every block of development will bring a new feature or a bug fix. After enough iteration, your code will need housekeeping. That housekeeping is essential to future productivity.