Culture is the most foundational aspect of your startup. It ultimately drives the kind of company you will become. It is also one of the most unfixable elements of your company in retrospect; apart from small adjustments. So you need to be explicit and thoughtful about it from the beginning. Having bootstrapped a startup, where we went from 4 to 100 people in 4 years, I can say it with confidence that – you can’t entirely control all of your culture’s evolution but the kind of foundations you lay down seals its fate.
Numerous metrics, empirical frameworks, and examples of what defines thriving culture exist today. Popular principles and manifestos like the Day 1 from Jeff Bezos or Extreme Thoughtful Dissent from Ray Dalio are available freely. It is excellent to read, learn, and be inspired by them, but at the end of the day, culture is contextually unique to your startup. What worked for Jeff or Ray is certainly not going to work for you as-is. Most certainly, as a founder, you are not Jeff or Ray. You are you, and the culture of your startup cannot be defined mimetically by just emulating these ideas and guidelines. The media is excellent at highlighting success stories, and somehow, before you know it, it starts to feel like a recipe. The guidelines and empirical data is not necessarily wrong but what’s bad is you begin to adopt things blindly without questioning if it’s the right thing for you, does it meet your market dynamics, does it fit for your people, does it agree with who you are, and especially why you are doing this. The radical ideas that worked somewhere else can’t be adopted blindly in your context.
So what works? How should one go about thinking about instantiating culture? What worked for me is - looking at the abstract idea of culture from a more concrete dimension. The dimension being: how does culture manifest itself? How do we observe what is the culture at a particular place and judge it? I concluded, it is governed by two main themes:
1.behavioral dynamics - how people feel, behave, interact, disagree, and conclude. 2.style of working - how people analyze, plan, and execute.
These two themes expose a systematic structure. When you think about instantiating a good culture in action, think of it as a continous function trying to optimize for – stable, open, and intellectually stimulating behavioral dynamics and resilient, high-quality, and efficient style of working. The principles you setup should reflect a guideline and optimization structure for the above; thus aiding on your startup’s vision and context.
For example: at FogHorn, we build a real-time analytics & machine learning compiler and runtime. It is used in oil & gas, manufacturing, mining, and health-care industry for predictive maintenance, safety, and operational efficiency. Now, this isn’t a vertical SaaS productivity tool type of company. Our customers take a solution on-premise and expect it to run with little maintenance. “Needs to run forever without a hiccup,” they say. Therefore, using a “move fast and break things” philosophy (even though it sounds cool) is not going to be a good foundation for this type of company. It will set up behavioral dynamics that are opposite to what you need. You also risk hiring the wrong set of people. Its is a simplistic example, but hopefully explains what I mean by understanding your startup’s context.
Another concrete, but a technical example is about the style of working theme. Given our business context, we needed a dominant mindset towards quality from the get-go. Writing a compiler & runtime in C++ is not a trivial task. Not to mention, we had to make it work across four platforms. So, how do you guarantee the quality and sanity without an active QE practice at the early stage? You incorporate the quality mindset as a style of working, and then it becomes your culture. Ok, what does this mean in practice? Traditionally, most developers write unit-tests and mock a bunch of stuff around other functionality, but what we did is take the RAII pattern in C++ to heart. Our unit-tests were almost like end-to-end tests. I will spare you the details, but the TL;DR is: a single 10 line unit-test could literally start the whole platform comprising of multiple real services, drive a test with the real thing, and self destruct cleanly. It gave us absolute confidence that any new code will certainly work when the system is then deployed as six different docker containers, maybe even in a distributed environment. The kind of control, quality guarantees we got from this was boundless, and it became our defacto style of working. It still pays dividends today.
To figure out what your cultural principles need to be, you have to dig deeper into your vision and target market. Culture is truly the heart of your company that no one sees as you do. Some good questions to ask yourself to figure it out are:
1.Why did I start this in the first place? What was the main inspiration?
2.What market are we playing in, and what is the mindset of this market? How do I expect it to evolve?
3.What story do I want the customers to hear about us?
4.If you took each employee into a different room, interviewed them separately about your culture - what is the one common answer you would like everyone to have?
5.What is your ambition of where you want to take this? Be 100% honest about this to yourself, and you don’t even have to tell anyone. Just asking yourself will help.
Assuming above makes sense, and you have some principles written down. Try to re-evaluate them against those two themes. See if it coherently fits. Writing them down is essential, it helps to clarify your own thought. Continuously refine the wording, and repeat it over and over and over again to the team. Over-communicate. Re-visit at-least twice a year.
One other pitfall you could get into is being prescriptive about your culture rather than being descriptive about it. It is a subtle nuance but very important. Prescriptive principles almost dictate doing this and then that which would result in such and such. The issue with this is it leaves practically no room for adaption by your team. People could still follow it but with no heart in it. Descriptive principles don’t dictate a recipe at all. Instead, you describe an end-state, a goal you want to achieve. You specify the characteristics and attributes of that end-state instead of a procedure or rules. This allows people to organically grow methodologies that work for your startup with its unique set of people to achieve that goal. It creates a sense of authenticity and vested interest from everyone that wouldn’t come in if you were just prescriptive. Don’t believe me yet? Watch Steve Jobs’ videos again after having read this passage. You will see how he so descriptive about where he wants to go, rather than prescriptive about how to get there.