5 Lessons in 5 Years as CTO of a Start Up

Recently, I completed 5 years of building a category-defining product called Clarisights (technically 4 years of building Clarisights + 1 year on AdWyze - the precursor to Clarisights). The last five years have been a giant collection of bad choices, a sizeable collection of good ones and a small number of great decisions. I have tried to build the tech worthy of such a deeply technical product and a team and culture capable of achieving greatness.

So, here are the top 5 lessons I learnt in the last 5 years that I think most founders and leaders in tech startups should know about  - so that they don’t have to learn them the hard way as I did!

These are also things that all employees in organisations building deeply technical products should expect if the organisations are doing well and growing well:

1. Less is more: For an early-stage startup, this is a big one. Given that most early-stage startups are going to be severely resource-constrained, ruthless prioritisation and limited surface area are needed in every aspect. This applies to the deliverables like projects and features where quality degrades as teams run very thin due to too many parallel projects. This also applies to operational aspects like too many layers of hierarchy and a large number of teams, leading to silos and unnecessary red tape.

Counter-intuitively, this even applies to notions of organisational growth that are pervasive in the industry. Healthy and steady organisational growth is NOT equivalent to the company size growing rapidly. Instead, having a small number of people in any organisation is desirable as long as the key business metrics can grow at a healthy pace without stressing out the employees.

Even seemingly small things like daily sync-ups and catch-up meetings are going to pile up as huge chunks of wasted time.

The biggest mistake I made in the early days was to allow inefficient and unnecessary things to happen, thinking they are needed in the short term and could be corrected later.

Such things collected over time into an almost insurmountable pile of tech and product debt.

Efficiency is probably the most important distinction between successful and unsuccessful organisations. In fact, it should be a core value for any organisation, its constituent teams, as well as for all individuals. And the more (unnecessary) things you do - the more inefficient you become.

2. Empathy and its pillars: In his extremely successful book Sapiens: A Brief History of Humankind, Dr Yuval Noah Harari argues that Sapiens (Human beings) came to dominate the world because it is the only animal that can cooperate flexibly in large numbers. This extremely important trait makes us capable and successful at undertaking large and complex endeavours. For example, a tech startup.

Central to this is empathy: the ability to share another's experiences or feelings by imagining what it would be like to be in another person's situation. You want to build your organisation on the pillars of empathy which come in several different forms...

• Empathy with the customer: Don’t make assumptions on customers’ behalf. Conversely, don’t build what the customers want, only what they need. This requires deeply understanding their problems and use cases, before attempting any product changes.
• Empathy with your team: In an early-stage startup, you want people to strive and make the lives of their teammates easier. This means you don’t want them to hide behind compartmentalised boxes of predefined responsibilities. Instead, everyone should be limited only by their ability to help with a certain problem and not by their role/title. As a leader, empathising with the team means not setting up processes that you have never been through yourself, and putting in proper support measures like pairing people with complementary skill sets, etc.
• Empathy with oneself: It’s an important value that’s often missed in early (or even large) organisations, and is usually the reason behind a stressful work environment. You want to encourage people to empathise with themselves and thus proactively ask for help whenever they are stressed, overworked or stuck.

3. Define your culture and values early on: Ambiguity is often the main value system of an early-stage organisation. But by not defining your values, you aren't being clear about who you want to hire and what you want your culture to look like. Individuals are not going to work well together unless their values align. Thus, it’s important to define the core values for any organisation early on, and get people into the organisation who either possess a large overlap with those values or can constructively evolve those values.

4. Those who cannot do shall preach: Execution >>>> Ideas. It’s as simple as that. While it’s very important to be able to think in abstract terms and generate quality ideas, it’s also fundamentally important to translate ideas into action.

Thus, people who can or have a tendency to only generate ideas without rolling up their sleeves and turning ideas into actions are only going to add to the organisational burden. They do this by creating endless trails of complaints, discussions, meetings, documentations, etc., without contributing to clearing that backlog. Such a burden is an unsustainable inefficiency in an early-stage organisation where resources are scarce, and too many discussions simply lead to thrashing instead of productive output.

5. Titles are just placeholders for ability: Avoid titles and hierarchies for as long as possible. Hierarchy is a necessary evil which is simply unavoidable for large organisations. But, for small organisations, many levels of hierarchy and titles are mere temptations instead of necessities. They can create unrealistic expectations from people, unnecessary compartmentalisation and miscommunication between folks.

This does not mean you should have no titles or hierarchies in the organisation. It simply means that the focus should be to keep them to a minimum.

A very clear example is when we tried to hire architects and principal engineers. We would attract talent more interested in the title itself or interested in the work associated with that title.

After realising this, we quickly switched to a common title called Software Engineer for the whole engineering org to better reflect the expectation that, at this stage, you won’t be boxed into solving just one type of software engineering problem, but contribute to any software engineering challenge that is within the sphere of your abilities.

For more information on Engineering at Clarisights, please enjoy this video:

I hope this has been useful. Best of luck on your journey.

If you would like to work with Ashu and the team, we are hiring!