Srinivasan Rangarajan

Srinivasan Rangarajan

With all the startups I have worked with, I have noticed one mistake that every founder keeps making when they are starting off with the product. Planning for millions of users from day 0.

Founders are too blinded by their ideas, that they believe “if you build this awesome product, they will come.” Even worse, there are founders who think, on the day of launch, users will come out in hordes, signing up and using their product exactly the way they envisioned.

The product manager or the CPO would have outlandish claims of their potential user base and how the product needs to scale from the time they press the launch button. Raise your hands if you have heard someone say something similar to this “There are 2.2 Billion Facebook users and even if we get 1% of that crowd, it is 22 million. We need to handle all those users.”

Developers Love Working on Scaling Problems

We developers love a good challenge and think of all the different possible ways the system can break down – How many concurrent users will sign up, what if the confirmation email blocks the request for another user, what if the users upload GBs of videos, what if they have a unique hierarchical data model, and so on.

When there are numerous possible problems, we do premature optimizations — like spawning off multiple unnecessary microservices, developing a custom framework which is needed just for this project, using a data store which requires atomic clocks to synchronize data, etc.

For a developer, all this is fun and we loves working on these problems. And since the product manager has specs which clearly mentions that we need to handle millions of users, we better be prepared. But what happens on the launch day?

Launch Day

You are not going to get million users on Day 1. Not on Day 100. Maybe even after a year. There is perhaps a 1 in 100000 chance that your product gets viral and you get thousands of users every hour from day 1.

With such low chances, why do you want to waste precious time and resources, building things which are not needed? If you had set realistic estimates of the number of users, your tech team could have built the product maybe in a month. And if you launch early, it allows you to test your hypotheses and iterate much faster.

Your development team would have chosen Rails and MySQL for the product and would have hashed out a basic CRUD app in less than a week. Would it scale to millions of users? Maybe not. But it would get users into your system.

ChangeLog.host isn’t scalable, but works

Let me show an example from my own life. When I built ChangeLog.host, I didn’t worry about scale. I built it using Flask a simple Python web framework, used Postgresql for my DB and hosted it on a free Heroku instance.

I built it because I wanted to use it. It was designed for a single user in mind. It might work for a few thousand users, but I didn’t build it like that.

I built it in 24 hours, did a soft launch to a limited group. How many users did I get? A grand total of 10 users. Will it scale to thousands of users efficiently? No way, but this is a decent enough product that does it’s job.

I deliberately didn’t market it to more than 10 people, as I wanted to see how they use it first. Instead I went out and talked to them, did a bit of cold calling and messaging. I found out what my potential customers wanted and didn’t want. The results and insights I got out of it are worth it.

I would have spent maybe about 40 hours in total on this product, but I learnt quite a lot from that time. I am happy that the product isn’t viable for the market I was looking for and that I learnt it much sooner than later.

Imagine if I had hired a team of UI designer, front-end developer, mobile app developers and spent 3 months building everything and then launched. Even with a conservative estimate, I would have wasted 1440 hours in total. It doesn’t require a PhD to realize it would have been a mega-failure.

TL;DR

Stop building products for millions of users. I understand that not every product can be built for a single user and scaled up. But at least don’t expect millions of users to come knocking on your door when you launch. Build small, iterate fast.

PS: In the future posts, I would be writing how to identify your idea by doing the right customer development, building a MVP, and other such product related posts. Subscribe below to receive them.

Whenever I go out to meetups and conferences, fresh out of college graduates and entry-level engineers always have a few questions to ask me. I try as much as possible to not give them advice that would influence their decisions by my bias.

But, there is always one question that I find is becoming sort of a pattern. “I am about to join company X and I would like to know whether it is a good decision or not.” or “I have offers from Company X and Y. Which should I pick?”

