I’m rarely as befuddled as the times that I come across a company trying to build software without enlisting the expertise of a CTO/tech VP/consultant/[anybody!] who understands software, business, and how to connect the two.
I’ve seen this manifest itself in two very different types of companies.
Startups do it out of “necessity”
So many non-technical people I meet are trying to bootstrap their next idea with minimal funding and think their best first move is to find an engineer to begin executing the vision. They do this because they don’t have a technical co-founder, are having trouble finding an advisor, and don’t want to wait to make progress. “When I get the MVP done, I’ll get investment and hire a CTO then,” the argument goes.
If you’re starting a software-based business without a technical co-founder or advisor, please pause, breathe deeply, and think very critically about what you’re trying to do. In a field where you have little or no expertise, you’re going to oversee the build-out of something that makes your most complex Excel masterpiece look like first grade homework. How are you going to know a good engineer when you see one? How will you know if real progress is being made? Are you certain that your vision is technically feasible within the constraints of the known universe?
Think about it another way. If a friend came to you with a great software idea and asked if you could help her hire an engineer, direct the work, and provide some assurance that the end result will meet her business goals, what would you say? If you couldn’t confidently respond, “Yes, I’m well-versed in these things and will admirably execute your vision,” then I hope you’ll immediately see the fallacy in thinking you could do the same for your own software idea.
An even more egregious error I’ve seen startup founders make is to raise plenty of money and still not retain the services of a technical leader. They hire engineers or a software firm instead, relying on the coders to “do their thing” while the business-to-tech translation is handled by the CEO or non-technical product guy. I know one startup that took this path and burned at least half a million dollars before scrapping and rewriting the whole thing.
Software startups need software people in their founding teams. Full stop. If you can’t find and convince someone to be your co-founder (or, at least, a very strong and equity-incentivized technical advisor), change your idea or your pitch or your finances until you can. But please don’t march forward guns a-blazing. Or, if you do, be prepared for tears and heavy drinking.
Established companies do it out of ignorance
More established companies can fall into a similar trap. Those that aren’t primarily software-based (e.g., manufacturing, services, healthcare, etc.) frequently take up software development as an addendum to their existing business. For example, a manufacturer of auto parts might realize that its customers are demanding a web portal for viewing real-time inventory levels (NOTE: totally fabricated example – I know nothing about the auto parts industry).
When this happens, these firms frequently put software development under the same organizational umbrella as some existing function, such as IT or Operations or (non-software) Product Development. They believe incorrectly that software development is simple enough or similar enough to what they already do that they can use their existing management and processes to make it work. They’ll either hire engineers directly or contract to a software firm to build their custom application – with nobody in charge who understands how software gets built.
At the risk of stating the obvious, I consider this a terrible idea. I’ve watched companies burn millions of dollars this way. Whole applications and years of effort thrown away. All because they didn’t find somebody to advise them on the way to get it done before they started.
Why this doesn’t work
Building software without a software leader doesn’t work because software is very complex and not at all similar to anything else in business.
A lot of people (me included) like to draw analogies between software engineering and any number of well-understood activities, like building a house, manufacturing widgets, etc. But these are word pictures that don’t capture just how different building in a non-physical space can be. We draw those analogies because, relative to coding, they’re easy to understand. Software is hard to understand if you don’t live and breathe it, which makes managing it impossible for non-technical people.
A great software leader is comfortable in this space and can make it work. To that point, here are some of the things a CTO/VP of Engineering/senior technical advisor can do for you:
- A good software leader sees the holes in your plan. You’ve got this idea in your head. Or you’ve drawn a design on paper. Or you’ve drafted a detailed document outlining the whole system that you’re sure is going to work. But trust me when I say that the thing you want to build, unless it’s trivial, will take much more time than you think and is riddled with holes you haven’t considered. A software leader can identify and correct those holes before development begins, which saves a ton of time and money (i.e., rework) later.
- A good software leader knows what’s needed. When you’re positive you know what you want to build, you need to hire people or find a firm to build it. How do you know whether you need a large team or a small team? How much should you be paying for this whole thing? Finally (crazy thought!), do you even need to build it, or are there big chunks of it already finished for you in the form of off-the-shelf software or open-source libraries? A software leader answers these questions, saving millions of dollars and massively de-risking the project.
- A good software leader accelerates development. When you’re starting development, you need to put the required processes in place and no more. It’s extremely common to see software teams that move at 1/2 or 1/4 speed simply because process hasn’t been judiciously applied. Design reviews, code reviews, test plans, deployment procedures, progress tracking – all of these things have to be carefully balanced against the main effort of writing code. A software leader has seen this done many times before and will make your team go much faster by picking the right processes.
- A good software leader can read the tea leaves. During development, something feels wrong, but you can’t put your finger on it. Progress seems to be inexplicably slowing. Bugs are becoming more common in the deliverables. And in the end, your intuition was right: the finished product is low quality, over budget, and past due. Before things go wrong, a good software leader can feel this coming and, more importantly, identify the problems and apply an array of solutions.
Please don’t try this at home
If you’re about to make the critical mistake of developing software without a software leader – or have already started down that path – please stop. Hire someone with experience. You’ll spend a little and save a lot – maybe even your business.