Building a team or a company gives one a chance to make a lot of decisions at various stages. If you are lucky, some of them will be two-way doors, but most of them are one-way doors. Here are a few I can think of that I had to decide or think about at some point in the past (10+ years).
Speed vs Quality ‘Culture’
When I wrote the heading, I was mostly thinking about software development. But the path one takes ends up expanding in all other teams/departments as well. While the immature assumption is we need the speed at the early stages of the product and we can focus on the quality later, things never go down this way. There is never a clear distinction between what is the early stage of product development where speed is needed and what is the later stage of product development where quality is needed. https://patrickcollison.com/fast is a set of projects that might inspire you to move fast. I’m not sure if all of them had high quality though.
One anti-pattern when it comes to speed vs quality is probably the Apple iPhone releases. There is an expectation to release something new every year and every innovation (not sure if we still have any new though) must be tested thoroughly before it gets in our hands. Hardware is very unforgiving with bugs. Intel learned this lesson the hard way.
Team vs Family ‘Culture’
This is another difference in how one can build a team. And again, different successful companies have been created focusing on the team & family. A clear example of we are just a professional team is Netflix.
Here is an excerpt from https://jobs.netflix.com/culture
We model ourselves on being a professional sports team, not a family. A family is about unconditional love. A dream team is about pushing yourself to be the best possible teammate, caring intensely about your team, and knowing that you may not be on the team forever. Dream teams are about performance, not seniority or tenure.
Family is the other end of this spectrum. Salesforce is the best example of this. Here is an excerpt from https://www.salesforce.com/blog/what-is-salesforce-ohana/
In Hawaiian culture, Ohana represents the idea that families — blood-related, adopted, or intentional — are bound together, and that family members are responsible for one another. When he created Salesforce in 1999, he made sure that “Ohana” was in the company’s foundations.
This is probably the most confusing one to pick, since both the options are equally good ones.
Spaces vs Tabs
Being a developer, I need to write this. But this is probably something I should add. This probably is the meta for all the technical decisions which I can never change now. The choice of cloud (AWS vs GCP vs Aure). The database choice and programming language & framework choice feel like a two-way street at the start, but after a few years, the company is married to those decisions.
Of course, many other bigger decisions feel like one-way, but it is not impossible to change them later. For example name, branding, founders, and legal structure all feel like one-way decisions. But we’ve made changes in every one of them.
We initially called the company Interviewstreet and then changed it to HackerRank. We started as 4 co-founders, but only two (me & Vivek) ended up starting this eventually. We started the company in India but finally reorganized the company structure once the US entity was formed.
These are the three one-way decisions I could think of based on the past. I don’t know the right answer for any of them even today. Wonder how many more one-way vs two-decisions lay in the path ahead.