A few years ago, I remember reading an article by an American venture capitalist who was talking about the reason behind the first bubble. Most of it, I agreed with including the fact that the entrepreneurs were mainly from business backgrounds and obviously did not possess the technical know-how to execute or validate their ideas. Investors were merely throwing money into a brilliantly sold concept by sales guys. This time around, the startup scene is beeen driven by engineers. When it comes to investing, he will always invest in an engineer led team rather than a business led one because you can teach engineers to be business people but you can’t teach business people to be engineers.
As a business person this erked me. I understand his sentiment to the extent that it would take a business person a hell of a lot longer to acquire developer skills than for engineers to learn how to run a business plus they can do it on the job. It’s a lot less risky to say the least. However, business people running a tech startup should learn to code and some engineering/development basics.
Granted it’s not possible to learn all the skills required to build a tech company but if you’re seriously building a tech business then you better learn the principles behind design and development as well as dabble a bit.
One of the things that got me into trouble a lot during the early stages of my career was been nosy, looking into areas that were way beyond my remit. I remember when Haymarket got their CRM system with inbuilt campaign booking functionality, it was a breath of fresh air. We were using paper cards to keep track of conversations and client details, order were faxed and yes, business was purely done on the phone or face-to-face. Back then, such systems were all custom built and for whatever reason the software company hadn’t built in different access rights for different users. I suppose it was assumed that staff would just use it for what they were supposed or needed to. They hadn’t accounted for the curious minded like me. I just needed to know how it worked so I used to explore the system and discovered many things that could be done with it including what would now be considered security holes and vulnerabilities. When I mentioned these things to our IT guy (he originally ran the ad design department before been rebadged with his new title) he was not impressed. I got a serious dressing down and was told I had no business looking where I was looking.
As children, we are naturally very curious, annoyingly asking “but why” all the time. This curious nature is unfortunately driven out of most us. How many times were you warned that curiousity killed the cat when you were younger? But business people running tech businesses must re-discovery that element of curiosity.
The biggest challenge faced by a business person trying to launch a startup is find a tech co-founder. There are so many co-founder meetups, events and sites dedicated to this. The problem with these are that you have to kiss a lot of frogs before you find your Prince. There are plenty of reasons why business people should learn to code but there is one main reason to do so. How will you know who to look for if you don’t know what you need? The fact is that as a business person you are in a vulnerable position, that’s why there are so many horror stories of people spending on poor builds, been over-charged for a project, developers running away with the code (by the way it’s most likely in Github or a similar repository which you should have set) etc.
Teaching yourself to code (you don’t need to become a damn rockstar or ninja) allows to get into the developer mindset not to mention have an apppreciation of why things can take so long. Understanding the different languages, frameworks, testing practices and build principles etc, the conversation you have with a prospective tech co-founder or developer you may hiring as a freelancer is totally different. Remember when you were a teenager and you’d question your parents’ decision asking “but why” and the default reply was “because I said so”. I found that so bloody infuriating. Well, this is essentially what’s happening here, you’re just been told how your tech business is going to be built because the developer said so. If you have no understanding of the different technological options and the impact they will have on what you’re building, how can you ask the question “but why” and be comfortable with the answer.
More importantly, how will you know the cost of the build decision on the business. Things like the language and framework that you choose have a long term cost implication on the business. For example, MOO decided to rebuild their customer design tool using react.js. One of the key reasons was that each time an element was changed, it was automatically repeatedly throught the entire platform. Needless to say this significantly reduced development time saving costs. Developers can finish each sprint quicker moving through projects much faster and reducing the need to recruit more people to get through the work. Teams can be kept small and agile. Whilst it is ultimately the responsibility of the CTO to make these decisions, the CEO should understand the implications on the business especially as it’s their job to continually look for money and make sense of the money been spent.
Business people should equip themselves the language to be able to comfortably discuss tech with developers. I don’t know any developer who would be offended by that, far from it. If they are, run. Otherwise, you have to accept that you will have to kiss a lot of damn frogs before you find your Prince or Princess.