Till a few years back, I used to give very generic advice to these questions. Asking about the products and teams they would be working on and telling them how to decide. But in the past few months, along with the other questions, I have told these young engineers to ask this one question to their team head/hiring manager and the founder of the startup.

What’s your attrition rate?

This one question would give you a fairly good idea of how the startup or the team you are considering to join is performing on a person-to-person level. And how the founders are taking care of their employees.

People in sales and marketing know this saying “It is a lot more expensive to acquire new customers than to retain existing ones.” It is the same for employees too.

As engineers and employees, we see only the salary we get paid from the company. But there are at least 2x costs that the company pays for each employee – in terms of getting people in for interviews, providing an offer, paying the consulting firm for hiring you. And there are numerous other non-monetary things like onboarding to the team, training, making sure there is a right cultural fit, etc.

Retaining old employees and making sure they are happy and content is much easier and simpler than getting 2 new hires to join. And most of the times it is not just paying higher salaries. A lot of employees would be happy with better working conditions, ergonomic chairs/desks, working remotely, etc.

Why did the last person in your team leave?

If a company has a high attrition rate, it means that the employees are unhappy with how the company is being run or they don’t like their team or the products they are working on isn’t challenging enough. And this is where the second question is useful – to identify if there are inherent flaws that the company is failing to recognize and fix.

And based on their answer to these questions, you can ask further follow-up questions like, “What did you do in the last quarter to make sure you retain employees better?” or “How can you reduce it further in the next 1-2 quarters?”

Remember interviews are always a conversation and you have the right to ask these questions as much as they have.

But people always lie in interviews, even interviewers

No one would want to accept that their attrition rate is very high or that employees leave because of bad management. You can’t expect 100% true answers to these questions.

I have seen one manager lie outright saying “Haha! We are very lucky to not have any attrition at all.” When there are idiots who answer like that, you better run in the opposite direction.

Some tricks people use in answering such questions are: “Well, person X is with the company from the beginning/5-6 years. So you see people stick with us for the long run.” But remember, that kind of numbers would most probably be the exception, rather than the rule.

The next question you should ask for that is “And who left the quickest and why?” If the interviewer answers that question, it shows he is open and honest.

It also helps to ask this question to all your interviewers. If they are consistent with their answers, that shows that they are truthful to an extent.

Also, if there are people in the higher ranks who can’t even give you a number when you ask their attrition rate, it shows how transparent the startup really is and how committed they are to measuring things so they can improve.

It is not always Black and White

Just because a company losses 2 employees every month, it doesn’t become a bad choice. Nor does a company which has many employees celebrating 5 or 6 year anniversaries, make it a great choice.

So should you skip a company which has double-digit attrition rates? Depends. Your decision to join or skip a company should be based on multiple factors and this is also one such factor.

But based on anecdotal samples, I have realized that there is a high degree of correlation between a company which can retain its employees to how successful it can become.

It has been more than a year since I posted here and it is already the end of 2018. So how was my year 2018? This is not a detailed overview of the year like others write. But more like a short blog post of what happened in the past 1 year and what I am going to do next.

Quit working as full-time employee

Professionally, a lot changed. I quit my job early in the year and joined another company, and quit that too in a few months. But, why?

I have mostly worked with early-stage startups. I have always loved working on products which are in it’s infancy, where there is a certain uncertainty in what needs to be built. The challenges in building new features for a product are slightly different and interesting than maintaining an existing product and making sure nothing breaks.

When I realized that my contributions to the team wouldn’t match my skill set, I decided to quit. I am happy that I quit at the right moment – before I became too involved with the team.

I am currently back to consulting to startups, helping them to build MVPs and products. And I am not going to just consult for other companies. I have also decided to build my own product(s).

Built ChangeLog.host

ChangeLog.Host

One such product that I built was ChangeLog.host – a site where you can write your product’s changelogs/release notes. This is useful for product managers who want to keep their users updated about the newest features and bug fixes in the products.

