Vikrum Nijjar: Engineer #1 at Firebase and Founder of Gold Fig Labs (YC S19)
blog.ycombinator.com> standing in as SRE for 24×7 hour shifts… for over a year.
1. Should that be 7x24 since it is followed by hour?
2. Hero worship is toxic. It like the ultra thin models used for advertising. This just perpetuates unhealthy attitudes toward work.
Edit: changed phrasing of 1
Agreed, this is not just disturbing but embarrassing. Really, they couldn't hire an SRE to cover like, half a shift, enough to sleep? 24x7 shifts for over a year? So you're cofounding a company, making horrible and unsustainable decisions as a leader to the point that you're probably sabotaging it and someone is giving you the platform to by proxy advise others to do the same?
How is someone supposed to come to a conclusion that such companies are successful in spite of and not because of such environments? What a backwards way to build an organization.
In the extremely early days of a startup one doesn't have much optionality. With only three people at the company it really did not make any sense to hire a full time SRE for a pre PMF startup. I'm glad we made those trade offs back in 2011-2012 so that Firebase could be here today to be backed by a dedicated Google SRE team.
Don't mince words. In the extremely early days of YOUR startup, YOU didn't FEEL like you had much optionality. That is in no way universal. You very much do have optionality. You can quantify how much it costs to hire someone part time or full-time. You can quantify the risks of burning yourself out, or your manager can. Your firm had the optionality, you just chose to go in a very specific direction.
What I'm saying is that your firm survived in spite of, not because of this frankly amateurish decision.
Obviously nobody can take away your contributions towards making Firebase successful. I think many people may not realize the kind of fanaticism that it takes to get a startup off the ground, considering the odds are stacked against you.
I am curious though, how well did you sleep that year?
Agreed^2. Grab a highly qualified, talented person in India or Australia (or wherever is +12ish) from TopTal: solve the [first level] overnight issue, use them and onshore talent to drive the process of improving security and documentation while saving $$$, moving to supporting a global talent pool and improving the life of an offshore worker. Seems like a no-brainer to me (as long as the costs incurred are recaptured as benefits to the system/organization). Why would you tire and distract a _core_ contributor?
You cannot often outsource such things in a startup's early years. Things change fast, and a remote worker - does not matter how qualified - who is hired only for a specific purpose, especially something like SRE, might not have enough insight or context to fix things when they go wrong. It's fine to be idealistic and say that everything should be documented, communicated over email/Slack/hangouts whatever - but that does not work in practice when you are just focused on getting the product out, and dealing with multiple fires at the same time.
First of all, your words are saying outsource, not mine. I'm saying hire for. I'm saying specialize for, divide labor into. If you hire talented folks and understand how to divide labor properly (which you'll need to ever execute properly), you can do this from the get-go. I did this at my last seed-stage startup and I would have done it the same way every time.
People like talking about how things like this are idealistic, but what's more idealistic? Saying that you should hire the minimum amount of people to do the entire workload without taxing the finite biological constraints of the human body, or that you can't afford to do that and that somehow you will be the special person who can transcend your biological constraints without catastrophic failures?
If you ask me, the latter is what sounds idealistic. That's my criticism of this post.
>>First of all, your words are saying outsource, not mine
Maybe you have a different definition of outsource, then. For me, outsourcing is not necessarily sending work to a cheaper worker.
>>If you hire talented folks and understand how to divide labor properly Sure, but I don't think this is about division of labour. It's about communication, the small talk, all the things you have to hold in your head and cannot communicate because there's too many of it, and it's changing constantly.
I've worked in startups where it was thought possible to bring together a random group of people and get work done, and it failed miserably. I've also worked in startups where we did not do it, and went ahead to be successful. These are subjective experiences, but after almost two decades in software, I can humbly say I can see the patterns.
>>Saying that you should hire the minimum amount of people to do the entire workload without taxing the finite biological constraints of the human body
You should hire if you can, but it may not always work out if the person is remote and the role demands a lot of face to face interaction.
Thank you.
These kinds of people have little life outside of work and few interests outside of tech.
There are those of us who seek careers in tech but do not want to go home and think about tech or even read much about it in their off-time.
My first 5 years on the job, I lived and breathed the subject matter - was kind of required since I didn’t study it in school, but to be honest, I have no memory of a social life or hobbies during that time and it kind of skipped past me like a poorly scratched CD... I just missed out on LIFE.
> Hero worship is toxic. It like the ultra thin models used for advertising. This just perpetuates unhealthy attitudes toward work.
I now default to assuming that people with a lot of voluntary unpaid overtime have a personality disorder. Effectivity/productivity is an orthogonal axis.
Will copy the office hours on Friday! I love the focus on fixing tooling and enabling others.
Checking out Gold Fig Labs now :).
Some of things that caught my eye:
> We also knew Scala would help us attract good candidates, which it did.
Paul Graham wrote abt how one must beat the averages to be successful in a high risk world of startups [0].
> James and Andrew [the co-founders of Firebase] really treated me like a peer. At no point did I feel like Firebase was not mine.
Sam Altman has repeatedly said that culture is important and the way great companies are built is by making the first 10 or 40 employees feel like they are a part of the founding team.
> James and Andrew [the co-founders of Firebase] really treated me like a peer. At no point did I feel like Firebase was not mine.
This is super nice! Steve Huffman once said adding chat on the frontpage drastically changed hipmunk's understanding of the users of the site as the support was one-click away and they could act on user's frustration the very minute they were inconvenienced.
> At one point, we had a tweet posted on our wall, “Please marry me, Firebase!”
As Paul Buchheit would say, in the early days of the startup, make things a 100 people would love than things that a 1000 might like. u/rahulvohra had a great piece echoing similar sentiment abt HCX (high expectations customer) and how Superhuman found PMF by focusing on a smaller segment of their most demanding user base [1].
> Our highest order bit was to hire kind people. Obviously we wanted people with the right skills and ability to communicate...even on the toughest days, we still took time to take lunch together, walk around SoMa, and enjoyed every step along the journey.
Sam Altman repeatedly stresses on importance of hiring based on shared values and aptitude rather than a skill set in the early days of a startup. I guess, successful YC (?) companies all fit a similar pattern.
> The company was actually working on chat APIs, and then realized that their real-time infrastructure was more useful than the chat tools themselves. We pivoted to Firebase a few months after demo day.
This is one of the right ways to pivot. My favourite pivot story is of a startup that failed to raise money on demo-day, went back to work, tried hard but couldn't make it work, spoke to more users, realised they needed to build something complementary to what they were currently building, they built that and flew past $1 billion in evaluation in 2yrs after another pivot [4]. Like Michael Sibel says, if you've found a burning problem a set of users need solving, don't change the users or the problem in search of PMF, change the solution.
> Extremely high-concentrated messaging, like Kevin Hale telling us to focus on the one thing that’s important to our company right now.
Focusing on one to three things to do really improves velocity and helps with momentum, keeps everyone motivated to build. Breaking milestones into small one or three tasks that can be accomplished every week, you'd find that so much work gets done and importantly the momentum keeps of having done things keeps you moving forward. This hack is something that startupschool drills into you. Also see, producer vs consumer [2].
> And Gustav telling us, “You should launch this thing and you should be embarrassed.”
This has all kinds of nuances and caveats. For instance, Emmett Shear talks abt how if you're in the business of backing-up data (say, dropbox), you mustn't launch something that loses customer data as that would be fatal. So, you might need to get creative: Dropbox's MVP (or Minimumal Remarkable Product as Emmett calls it) was really a landing page with a video describing how Dropbox would work and its benefits to the end users with a sign-up form to get early access. They only launched when they were sure the product did backups really well.
> And we really didn’t know what was possible in us until we had people pushing us, people who wanted us to be as great as they thought we could be.
I met a YC alum recently and they said YC really changes your perspective on what's possible. That they were asked to think in terms of what'd your goals for the company and product be if you had unlimited capital. And it really changed how they ran the company even though they didn't have the capital at the time.
> ...at some point we were concerned that what we were building was too niche... We thought maybe it might be just DevOps managers or the security teams. Turns out, just about every developer has been in that situation.
And that's a huge market. A lot of disruptive tech starts out looking like a toy/niche [3].
Congratulations, Vikrum. All the best.
---
[0] http://www.paulgraham.com/avg.html
[1] https://firstround.com/review/how-superhuman-built-an-engine...
[2] https://news.ycombinator.com/item?id=3555581
[3] https://news.ycombinator.com/item?id=21315942
[4] https://www.youtube-nocookie.com/embed/L325PVEvm7Q?t=20m50s