hckrnws

The only way to win is not to scale. Most of the problems discussed by PG and in this post revolve around scaling company culture, and the associated management style, as the company grows the number of employees. Unfortunately, my feeling is that there really is no great solution to communication problems after a company scales to 20, or 50, or 200 (choose your favorite) people. Modern tools are helping more and more (GDocs, calendars, meeting transcription, ...), but after you get past 15-25 people, you go from everyone knowing everything to something less good. There's no reason that companies "need to scale". You can make millions of dollars without scaling up, and you can avoid many of the problems that kill companies at the same time -- investment overhang, cultural changes, management challenges, and the need to expand your customer base.

> There's no reason that companies "need to scale".

That just seems silly to me. There are fundamentally lots of problems that require the labor of hundreds or thousands of people. You're not building a jet airplane with a team of 25, nor an advanced computer chip, nor, in AirBnB's case, a global peer-to-peer booking platform.

I'm sympathetic to the idea that many companies grow prematurely, or that they grow "just for growth's sake", but I don't like thinking that an answer to a problem is to just pretend it doesn't exist.

There may be projects that require more people, but there are many that do not. Why must all companies grow?

I agree that startups need to be very careful with adding people -- and that most are not. For whatever it's worth, at Oxide we have long past the scale where everyone knows everything (currently ~75 employees); there is no doubt turbulence ahead as we grow with respect to employees, but I do think that some of our cultural idiosyncrasies (e.g. writing-intensive, recording every meeting)[0] have helped/will be helpful in this regard.

[0] https://oxide-and-friends.transistor.fm/episodes/cultural-id...

Thanks for the link! Basically all of "Demo Fridays, morning water-cooler, no-meet Wednesdays, recorded meetings, dog-pile debugging (aka CSPAN for debugging), RFDs (requests for discussion), no performance review process..." sound like music to my ears

What's the benefit to continued employee growth?

We definitely have needed (and will continue to need) to add new job functions as we scale as a company -- but we are very circumspect about it!

> There's no reason that companies "need to scale".

Scale tends to bring increased revenue/profits. Starting a business is a massive risk of both time and capital typically. If there isn't the potential to win a big reward, we would have far less innovation happening. Most companies need to attempt to scale to justify the risks.

If you want to risk your time and money without the potential for a big reward, thats great. Start a business, make it successful, and start pumping the brakes as you see fit. However, if you do this just be aware that competitors who are willing to scale may come and eat your lunch.

You can scale revenue without growing the number of employees. That's precisely why product-based businesses, like SaaS and software in general, are famous. Service-based businesses require scaling employees in order to scale revenue. In fact, if you keep employee growth in check, each employee makes even more money. Further, if you split profits, rather than forcing your employees to wait for the mythical IPO, they can use some of that money much earlier than if you grow employees, take on more investment, generate a huge overhang, give your employees low "startup" salaries, and then get aquahired with common equity getting zero return. In practice, it is far easier to get big payoffs for your employees if you keep the employee count small and aim for an early exit.

This might be the misuse that Graham warns us about when he said "as soon as the concept of founder mode becomes established...". Sure, let's turn a complex subject into some formulaic process of applying superficial lessons from one small experiment relating to documentation and "trust". That's super easy. Is there a for dummies book?

I actually had the exact opposite reaction.

I loved this article particularly because it gave specific, practical, targeted advice on how to really address what pg was talking about. Of course it's possible to reduce this to a "for dummies" implementation (We just need to write everything down and all our problems are solved!) but it seems pretty obvious, especially given Bryan Cantrill's reputation and influence, that this is not what he's arguing.

While I liked pg's post, the thing I found frustrating about it was precisely its lack of specificity. And, ironically, it's that lack of specificity that makes other actors (both well-intentioned and not) likely to "misuse" and/or redefine "founder mode" to be whatever they want it to mean.

Cantrill's reputation isn't relevant here. It is what it is, and there are no big-scale Apples's or AirBnb's in it. A decent technologist, I'd say. His advice is "almost" specific, and not in the least way actionable without the bits that are left out. One cannot teach charisma, or leadership at that level. The exceptional founder, doing whatever voodoo they do, can convince others to follow him, or her, up the hill, with discipline, succeed, and not get everyone killed. That isn't a science; it's not an art; it's a gift. That's why they're special, and why it can't be reduced to a set of mechanical rules. This post was "five easy pieces for founder mode".