I started building it as part of a 24 hours online hackathon challenge and I did complete the basic MVP level of features in 24 hours. But instead of continued development in a vacuum, I talked to potential customers.

I asked them why they would use such a service and why they wouldn’t use it. And what features are important for them to consider using this. I still am in the process of talking to others and understanding the users. Depending upon the conversations, I would either continue with the development or maybe start building other products.

I also want to release some MicroProducts – smaller products that are useful to a select few people. My goal in building such products is to not worry about the technical stuff, but rather concentrate on the marketing, growth, and sales side of running a business. I will make sure to blog about these “experiments”.

Personal Stuff

On the personal side, I was able to experiment with the Keto diet and was successful in reducing some weight (almost 10%). But I didn’t stick to it and ended up going back to my old weight. At least I found that it does work best and maybe I would try to stick to it more regularly in the next year.

2019?

I don’t want to write specific goals for the coming year. But this is going to be the overall theme.

Building Products and MicroProducts (and this means not just software).

Concentrate on the non-technical side of a business and blog about my experiments.

Consulting for other startups on the side.

Spend more time with my kid (now that I am working remotely, I have the luxury).

Whenever I meet people in conferences or meetups, I experiment with how I introduce myself. Every time I talk about myself and what I do, I make subtle changes and notice what reaction the other person gave.

This isn’t something I did in the initial stages of my career. When I started (as a programmer) I just told I am a software engineer or programmer in a startup. And I noticed that people will just start saying “Oh, OK. Cool. What does the startup do?” Then the conversation ends up being about the startup and I just missed the opportunity to make an impact on a stranger.

After my failed startup, I started consulting for other companies. And this was a stage when I used to attend a lot of meetups every weekend. And this is also the time when I began experimenting with my introductions.

Freelancer

Initially, I was saying “Hi I am Srini, I am a freelancer” or some variation of that. That was the most horrible thing I could say about myself. People kept saying “Uh? Ok. So you write code and stuff uh? What kind of code?”

Programmers doing Freelancing has this weird association with a code monkey who doesn’t know how to think. I kept hearing people who have this small task that they want help with and they were confused when I started asking deep probing questions about their product.

I didn’t communicate well enough that I am more of a product guy and I can help them end-to-end in researching, prototyping, building, and launching their product. Not just write a particular module and get paid.

Software Consultant

I started saying that I am a Consultant and this was slightly better. People began asking me help with different parts of their software and how I could help them. I was no longer a freelancer. However, there were still a few people who didn’t know what consulting was and their first question was “so consultant, like a freelancer?”

I had to resist the urge to not facepalm and reply back with how I was a bit different than just a coder they could hire on Elance.

I used to say that I work with startups and program stuff. But so does every other fresh programmer out of college. How was I different?

Solutions Architect

This was the stage when I promoted myself to be a Solutions/Software Architect (hey I was my own boss). This sounded cool and people started noticing me. Mostly because I spoke with confidence and authority, but partly because I called myself as an Architect.

Even this was missing something. I realised that nobody cared about the title. Yes, it did sound cool, but only before the kids. They see someone older claiming to be an architect, they will listen to every word you say.

My target audience were people higher up in startups. Guys who take the decision whether to hire me or not. For them, it doesn’t matter what I called myself. All they care about is how I am going to solve their problem.

Solve a problem

My introductions became something like this “I am Srini, I am a software/solutions consultant/architect and I help startups build products”. This clearly explains what I do and how I can immediately solve a problem for startups (my target audience). The responses were totally different.

Whenever I used this introduction, people used to start asking “Hmm, interesting. What kind of products do you build?” and “What startups have you worked with before?”.

I stopped being that code monkey or some weirdo who calls himself funkier titles. I began to be that person who can provide a solution to their tech product. And the conversation started and eventually, I would become their trusted advisor when it comes to building their product.

