7 mistakes non-tech startup founders make with software development
2+ years of tech-mentoring startups in Parisian incubators (INSEAD Launchpad, Station f Founders program, EDHEC Innovation, Paris&Co’s Welcome City Lab, Moove Lab) have given me an incredible window into the world of early-stage startups, and their relationship with tech (software development in particular).
It’s been an exhilarating experience, and one in which I’ve learned considerably. As a way to give something back, I tried to extract and share some lessons which hopefully will profit a wider audience.
1. Fail to protect their source code
Source code is the stuff that developers write all day long. It’s not the same, in fact can be vastly different, from what actually powers your website on your server, or your mobile app on your users’ phone. To add features or fix a bug, your devs need to work on your source code. Without it, they can do nothing, and your product cannot evolve.
Too often, I have met non-tech founders who were not aware of this, and whose source code was taken hostage by an IT service provider, a freelancer, or in some cases by their tech co-founder. Whoever it was, they would only release the source code against an outrageous sum of money. In many cases, this is a death sentence for the startup.
Your source code should be stored in an account in your company’s name, with a specialized source-code hosting provider, like github.com, gitlab.com or bitbucket.org. It’s really simple to do — and it’s free!
2. Adopt the “Hire-and-forget” method
In the military, “fire-and-forget” is a type of missile guidance that does not require further guidance after launch.
In IT, an unfortunate equivalent is to hire developers, “launch” them towards a target (your product, often vaguely defined), deny them any further guidance, and hope that they will hit the target.
Needless to days, it never happens. You will not get what you wanted, your budget will go through the roof, and you’ll have a very demoralized team of developers (all the more so because they’ll be blamed — unfairly— for the fiasco).
Software development requires your regular and constant input, especially for a new product. You may have a fantastic idea for a product, but as soon as you show it to users, the requirements will change. You may realize yourself even before that, that what looked good in your mind, turns out not to make much sense once you see in real life.
Another reason why this is a bad approach is that it gives you no flexibility to adjust your priorities based on market feedback. To make things worse, you may not even get valid market feedback because you have no product to show until the agreed-upon deadline.
Instead, you want to have a constantly updated product, based on regular incremental changes or addition of features, which you need to test, demo to potential users, and refine iteratively.
You should test the product daily, and meet with your dev team at least once a week.
3. Switch strategies constantly
The surest way to fail in software development is to keep switching priorities.
Now, as we’ve seen before, you definitely need a lot of flexibility to adjust your priorities based on market feedback. But if you constantly tell your dev team to drop what they are doing and start something else because… you’ve got a demo tomorrow with a potential stratetic partner, or a prospect vaguely promised to buy if you add this or that feature; and if your team does not have the time to finish something, you’ll end up with lots of code, but no product.
As a rule of thumb, you should consider the week as a indivisible unit of time, where weekly priorities are sanctuarized. If you want to make changes, wait until the following week. Of course, exceptions can happen (but not every week).
Even this may not be enough. Give your team time to finish whatever they are doing. If you determine that this is not your strategic priority any more, then scale it down; remove non-essential features (there’s always plenty of those), so that they can finish faster and can move on to your next top priority.
4. Keep things complicated
As an entrepreneur, and especially as a startup founder, you should wake up every morning full of ideas about how your product will fix this or that new problem; how new features you’ve dreamed of during the night will make your product even more appealing to customers; how new ways to use your product will open even more markets to you.
You will also be bombarded with suggestions from well-meaning advisors, or demands from sincerely interested prospects, for new features or variations : “If only you did this, we’d buy your product” or “If you had that feature, this market would open up to you.”
Your developers will only be too happy to implement all these extra features. The more complex, the more challenging, the more motivating. In software, anything is possible, and developers take great pride in their ability to implement some technical complex solution to a problem that seemed impossible.
The only problem is that all these additional features add complexity and time to your development timeline; this pushes your time-to-market further and further away. In addition, you run the risk of having a product where no feature is entirely finished, or not enough to satisfy anyone.
Instead, keep it simple. Go for the essential features first. Leave the bells and whistles for later, if you have extra time and resources (you won’t).
As a startup, you need to solve a problem that noone else addresses, or do it in a way that’s much better or cheaper than anyone else. To most customers, you are a risk: where will your startup be in a year’s time? You need to provide extraordinary value to overcome that risk. Fancy features won’t help you.
5. Set unrealistic deadlines
Occasionnally, you will need something done in a rush. You have a unique opportunity to meet with a potential investor or prospect, and it has to be next week, and you know they want to see this particular feature.
Or someone’s defaulted, you’ve been given a booth at a trade show, or a slot to speak at an industry event. So you need something to show, and very little time to get it done.
You will find that your developers will be all too happy to help (unless, of course, they are already seriously demotivated by your mistakes). They will definitely get something done for you.
The cost of this, however, will be bad code (aka “technical debt”). It’s not their fault. You can’t have both ultra-fast results and high quality code.
And sooner or later, you will have to pay for this (that’s why it’s called technical debt). Today’s bad code, if not fixed, will make tomorrow’s developments that much more difficult and slow.
If you do too many last-minute, urgent requests, your technical debt will explode. And you could very well end up in a situation where any development is painstakingly slow, where even simple features take ages, just because of high technical debt.
Don’t overexploit your dev team’s enthusiasm and helpfulness. Don’t ask for rush jobs too often; and when you do, give them time afterwards to clean up the code.
6. Pretend to know more about tech than you do
When you go to see your doctor, you don’t pretend to know more about medicine than they do. When you consult with your lawyer, you don’t pretend to know more about the law than they do.
Software developers are experts in their domain. Even a junior developer knows more about software development than you do. So don’t pretend to know more about it than they do.
Don’t tell them how long a task will take. Software estimates are notoriously inaccurate and unreliable; if professionals don’t know how long a task will take, how do you expect to know? Don’t even tell them the task is easy: All devs, even the more experienced, get surprised now and then by an unexpected technical difficulty in what seemed to be a simple task.
Instead, respect their expertise. If you need something done urgently, tell them why. They’ll only be too happy to help. If you are afraid something is too complicated, and will cost you too much, ask them how complex it will be; if need be, tell them you only want the feature if it’s simple to make.
Treat them like adults. They are perfectly able to understand your business constraints. In fact, most are yearning for this info, and grateful when they get it. They’ll use their expertise to craft the best solution for you, whether it’s getting something done urgently, or figuring out a cheaper alternative to the feature that you want.
7. Blame your devs
My devs are always late! They can’t keep their own deadlines! I’m getting nothing out of my dev team! They take ages to do even simple things! They are not good enough!
If these thoughts are going through your mind, you may want to take a step back.
Sotware projects rarely fail because of developer incompetence (it happens, of course, like in any industry). More often then not, they fail because of bad management practices.
Are you making unrealistic demands of your devs? Are you constantly switching priorities? Are you making your product too complicated? Is your attitude dismissive of their expertise? Have you lost credibility because you are pretending to be an expert when you are not?
It may be, of course, that you have a particularly incompetent developer in your team, or worse at the head of it. But you may also want to take a look at yourself, or you will reproduce the problem with whoever you hire in their place.
Remember that your team is likely going to be a mix of very good, good, average and slightly below average developers. The myth of the sofware wizard that will whip up a fantastic app in a weekend is just that —a myth (or that person, if they exist, doesn’t work for you). To get the best of that mixed team is the goal of management.
Apply the wrong methods, and you’ll make any team worse. Adopt good practices, and you’ll make even an average team perform wonders for you.
