Why tech operations are as important for startups as the product development

Why can non-technical founders fail their tech startup?

Because technology is more complicated than someone without a good technical background could imagine. They are -in many cases- astonished by some complexities that some components of their product could have. They hustle hard to make successful decisions and establish the long and short-term plan for their success, but on the other hand, they become paranoid about their technical teams... A crisis of trust is the beginning of the end, especially in small teams!

With the help of product managers and business developers, they are the people who shape the product and have the most important fingerprint on the outcome.

They may be more aware of features than any important technical detail related to the same features.

"We are going to create real-time analytics dashboards because our client X wants this feature! These guys are awesome (read: they have $$$). If we could get this the next month, we can deploy the same solution to our important customers. We build a "Customer-Centric" product (read: we want more $$$)!"

In the meantime, business developers and sales may find new clients, who can pay (more) for new features .. the tech team should follow in all cases.

Unbearable features

The good thing about successful entrepreneurs is that they work smartly: Do less to generate more.

But since non-technical founders cannot be aware of some technical details, most of the time, the "do less to generate more revenue" negatively impacts the technical teams. We are unable to estimate the technical capacity of a software engineering team, if we don't have an excellent technical background: things are as simple as this statement.

With the above scenario being repeated along the year, software engineers find themselves developing the minimum they can do.. While developing an MVP is the best idea to start a startup, it doesn't apply when a startup reaches a certain stage.

- "We need real-time analytics dashboards; within two weeks, it should be deployed to our live systems because our client X wants this feature!"

- "Have you said 'real-time', 'dashboard', 'deployed', and 'two weeks'?"

Every term used in the last example, imply that everyone in the technical team from front and backend developers, architects, and operation engineers is prepared to accomplish that.

Software Engineering is not coding.

It is about:

• learning
• design and conception
• benchmarks and technical choices
• creation and maintenance of development/testing environments
• and a lot of awesome but sometimes painful things!

Nowadays, it seems that the first goal of many startups is getting ahead faster and faster.

This why a developer ends up coding without testing; an ops engineer ends up deploying without automating or scripting the deployment without thinking about a rollback strategy…

Is everyone in your technical team really prepared to make your startup more prosperous? Ask this question every time you want something to be done. Making a good turnover seems to be easier than making your team happily productive.

"Yeah, we need 'agile' development, faster' time to market', and an 'iterative approach' over a working 'prototype'."

For many people, features mean development, and feature makers are programmers/developers.

Dear non-technical founder, some features should be conceived, with good specifications, planned, designed from software and an infrastructure point of view, it could have dependencies, prerequisites, several technical considerations, some technologies that could be tested or benchmarked and probably then it could be developed.

After development, it should be unit-tested and deployed to the QA environment where regression, smoke, functional, load .. etc. tests should take place at this stage; the product move then to staging and production environments.

What's good in creating new features to destabilize old ones?

Regression: Sometimes, developing a new feature, adding a new functionality could alter the behavior of your old application components and features.

Sure, there are better ways to accelerate all of this and create an iterative approach over tasks like testing, deploying .. etc. but this requires a pipeline, automation, a vision, a strategy, and some of your engineers' time.

Your automation pipeline should be developed and needs some time in all cases… The time that you don't have, in most cases. I don't think that a non-tech founder could have a clear definition of containers' orchestration, for instance. I think that most of the interest of a non-technical person working on technical projects goes to development since it's about the product .. they may know some words they saw on their Twitter timeline. "Javascript", for instance, since it's widely used in tech startups nowadays, but do they really know everything? I'm not sure .. until they're trapped.

While methodologies and philosophies like Agile, DevOps are adopted within some startups, I've seen a lot of other startups (mostly with non-technical founders) using the waterfall model .. and in a bad way!

I noticed that being a non-technical founders helps a lot in ramping up sales, establishing good marketing plans, and having a strategic vision… A non-technical founder will delegate all of the technical work and try to compensate for his modest technical skills by doing a better job in other fields…

This is common, to the point where, sometimes, business developers, marketing, and sale guys are overstaffed.

This post doesn't explain that non-technical founders couldn't build successful tech-startups .. We simply mean that they should work more on shaping their technical skills. The same applies to technical founders who aren't used for marketing and selling their products.. but in my opinion, developing non-technical skills seems to be easier. There are many successful startups founded by non-technical founders, but the most successful companies were founded by technical guys: Google, Facebook…

When you're in a startup, the first ten people working on your project will somehow determine the destiny of your vision. If you are not a technical founder, make sure to make good decisions in recruitment.. and please don't hire a technical co-founder for the only reason to build your product for free.

Dev and Ops in the early stage

Generally, entrepreneurs are not afraid of failure but rather of not supporting success. A successful entrepreneur has experienced failure(s) at least once, but success may not come frequently.

Success means usually more development, more clients, and more features, but at the same time, it means more technical operations .. with a growing development team, your startup needs more operations and DevOps practitioners.

Iterating over the adoption of DevOps in an early stage plays an important part in your success as a non-technical founder.