Even now, after becoming a full-time employee, I always test out my introductions. I explain what I do and what I have done in the company and so on. And since I am representing the company in such conferences and meetups, I test a lot of variants introducing the company too. In tomorrow’s post, I will explain how to explain what your company does.

I want to know how you introduce yourself. Please leave them in the comments below.

All these 4 dysfunctions eventually lead to the final dysfunction, the inattention to results. When a team is doesn’t trust themselves and are afraid to have an argument, it leads to non-committal decisions being taken leading to no accountability at all and each team member works towards his own personal results instead of the team’s results.

Any team should set the goals and objectives they want to achieve. But if there is no accountability, the members would start working towards their personal goals or their own team’s goals.

Team level goals

Say the overall company’s goals are to have 100 paying customers by end of year, each team needs to commit to it. If let’s say the sales team thinks it is a huge target, they would start working on accounts which are smaller, but easier to close.

Getting 100 clients who are ready to pay a few tens of thousands is different from getting 100 clients who pay hundred thousands of dollars. The first might be easy, but it doesn’t add any significant increase to the top line.

Personal Goals

If the intra-team goals aren’t achievable, then individual members would start working towards their personal goal. With the sales team example, each sales person would start getting clients who yield the highest commissions. This kind of behaviour is detrimental to the growth of the team and the company.

How to overcome this dysfunction

The simplest way to overcome this dysfunction is to publicly declare the results that they need to be achieve. Public proclamations in a team setting tend to allow the team to work passionately towards the goal.

Another way is to announce results based rewards. Link the compensation of the team member based on the results he achieved. But make sure that the goals are clearly mentioned and tracked. Have an objective way to track the goals and the results achieved.

Conclusion

Whatever I have written in these 5 posts are just a very brief gist of the book. Be sure to read the book and really understand with the story and examples of how to save your team from these dysfunctions.

When a team doesn’t trust the members and hide their weaknesses and mistakes, it would lead to the fear of Conflict. The members wouldn’t want to argue and have a healthy discussion. This would lead to a lack of commitment from each member. There will be a few team members who wouldn’t buy-in to the team decision. This leads to the fourth dysfunction – Avoidance of Accountability.

Even if a single team member doesn’t agree with the team’s decision and doesn’t want to commit, he would feel like he isn’t involved in the process. If anything screws up he would just claim “I didn’t agree to this at all. Don’t ask me.” or “I aired my opinion on this before itself, I knew it would fail.” This kind of behaviour ends up hurting the team.

Each team member needs to understand that everyone in the team is involved in the decision and is held accountable for anything that might happen. The members need to own the decision and the product/company. They need to hold each other to a higher standard and constantly drive each other to perform better to reach the end goal.

Whenever one team member shrugs off his responsibilities, the others need to point it out and make him realise that his behaviour is causing failure in the quality of work others do. The team needs to self-regulate each other.

How to identify your team has this dysfunction

It is easy to identify this as each member would wash off their hands on any difficult situation. They become a mediocre team and have a lower standard for performance. This causes deadlines to be missed and ends up with missing all the goals.

How to overcome this dysfunction

There are easy ways to overcome this dysfunction. Whenever there is a group meeting to decide something, make sure you listen to everyone’s arguments and accept their point of view. At the end of the meeting, once everyone has committed to the decisions, make a clear list of goals and standards that was decided. List them out on a paper and email it to everyone in the team.

It is up to the team leader to translate these goals to clear objectives for his subordinates. By making sure everything is recorded accurately, it would avoid any kind of ambiguity.

There should be simple and regular progress reviews. Team members should be given constant feedback on how they are performing regularly. List down the stated goals and objectives and mark against them how each team member is performing.

Finally, the team leader or CEO needs to bring about this culture of accountability by creating a disciplined environment. Whenever a team member does something against the standards set, make sure others point it out. If no one speaks it out the team leader needs to speak out.

By having this kind of culture, the team eventually learns to keep everyone at a higher standard and hold each other accountable for all the decisions that they take.

