Scale and Culture , the ultimate conflict in startups

Ever since I left the big company career , I have been talking to and learning from folks who have a lot of experience in the scrappy startup way of life. I have had such conversation with engineers, founders, sales people, VCs , Angels , receptionists and pretty much anyone else who would talk to me about this . I am rather firmly convinced by now that what worries start ups is the idea of scale – or more precisely, how to scale the business without sacrificing their culture. 

Culture is a loosely defined term for me. It is contextual – some people consider the freedom to work on a pet project as culture, another looks at free beer and food as culture, yet another thinks a primarily engineering skilled work force is the hall mark of culture , some one else looks at a flat hierarchy as the best indication of culture and so on. And this is primarily the reason for the conflict between the need to scale and the urge to defend culture. 

Looking at some iconic new generation companies from the outside – like Google and Facebook, it looks like a lot of the startup culture can be saved. At least the easy ones like informal dress code, free food etc. But a few friends who work there have told me that when it comes to decision making and hierarchy, they tend to shift more to the large company way of doing things. 

I have never founded a company – but from observing people who have done so, it looks to me that the ideal way to do this is for an engineer with a great idea to go find a friend who has business savvy and get a company started. May be it works with the business guy being the starting point too – but to me it does not seem likely that a business person without tech chops can identify a good techie quite as easy as a techie can look for business skills in a partner. I may be wrong – but at least that is how it appears to me. Without a business oriented founder ( pretty cool if business person also is a techie) – I think there will always be a feeling in the company that the sellers who get recruited are a bunch of over paid losers. 

Same is the case for hierarchy . I hate hierarchies with a passion. But it is nearly impossible to manage more than 10 people effectively. So as a company grows, fighting hierarchy is futile – you will just invite chaos. It is a fine balance. When you are small – you can hire enough top notch talent who might not need much management. But there are only so many smart people available on the planet and not all of them are available to your company. So embrace the concept of structure to minimize growing pains. 

There is a certain paradox in engineers fighting hierarchy and structure in organizations. I am a perfect example. I am obsessive compulsive in organizing my code well, ensuring separation of concern , clear hierarchy of a stacks and so on. Yet when it comes to people management – I have fought my bosses tooth and nail on every bit of organizational discipline they had instituted. I can’t say I have fully embraced the idea – but I am a lot more understanding of the need for structure than I was in my younger days. My closest to ideal situation is a flat team that organizes itself to solve a problem, and use hierarchies needed to get things done. And then they go back to the flat team and re organize for next problem to be solved. 

Same deal with performance reviews and comp plans. I like giving and getting feedback at task level and periodically at big picture level. This works well when the organization is relatively small. But when a company grows to hundreds and thousands of people – all those things I don’t like – bell curve type things, come into play. A lot of this misery is caused by lack of flexibility in corporate budgeting. Budgeting is done for predictability – not for performance optimization. And it has extreme side effects that everyone knows but very few CFOs act on. To some extent, tools are to be blamed too. Even if a business wants to be flexible – the common enterprise tools for budgeting and planning have restrictions that minimize flexibility. 

When I left SAP and joined MongoDB – a lot of friends and my mentors told me that once you taste the startup world, there is no turning back to old world. To a large extent, I believe that is indeed true. The flexibility and freedom offered in a smaller and faster growing company is a big plus factor. But what happens when a start up gets too big ? I have seen some of my friends go back to the big company world, and some others just jump to an early stage company and help them grow. A handful who made a lot of money have moved on to be investors. 

I think some cross pollination is necessary in our industry. Even in the 5 months that I have been in this role – I realize how some stuff in my old world can benefit by making changes to how they operate. Similarly the younger companies can get a lot of benefit from people who bring in the perspectives from the big company world – especially about scaling. The latter happens a lot already. But the former – where big companies hire leaders from startup world – don’t happen to the same degree. 

I am very much a newbie to all of this – and am very curious what you think . 




Published by Vijay Vijayasankar

Son/Husband/Dad/Dog Lover/Engineer. Follow me on twitter @vijayasankarv. These blogs are all my personal views - and not in way related to my employer or past employers

One thought on “Scale and Culture , the ultimate conflict in startups

  1. We just said goodbye to a couple of very good interns. My advice to them was to get big company experience before joining a tiny startup. Sure big companies have their inflexibility, but they are also usually a successful business of some sort. There’s a lot of startups with bad culture out there, and nonfunctional parts of their businesses!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: