Comment by solatic | Hacker News Reader

Comment by solatic | Hacker News Reader

> When someone new joins the company, they do what everyone else does: go into our Notion queue, pick a task, and get to work, asking for clarification when needed... Instead of setting quarterly goals or using OKRs, we move towards a single north star: maximizing how much money creators earn. It’s simple and measurable, allowing anyone in the company to do the math on how much a feature or bug-fix might be worth.

Quite frankly, this doesn't seem sustainable. There's only so much high-visibility/high-value work. When your headcount is large relative to "desirable" work, people will compete for the "desirable" work. They will lie about the 60 hours of work they did last week, and tell you that it's the culturally-normative 20 hours of work, because it makes them look like 3x engineers.

> expecting responses within 24 hours... we can compete–and win–on flexibility

Including in SRE / ops roles, where people need to be on-call?

Let's be clear about something here. You have a headcount of 25, and ostensibly nobody is full-time. It's certainly possible to avoid internal competition at that size, with the right culture. But can you really avoid adding headcount? Can you really protect your culture from the opportunists, the cutthroats, the workaholics? How large can the kibbutz grow before the workers' paradise is no longer so sunny?

Does it have to be "sustainable"? It wouldn't work for Google, but it works for Gumroad (and, like they said, most open source projects). Gumroad is a pretty simple site (and I don't mean that as an insult). They don't deal with huge customers, sales processes, large data, complicated tech, etc. Most "hard" things can be outsourced to a SaaS tool.

So why overcomplicate things?

Premature optimization is the root of all evil

You say that, but the other side of this argument is having to rebuild every. Single. Part. Of a program because nothing was designed with forethought and scalability in mind.

Great code is both simple and has the ability to scale if needed in the future.

Sure. A lack of premature optimization does not imply a lack of consideration.

Then by that note, premature optimization doesn’t imply excess complexity nor effort. So we have gone in a complete circle and conveyed nothing.

Pretty sure that doesn't logically scan.

If it doesn't imply excess complexity nor effort, it's not premature to optimize it. Why write the inefficient algorithm when you remember the efficient one, and it's no more effort?

But if an optimization will imply excess complexity or effort, and you aren't sure it's needed, it's premature. Worrying about load when you have 3 users is almost assuredly premature. Not to say you shouldn't ask yourself when building "what happens if I get a bunch of users, and are there easy decisions that barely cost me any effort now, but which will allow this to scale easier later, such as writing things with minimal shared state, etc etc", but once you have optimization design/implementation choices that are going to noticeably delay launch...it's premature to select them.

"Premature optimization is the root of all evil" is a thought-terminating cliché and a tautology - if it's premature, it was done too early.

When people discuss the phrase, the conversation degenerates into random proclamations about when one should worry about things, proclamations that immediately break when applied to specific situations.

Premature optimization is extremely subjective. You can’t actually make any decisions based on it because the data you need to know if it’s premature is in the future.

Conversely we know you can’t make an unscalable design scalable after the fact. You may be able to do micro optimizations of hotspots or fix the egregiously bad parts but you’ve painted yourself into a corner.

The good news is that most scalable architectures are simpler and better in most other facets of the design so it’s largely a false dichotomy.

Yep; the quote was originally about in line optimizations, like profiling to avoid cache misses and tightening inner loops and such. Nowadays, with your main concern being service throughput, the bigger concern is your architecture, not your implementation.

Which is where the confusion is, possibly. Architectures you can't easily undo; that loop or choice of data structure you can. So it's generally worth giving careful consideration towards your architecture (it's not premature to ask "What happens when this one thing becomes two?")); it's generally not worth giving the thought towards your implementation.

A lot of garbage systems make a lot of people a lot of money.

> Does it have to be "sustainable"?

Well, yes. Sustainability doesn't only mean "in the face of expected large growth", it means (for example), here's a culture that the company likes, can that culture continue to thrive through the coming years?

Yeah, you can be sustainable at 10% YoY growth at a lot less pressure than 20% YoY growth v

I actually really like the anti overtime policy (half your hourly rate after 20h / week)

I suspect that scares off workaholics.

It's definitely sustainable if they don't plan to grow, and frankly it might still be sustainable at much larger sizes

> I actually really like the anti overtime policy (half your hourly rate after 20h / week)... I suspect that scares off workaholics.

I suspect that anti-overtime policy, at scale, is somewhat like a salaried position. When you earn a salary, your salary is guaranteed regardless of how many hours that you put in. Why work more than 40 hours a week? But in the real world, gains and promotion often go to people who "bleed" for the company. If salaried positions, which offer zero overtime pay, end up promoting overwork, why would offering a partial reward of half-pay factor in at all into whether the company has an overwork culture problem or not (particularly if reporting hours is the responsibility of the employee and the employee can simply decide not to report the overtime hours)?

I suspect setting the bar at 20h sends a reasonably strong signal.

Even if people do overwork, they should only do it with that as a baseline, which should keep anyone from 80 hour workweeks far away (why would I work there for 80h/week when Netflix would pay me 2-4x for that much work?)

You might see people working 40h/week but I'm not seeing why that is bad for the company or culture.

I think you're pushing at "there will be people who really want a pay raise and they will work long hours to get it" but I honestly just don't see that happening. It only happens if it's rewarded, and they've set up what seems to be a strong culture that motivates people to not work too much.

It seems like their current culture consists of people who don't want to be defined by their work. The post notes this explicitly.

If the employees will overwork, I suspect it will be on their side projects, and more power to them

I still think it's a worthwhile effort to try to scale if their path, vision, dictates it. Ultimately I see such bad actors trying to integrate themselves into the system - to game the system - to be simply increasing waste or inefficiency. So while such behaviours may be slowing growth of the system, so long as there aren't unmovable blocks introduced, and everyone's mostly aligned to leading metrics - then it should be fine; potential blocks include things like unions, which is why I'm still juggling thoughts and reasoning as to whether unions are good or not - likely industry wide they are. A failsafe in this scenario is contract workers can all be let go easily - minus the domain and systems expertise they have - and you'd need the main controller, visionary/founder, to be paying full attention and make course corrections when necessary, hopefully finding trusted co-captains along the way that are passionate with the work more for than financial gain.

What would you say if the answer to your questions were yes, yes, and large enough?

Why isn't there enough high-value work? One of their organizing principles seems to be that it's okay to do something that seems fun or that creators are asking for, so why should that stop being a guide for people who enjoy the work they do and enjoy listening to customers?

> What would you say if the answer to your questions were yes, yes, and large enough?

Then their model isn't replicable as a "better way of working" in general. Most companies with 50+ headcount aren't going to suddenly slash their headcounts down to 25 so that they can assert the cultural benefits that can be achieved with a small workforce and clear messaging that exponential growth is neither expected nor desired. If their model isn't replicable, then it doesn't have as much to teach us.

Companies aren’t motivated to replicate it, rather.

I would agree though that if a lesson is repeatedly refused, the pedagogy must change.

Well most other work places are not workers paradise or sunny at all. So they are clearly doing better than most.

Reply on news.ycombinator.com