This week I am writing about the book Five Dysfunctions of a Team which is about a fictional company whose executive team is highly dysfunctional and how the new CEO brings them all together to create a better company. Last two days were about the first two dysfunctions: Absence of Trust and Fear of Conflict.

I was explaining how when the team members don’t trust each other to not use their mistakes and weaknesses against each other, they will be afraid to argue and have open conflicts. When the team is afraid of facing conflicts, there won’t be a clear commitment from each team members.

Any decision that needs to be taken will have few members who don’t publicly air their opinion. This discontentment would lead to the entire team leaving the meeting without reaching a consensus.

To get a commitment from all the team members, two things are needed

Clarity

Buy-in

Great teams always leave a meeting with a clarity of the decision that was taken and also with the knowledge that every member had the buy-in. No single team member is harbouring doubts and disbeliefs about the decisions.

Note that there is no need for a consensus or certainty in reaching a commitment. No team can get both. There will always be one or two team members who will not completely believe in the decision, but the team needs to give a valid space to air their concerns. The team also needs to accept the concerns and move forward taking into account each person’s views.

Also, no one can be certain that the decision you take today will be the best decision. Things always change, the business landscape might cause a different outcome. Competition might get better funding. But you have gotta take a decision “today” with all the possible information available as of now. You can’t keep pushing away and not reach a commitment.

How to overcome this dysfunction

There are very specific steps to overcome this dysfunction. One of the important steps every team needs to do is to reach a decision with a deadline. They have to decide by when they need to commit and stick to it.

And once everyone buys into the decision, they need to cascade the information down to the next levels. If the executive team decides that they are going increase number of customers by 100, this information needs to percolate down to the next levels. Each employee in sales, marketing, tech needs to understand the goal and start working towards it.

Always think about contingency and worst-case scenarios for each decision. This would help mitigate the risk and fear of failure. And instead of doing time-consuming research and studies, start discussing with each other with as little research as possible. Only during the discussion among the team members, various viewpoints will be exposed and it will lead to a better decision.

Tomorrow we will see how not having a fully committed team would lead to our fourth dysfunction – lack of accountability.

In yesterday’s post, I was explaining about the latest book that I was finished reading: Five Dysfunctions of a team and the first dysfunction – the absence of trust. If you didn’t read it, go read yesterday’s post and come back.

Continuing from where I left, when a team doesn’t trust each other, it would lead to the second dysfunction – Fear of Conflict. Any good relationship if it needs to last over time and grow continuously, needs to have conflicts. Whether it is a marriage, friends, business or in a team there need to be open conflicts.

But people try to avoid conflict, especially at work as it is many times considered negative and unproductive. Petty interpersonal politics is different from productive ideological conflicts.

The goal of having a conflict and teams intensely and passionately arguing is to produce the best possible solution for the problem. Many times having an open argument about the problems and issues at hand lead to resolving them quickly and completely. And since the team members know that there is nothing personal about the conflict, they don’t hurt each other’s feelings.

Only when the team members do not openly debate or argue on important ideas/decisions, it turns to back-channel gossip and personal attacks. This kind of behaviour is more toxic than having a healthy argument in the first place.

So how do you overcome this dysfunction?

The team members have to first understand that conflict is productive and healthy. Each member should be able to air their honest opinion about any issue and others must learn to listen to their opinions openly.

Once the first dysfunction (Absence of trust) is removed, each team member would realise that any opinion they hear is not a personal attack, but instead about the actual issue they are discussing.

When people start trusting each other that they won’t use their mistakes and weaknesses, they will have better arguments and openness in their conflicts.

Often times the arguments become heated and might become messy, but as long as the members understand the true goal of the argument, they will come to a good resolution.

How this causes the third dysfunction

