The term "Open Startup" is not new, but still fairly niche. There are Open Startups with millions in revenue, yet only a tiny percentage of Startups today fall into the category.
However, with the recent movement of "Building in Public" and the growth of COSS (Commercial Open Source Software Companies) it has become more and more popular. Before we dive into the details, let’s first go over some fundamentals:
What is an Open Startup?
@dinkydani wrote a great piece on HackerNoon about Open Startups dating back 3 years, referring to Open Startups as
“a transparency and openness movement seemingly initiated by Buffer, quickly adopted by Ghost, capitalized by Baremetrics, and recently popularised in the Indie Maker community by Pieter Levels"
While there is no formal definition of what qualifies as an Open Startup, which metrics are required, or to which extends a startup needs to publish its KPIs, the common idea is: Any Startup that shares its metrics as open as technically and operationally possible is an Open Startup.
The vast majority of startups, such as Cal.com, run their Open Startup page under the page /open. Enter cal.com/open.
Not every Open Startup is a COSS startup and being a COSS startup does not necessarily make you an Open Startup, however, the nature and values of Open Source make it much easier to build a culture of openness, transparency, and thereby trust.
Why should I care?
Frankly speaking, Open Startups have a tough time screwing you over. Almost everything they do is public.
Investors see how a company performs.
Employees always see what’s going on internally.
Customers see how active the development cycles are and how their precious monthly subscription is being spent on.
As a founder, you’re not only building a product. You’re building an organization and its culture. If you believe code should be open and transparent, why stop there?
Lastly, when building a product in public that requires an active and engaged community, sharing the milestones can help you recruit true fans who’re actively interested in the growth of the project.
For some, it’s like rooting for a favorite sports club to win and get better!
Open Salaries
Some Open Startups even go as far as opening up their salaries, leading to an even more transparent organization that can help attract better talent that values such openness.
Open Salaries also help mitigate nepotism, abuse of executive power, and overall leads to higher fairness when structuring salary bands.
How we do it at Cal.com
From the very first days of the project, we’ve actively built out our /open page. I believe it was the third page we’ve built internally, but haven’t publicly announced its existence before today.
It was clear to us that the teams section will be the most important one because that’s the foundation of every organization.
Salaries and hourly rates for freelancers are opt-in, which means if a team member doesn’t feel comfortable being public with this sensitive information (often for very good reason), they’re never forced to publish it.
Contrarian to most advice out there, the reception inside of the team has been insanely positive. Transparency reduces jealousy, increases fairness, and promotes racial and gender equality.
The other metrics include: weekly active usage, weekly bookings, new customers of our hosted plan, merged Pull-Requests (aka "how much code is being published"), monthly burn (expenses after revenue), GitHub Stars and much more to come!
Global Salaries
This topic is the most controversial and most challenging one. There is no clear winner between global salaries (every person of the same seniority and title gets paid the same, regardless of location) or localized salaries (every person has an individual salary based on their location)
We’ve thought about this a lot internally and came to the conclusion to go with global salaries, even though fully remote organizations like Gitlab have been working successfully with localized salaries in the past.
Here’s why:
We believe your compensation at any organization should be based purely on meritocracy and what you bring to the table. No manager should know, nor care about your living standards and personal lifestyle.
Our company was born on the web and lives on the web. Our team is fully distributed and works online. We have no physical headquarter and don’t plan to have one. We’re all citizens of the web and thereby equal.
Don’t let people tell you otherwise, but your compensation will always be transactional. And the fairest transaction is money for work.
If the work is of equal quality, it is only fair to pay equal dinero.
We don’t care if you wrote the line of code in Costa Rica, Sweden or Portugal.
Work = Money.
The future of work is async and nomadic-compatible:
The entire organisation runs asynchronous and both founders of the company are “digital nomads" (short nomads) who work from various different countries.
We very much believe this is becoming a more and more common trend and only global salaries are truly compatible for this.
Another strong argument against localized salaries is actually the lack of enforceability.
Let’s say you’re currently in the Bay Area but plan to move to Europe. Do you tell your manager? Does the manager stalk you and bring this up internally? How do your team members feel when they find out you’re making 4x their salary, even though you’re neighbors now?
Not only mentioning how hard it actually is to come up with a fair localized salary function:
Let’s say we take a regional multiplier and come up with a base salary. Does the multiplier factor in the person’s rent? The avg. cost of living in that region? Where do you get that data from? Does it update monthly? Yearly? What if the person lives at home with their parents? What means "cost of living" anyway? Does it include children? Mortgages? Student debt? ..?
Gun to the head, I wouldn't know how to write this function ad hoc.
To summarise, we believe localized salaries are unfair, hard to calculate, and almost impossible to enforce without hiring a private detective to snoop upon your employees (not cool).
How
Like most startups, we’re differentiating our team members into levels of seniority and titles:
IC Level 1 (Junior)
IC Level 2 (Mid)
IC Level 3 (Senior)
We’re using the contract templates from Deel which also helps with transparency and standardizing salaries.
You may read this and wonder how the f*ck should a junior engineer from the Bay Area be able to pay rent with only $60,000? Yep. That’s one of the downsides of global salaries: keeping out people from highly privileged regions.
Our line of thinking is: As a company that’s looking to build the best team, we much rather hire the most talented person from a region of lower costs than a below-average player at twice the rate from a highly competitive job market.
Many tech workers may not like this, but remote work will only accelerate the rate of commoditization of knowledge work.
Furthermore, we believe as an organization with a mission of connecting 1 billion people by 2031, we can have even more positive impact on the world by slightly overpaying some lower-cost regions than losing the competition in job markets that are already predominantly won by big-tech salaries and perks. You may win a Bay Area engineer with an astronomous salary, but you likely won't be able to keep them for long.
We’re looking to connect and empower billions of people in every corner of the world and global salaries will help us achieve this even more.
Now, that being said, we haven't drunken from the fountain of wisdom and can’t predict how the future will play out. We may change this policy in the months to come but for now, this just feels like the most right decision when comparing the pros and cons.
Additionally, we may make decisions on personal negotiations with employees, i.e. bonus payments or individual perks (i.e. supporting your family or staffing a therapist) if required.
If the same seniority has a different salary, we'll be leaving a note to the team explaining why this exception has been made (i.e. acquisitions, acqui-hires or poached executives), though it hasn’t happened yet.
I’m sold, what tools do you use?
We use:
PostgreSQL to store our data
Jitsu.com to track telemetry and anonymized events
Metabase.com to run queries and show the graphs
Stripe.com to collect money
Orbit.love for community analytics
AskGit.com to receive GitHub analytics
Airtable.com to store static information
SyncInc.so to sync our Airtable (and soon Stripe) into a dedicated PostgreSQL which connects to Metabase
Are you planning to add more metrics?
Yes! Our cal.com/open page is an ongoing project that is very close to my heart.
My personal life goal is to be as transparent and honest as technically and operationally possible, while also trying to keep the setup- and maintenance time as small as possible.
For example, we’re planning to show our Stripe data in Metabase but it’s a real PITA to get it done correctly and we have fires of higher priority to put out first.
Everything revenue, retention, churn is likely launching before December 2021! Pinky promise.
As a nomad myself, Pieter ‘@levelsio’ Levels of Nomadlist, has been a great inspiration
The team behind Buffer which has been pushing for transparency for years
Joseph Jacks from OSSC for supporting us in this push and for being a true evangelist of Open Source
Patrick DeVivo for setting us up with a free AskGit.com account and helping us get our GitHub data visualized
Thank you for reading and trusting in our mission.
It is an honor to serve every one of you and we’re keen to hear what you think. If you plan to work at an Open Startup and get a taste of its culture, we’re hiring!
Explore the differences between self-hosted and SaaS (Software as a Service) scheduling platforms to help you determine which option best fits your needs.