Only when a team has a good and healthy argument about the decisions it takes, each member would begin asking about other’s perspectives and opinions. Unless everyone’s opinions are heard and discussed, it would be difficult to get a buy-in from the entire team. Which leads to our third dysfunction: Lack of Commitment. Wait for tomorrow’s post to learn about this dysfunction.

Five Dysfunctions of a Team is a book I started reading recently and I think is one book that everyone who is working together with a team needs to read. This book describes the many pitfalls that almost all teams in the world face.

It starts out with a story about a fictional tech company in Silicon Valley and a new CEO comes in and finds how the executive team is highly dysfunctional. She takes them to a retreat and explains them about the 5 dysfunctions and works with them over the next few months to get the team to function together.

When you read the stories you would feel like you could relate to each character in the book with someone you would’ve worked with or currently working with. But the author clarifies that he sees the similar pattern in any company or team that he has worked with. He explains how to fix the five dysfunctions and make the team work together towards the common goal.

Five Dysfunctions

Absence of trust

Fear of conflict

Lack of commitment

Avoidance of accountability

Inattention to results

Each of the dysfunction will build up to the next level and cause a totally dysfunctional team which is full of ego, politics and selfish people.

A team which doesn’t have any trust in themselves, would not have any conflicts. Team members would be afraid to air their conflicting views during meetings and would not have 100% commitment towards any decisions taken. And since there is no commitment, there is a lack of accountability.

The Team members will just say, “I knew it was going to fail.” and pass the blame on others. And this causes each team member to work only for himself and his group and wouldn’t care much about the whole team or organization’s growth.

This is how each dysfunction causes a major rift in the teams and end up causing irreparable damage to the organization. In this post and the next 4 posts, I will be talking in detail about the 5 dysfunctions and how you (as a team leader) should help your team overcome it.

Absence of trust

This is the first dysfunction – absence of trust among team members. Which is caused by their unwillingness to be vulnerable within the group. Only if the team members are genuinely open with each other about their weaknesses and mistakes can build the trust.

This is called vulnerability-based trust, which is completely different from the other “I trust him to finish his work by this week” kind of trust. Only when the team has this kind of trust, they will feel comfortable around one another. Else they will have their shields up always on the defence.

If all your time and energy is spent trying to protect yourself from your team members, you can never focus on your job. Only when you stop worrying about your weaknesses and trust that your team won’t use them against you, you will be able to start concentrating on your strengths and use them for your team.

Also, they will hesitate to ask/provide help and feedback to others. They even doubt the intention of others who try to help them and fail to recognize other’s skills and experiences.

When there is trust

When the team has trust, they will openly admit their weaknesses and mistakes and help each other in solving their problems. Always gives the benefit of doubt before reaching a negative conclusion. Apologize for any screwups without any hesitation and don’t have any ego.

But most importantly they focus all their time and energy on solving important issues instead of petty office politics.

Building vulnerability based trust

This kind of trust is very hard to build, as we have been trained from an early age to be competitive to be a successful person. Also, it is our natural instincts to not open up to everyone and protect ourselves in such a competitive space.

The team leader needs to conduct various exercises to help each team member to open up to each other. Each team member needs to start by sharing something personal about themselves. This shows everyone that there is just another human behind one another and builds empathy with each other.

The second exercise is for the team to identify one important contribution of each team member and one area they need to improve upon. Yes, this exercise is a bit dangerous as it might cause some tension, but the feedback needs to be taken constructively.

The third exercise is to use a personality profiling tool like Myers-Briggs Type Indicator to identify each team member’s personality types. And the most riskier exercise is to start giving 360-degree feedback about one another. But there is a slight difference between usual 360-degree feedbacks. You should not tie this to any kind of compensation or performance evaluation. You should try to use this as a developmental tool to identify the strengths and weaknesses.

With all these exercises the leader can build a team which trusts each other.

In tomorrow’s post, I will explain about the second dysfunction – Fear of conflict and how a team which doesn’t trust each other fears to have open conflicts.