Hacker News new | past | comments | ask | show | jobs | submit login
Efficiency is the enemy? (2021) (fs.blog)
178 points by ivanvas on May 6, 2022 | hide | past | favorite | 70 comments



Oh, hello, queue theory and parallel processing theory! As you increase utilization (remove slack), throughput may grow, but latency grows more. If your nodes interact and depend on each other, the tail latency can grow completely out of hand, in exchange to tiny gains in utilization, and the actual throughput may go down as utilization goes up past some point.

Always have some free disk space. Do not run your web servers at 100% CPU utilization. Overprovision your clusters. Add redundant network links. These ideas look completely obvious, don't they?

Now apply them at the org level. Always have someone with spare cycles. Leave some time at the end of the sprint when all planned tickets are done. Allocate time during the day to sit and think, or to experiment, or to take a walk. Let the person oncall to mostly sit around and watch the system operate instead of churning out something. Now this sounds a little bit crazy, doesn't it. So much efficiency is left on the table!

(Also, certain Nassim Taleb used to be popular around here; he wrote a whole book, "Antifragile", based on these ideas.)


Not crazy at all. Just smart thinking combined with a good understanding of how the world actually works. You want to automate things as much as possible so that people have time to observe, think, and improve things. For example, a manager who is always 100% busy, working 80 hour weeks, is a bad manager. One step away from a heart attack or a major team/system failure.


Nassim Taleb also has a lot of stuff that goes against this kind of thing. The core of antifragile is that you should position yourself to gain from disorder rather than fight it. I kind of hate the whole thing, because while you do occasionally get some great innovation that way, he really undervalues the army of "Fragilistas" that take those innovations and make them reliable and practical.

I think he'd probably be against "Max efficiency" thinking, but "Max effectiveness" thinking is still not the same as "Minimum major trouble". He's a bit too "Move fast and break things", which is kind of like max efficiency, if you define efficiency as "How much business growth can I pack in ten years".

I've always thought that things should be planned with "Time firebreaks", that are absolutely excluded from all ahead of time planning whatsoever, with the intent of cleaning up any unexpected trouble you run into. Not quite a break time, those are planned ahead and known to be necessary.


This seems pertinent to me, and is a quite old concept.

Jacques Ellul, for example, posited that our "technical system" aims at efficiency to the point of engulfing everything, in a detrimental way because (composed with physic laws) it leads to betting on economy of scale (gigantism, centralization, specialization...).

Stephen Jay Gould "criticized the belief that evolution comes up with the best, or only, solution to a biological problem", and that organisms are always working towards fitness.


re: org level. This is especially true for anyone on call (pager duty).

Leaving a bit in the tank every day increases ability to respond to sudden emergencies more intelligently and with less burnout afterwards.


The article's central illustration actually contradicts the claimed point. In the illustration, the secretary, Gloria, has slack, but the purpose her slack serves is not to enable change, which is basically what the article claims slack is for. Gloria's slack is just to make sure that Tony, the CEO, doesn't have any slack: he's working all the time on whatever he thinks is highest priority, and never takes a break. And Gloria is not using her slack to think about ways to reinvent the organization to make it better. In other words, this central example is actually not an example of the benefits of slack: it's an example of efficiency--Tony works at peak efficiency and has no slack. So if Tony is doing good things as a CEO, the conclusion should be that efficiency is good, not that slack is good. Paying a secretary to have plenty of slack to support Tony is just part of the most efficient way for Tony to operate.

A much better example of the benefits of slack would be a CEO who delegates the day to day work to subordinates (which includes "making decisions", the thing the article says Tony's main job is), to give himself slack--more time to think about big picture things and consider ways to change the organization to make it better.


I think the challenge here is that efficiency is always relative to the position the observer is measuring it from.

In the case of Gloria, she should have some amount of slack to figure out how to do the big picture items of her job better, which include how better to help Tony.

Where things get tricky is when looking at the whole organization there's been a long tendency to see "slack" as "fat" that's to be trimmed. So, if a organization has two Glorias who both have some slack time, the argument is the organization would be more efficient and profitable having one Gloria with less or no slack time.

This has worked for corporate profits, but it leads to the humans in these positions unable to have the slack time needed to improve those positions.

Sometimes, this is fine and you can build a very profitable business off of it. For example, McDonald's isn't looking for their frontline staff to do any thinking.

In general, if a position can exist and doesn't need "slack" time, it is probably a position that should be automated as soon as it's cost effective.

If you really need a human to do it though, you should stop trying to treat it like machine and realize the importance of slack time and build it in to the schedule.


> For example, McDonald's isn't looking for their frontline staff to do any thinking.

They tend to punish it. I say that I learned from fast food: how to mop a floor, how to remove burnt coffee, and the value of an education/career.

I think because they work with a lot of teenagers, they tend to get away with belittling people and getting because you’re two back-talks from fired, and you’re not sophisticated enough yet for the subtle burn they can’t write you up for.

“Give a man a little power” was never more clear to me. They have their little empire of dirt and they are going to defend it.

The biggest asshole had a brother who was a pro baseball player. As if what your brother does makes you important (my own brother hated that idea). Congratulations, you sell burgers all day. Your parents must be proud.

The best of them had a mild case of impostor syndrome he tried to cover. Told too many dad jokes, but still top 3 for managers in a clutch situation. I hope he did something with himself besides ace school field trips dropping in on us unannounced.


I don't think Tony necessarily has to be working at full efficiency for this. Say Tony is taking a break when he gets a text from support, "Big Client X is really unhappy, looking for your help on this". He texts Gloria, "grab me previous interactions with X". Maybe he needs financial info that Gloria doesn't have a record of. "Dan, Tony needs to know Y, send me the info?". A chain like this could easily form a graph of tens of people, and will require back-and-forth.

You could imagine a scenario where everyone at the company is taking a break when X has their issue, and that's the best case scenario. Instead of everyone off doing their own thing, they're slacking off but ready to help. The combined context switching in an extreme case like this could be hours or days.


It always reminds me of a fire brigade or an army. You want the firefighters to have lots of slack so that they will be available when there is a fire. On the other hand, having people sitting around "being ready" is costly and there is some optimum amount you need.


The timescale makes a huge difference here. Firefighters need to be next to their equipment to respond to an emergency. US army reservists “One Weekend a Month, Two Weeks a Year” is understating things, but they can hold down a full time job when not called up.


What I meant was that both professions are good examples of "slack-full" professions. They can still be considered to be doing their job well even if they're not actively fighting (either fires or the enemy). If they're consistently inactive they may get a reduction in numbers, but I've never seen anyone seriously suggest to abolish the fire brigades.


It's both - an example of how slack in one system (Gloria) enables higher efficiency in another (Tony) and surmisably higher overall output.


Correct. Individual slack (available capacity, aka not running 100% efficient) enables and allows for organizational efficiency, higher output, and agility (the ability to respond to things).

Just like running 100% lean (just in time efficiency) reduces overall resilience when snags occur. Having SOME slack (available capacity) allows for agility when things go awry.



> A much better example of the benefits of slack would be a CEO who delegates the day to day work ... to give himself slack -- more time to think about big picture things and consider ways to change the organization to make it better.

That's not slack. As you just pointed out, that's his regular job. Slack is unscheduled time, not time that's devoted to performing your duties. The point of slack, anywhere, is that it lets you respond to situations that arise, by converting the unscheduled time into time in which you respond. If you're fully scheduled, that's difficult to do.


> Slack is unscheduled time, not time that's devoted to performing your duties.

Time that the CEO can spend thinking about big picture things and considering ways to change the organization to make it better is "unscheduled time". That's the point.


That time is often easy to reschedule. But it's not unscheduled time; if it gets reallocated to other tasks, company performance will suffer because important work isn't being done. It's not slack.

We can easily state this another way. Slack is unused capacity to do work. The CEO planning his strategy is work, the opposite of slack.


If the roles are both equally necessary, why does the CEO make so much more than the secretary?

The CEOs entire enterprise is due to others. If anything explicitly highlighting that undermines the myth they’re the experts.

Both of your models rely on the CEO delegating to focus on the right state change for the business, so I’m not sure why you create two scenarios with squishy ideas of a CEO being efficient or slacking. Some CEOs have casual demeanors, others addiction to Adderall energy; neither is slacking if that’s just the vibe they need to “make it better.”

You seem to be circling the core meme it’s the CEOs job to improve the company and wrapping it up in subjective modals for doing so. Not sure how this refutes the article.


> If the roles are both equally necessary, why does the CEO make so much more than the secretary?

Most jobs don't set salary based on the necessity of having someone in that role, it's usually based on how difficult it is to find a capable person in that role.

If there are 100k people capable of doing the job of the secretary, and 5k people capable of doing the job of the CEO, then the CEO will be able to negotiate a higher pay rate.


CEO’s routinely run businesses into the ground. So the question is if the hiring process for CEO’s is actually working as intended.


Right, the old supply and demand; a heavily accepted model drilled into us.

It’s not the only viable one to the species.

Given automation and first hand experience building analytics systems for VCs and investors; they’re not that much more capable. They’re humans at the same edge of knowledge as any grad of a decent university, of which there are millions.

Teaching “stay in your lane” tacitly props up apathy and disbelief in the proles.


Ultimately, pursuit of perfect efficiency results in crystalline systems which are fragile.

Slack is the ur-antifragility.

(efficiency pursued for itself is AN enemy)


Fragility & simply the deadening of exploration. Assuming you know what you are doing & only ever intend to do exactly that, better, is the ultimate horse blinders for humanity, preventing all other options than "go forwards".

Slack is time & permission to consider, reflecr, grow, enables finding new ways to thrive.


That's because the risk of fragility is typically not priced in.

If risks werent treated as an externality this failure mode would be taken care of. Of course some unanticipated failure modes would always come and surprise us. I would be one happy person if the failures we see around us were all of this 'inconceivable' variety. Very few are, except when one buries one head in the sand and refuses to consider the fairly obvious risks.


The "risk of fragility" is bankruptcy, or death if we're talking about a biological organism.

For example, the financial entity that makes tons of money speculating in a worthless asset, then goes belly up when its worthlessness is exposed (I won't name the asset(s) to avoid a flame war).

You can't "price that in." You just avoid it.


One sure can, by engineering a more robust system. This will cost you some though. One can buy insurance, one can make tail hedges. The right mix of mitigation strategies depends on the nature of the threat.

Avoiding it falls in the same spectrum. It is equivalent to assigning an infinite cost to the risk .


Yep. It also usually means no time to find better long term ways to do things. Everything is sacrificed on the alter of “efficiency” (basically cost cutting).


See also https://thezvi.wordpress.com/2017/09/30/slack/ , which makes the point that slack and efficiency are not opposites: "Slack prevents desperation. You can avoid bad trades and wait for better spots. You can be efficient."


Efficiency by what measure?

I like this piece. It speaks to an efficiency measure very often overlooked!

The way I see this is everything comes with costs and risks. Good systems manage those.

But they are not entirely eliminated.

And that's the game! Running full capacity is more expensive than some reduced capacity, and what that number is depends on what an organization has incoming.

Low latency responses to high priority events very seriously reduces overall costs. Having some degree of capacity to deal with it makes a ton of sense.

Invariably, someone else sees that as an unused resource.

The argument will be made that Gloria could actually be doing a lot and simply drop it when Tony ends up needing stuff.

And while true, task switches are not free, nor is basic human readiness. For Tony, he values knowing Gloria has command of the details and has good processes she has likely used idle time to conceive.

For Gloria, jumping into action is expected and normal. She is not haggard into a crappy state every day.

Efficiency has different measures.

I have seen similar in manufacturing where any capacity left unused seems like money left on the table. But the truth is people are often employing ideas to make their jobs easier, bring quality up, and the like.

Sometimes parts need rework. Stuff happens. Doing that may well be transparent to others given there is some capacity to get the rework done.


Efficiency sounds so nice, but ever since working on a safety based project and observing

1) Efficiency hates redundancy

2) Redundancy is, like, the easiest, most zero-thought way of adding robustness

I've been a little suspicious of efficiency.

And we see questionable efficiency optimizations all over -- here in an individual business, in the greater economy (Let's over-specialize our economies, it is more efficient. Let's JIT manufacture everything, buffers cost warehouse space).

Just add redundancy. It'll be twice as expensive but it won't explode if something goes wrong.


If robustness is what's important to you, then your challenge is to do that efficiently.

For example, maybe you can use something like the Reed–Solomon error correction, which allows you to balance between no redundancy and full duplication, both in cost and benefit.

https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_cor...


I guess like optimizing for throughtput != optimizing for latency


The real enemy is optimizing for utilization which people think is the same as optimizing for throughput. Anti-slack is exactly this error.

Optimizing for latency will often improve system throughput, and maximum throughput almost never shows 100% utilization.



Probably because that's pretty much the introductory chapter(s) (been a few years since I read it, but the topic comes up very early). Running everything at full capacity even when they can't do meaningful work for the sake of "efficiency" is a great way to accomplish a lot of wasted effort. It can go in several directions:

1. You have a lot of wasted work. You're making 100 widgets/hour that the next station can only consume at 20/hour. Inventory piles up and what happens when that work product is no longer needed or expires (if it can expire)? Now you've spent more (on the inputs to production) and have spent money you can't recover in full.

2. You cut to the quick. You look at that previous situation and say, "Let's sell 4 of the 5 machines, we only need 20/hour so why are able to make 100?". Turns out that the extra capacity helped you deal with maintenance downtime, tool changing, quality control issues (low quality parts, which should itself be addressed anyways), or meet customer needs for spare parts (infrequent, but large orders like at one former employer of mine).

(2) is what happens when a lot of people learn of JIT but don't comprehend JIT (or Lean). They don't understand, by analogy, that cutting your arm off to lose a few pounds is probably not the best idea out there.

My prior employer learned this, they cut out the travel and finance teams (about 8-10 people in total) and moved all that load onto the engineers who traveled, individually, infrequently but as a group very often (1500 of us). Problem: They did it infrequently, with a crappy web app. You went on a trip that lasted 1 day? It took you 4-8 hours in advance to set up everything, and 4-8 hours after to put in your vouchers. So a single day trip could take 3 days of total time. And for the first time someone used the system, or if they had anything unusual in their voucher, it could take days (worst I saw was a week of 3-5 hours a day spent on their voucher dealing with the back and forth on getting it approved and amending the voucher). They brought back the "idle" travel and finance teams, and, huh, suddenly we weren't wasting so much time on it. They were experts in the system and could get those complex vouchers done in a couple hours, and the simple ones in minutes.


Isn't the example in your last paragraph more about specialization than cutting out slack?

It seems to me like they misunderstood the value stream. The specialized added value by reducing the average administrative overhead of the engineers, which enabled the engineers to focus more on where they add the most value to the system. Not unlike the secretary and CEO in the article.


It's both, their specialization provided slack (both to themselves and the engineers). And yeah, the value stream was grossly misunderstood, and the work was undervalued.

Because of their specialization they were fast with broken systems (they used the same crappy web apps as us, but they understood them). Because they were not engineers and they got the work done fast, there was no perceived value in their role (classism and other biases at play here), it was thought (bad assumption) that the engineers could do it just as well themselves. And since the engineers had more than enough slack anyways, they could lose 15-30 minutes before and after a trip to dealing with the paperwork.

And if that assumption had been correct, maybe it would have been the right call. But the assumption was incorrect, and it was a very stupid call. We didn't charge the customers for that overhead, so any time the engineer spent on it (hours, sometimes days) was revenue lost. The dedicated team cost much less than the lost revenue so it was overall a net loss.


I really dislike blogs/articles/publications that don't have a publication date prominently placed for the reader. This, at least according to the wayback machine, is from at least October 31st, 2021 -- Although I seem to remember reading it before this date.

It really does the reader a disservice by not giving them the temporal context in which the words were written.


Related to the concept of efficiency / slack is the concept of a Moral Maze (from Robert Jackall) [1] or Immoral Maze (the same thing but renamed for clarity) [2].

[1] https://www.amazon.com/dp/0199729883

[2] https://www.lesswrong.com/posts/zpA2Tnp2k38qSmr8J/how-to-ide...


I'm not sure how Moral Mazes relates to this topic, can you explain the links to me a little bit more?


One aspect of a Moral Maze is that it systematically removes slack:

> A world without slack is not a place one wants to be. Mazes systematically erase all slack. Slack is evidence of not being fully committed, and given that everyone’s skills are equal and competition is perfect, holding anything back means losing even if undetected. [1]

And an article by Zvi on the specific concept [2].

My take, and my experience, says that a lot of what makes a moral maze is an organization where professional managers engage in a large-scale effort to ensure that blame or negative consequences flow past them. So you advance by building a maze around yourself so that negative results miss you and you grab credit for positive results that have to flow through you.

When people "on the line" do good work, you can leech off of that. And as long as your organization does good work you can do fine. But if your organization becomes marginal or if you're trying to outcompete other middle managers, you have to find a way to pass that downstream. As a generic "manager" you can't add value on the line, but it's very easy to blame lack of results on lack of efficiency (too much slack) so that's what gets sacrificed.

[1] https://thezvi.wordpress.com/2020/01/12/how-to-identify-an-i...

[2] https://thezvi.wordpress.com/2017/09/30/slack/


I wonder if this could be summarized as something like:

Efficiency is only useful until it imposes on some degree of slack, or spare resource, which allows you to respond to aberrations which (inherently fragile) efficient systems can't accommodate very well (Although you could argue that an efficient system would accommodate systemic aberrations well, but then I wonder if it would be a semantic argument).

Sort of like with finances. You could optimize your spending and investing as though economics are totally determinate, but they aren't, so you keep some cash as slack to accommodate cases where the shit hits the fan.

When working on a project, you could schedule your time down to the wire and work as hard/smart as possible to hit the deadline perfectly, but it's not going to work out well every time (or often at all in software). So you figure alright, it seems like something that should take 3 days, I'll bank on 5. If you come in over or under, it works out well for everyone. There is not point in trying to max out on efficiency in these cases.

In determinate environments where things really do work exactly as you'd expect, well, it's a different story. But human beings aren't that.


Excellent rationalist restatement of the central Mystery of the Church of the SubGenius


Slack is great for resiliency, but it obviously can't be unbounded. The CEO in the article can't have 100 secretaries just in case. One of the great things about approaches like linear programming (programming in the sense of industrial engineering and not CS) is that it helps quantify how much that slack is worth. It can then be put into context of whether the risk tradeoff is worth the extra slack.


In a world where CEO time is apparently worth like 300X worker time, how many secretaries is the right number? I guess it is however many it takes to keep the CEO completely saturated with work...


That's exactly what my GP was commenting on. Instead of using heuristics like "however many it takes the CEO completely saturated with work" or assuming the CEO worth is 300x the secretary, you can quantify it. As soon as the value of the additional slack (organizational value or risk balance) is outpaced by the slack cost (secretary salary), you know you've added too much slack.


Assuming salary maps to value add, let's say if the CEO is worth 300x the secretary, he needs 300 secretaries.


I'm not sure if this comment was meant tongue-in-cheek, but wouldn't this assume the administrative overhead scales on a linear 1:1 ratio with the CEO's value? If a engineer's value is 2x another's, it doesn't necessarily mean the former uses, say, 2x the electricity/copier machine/office space. But maybe that was your point and I'm being dense.


I was more making the point that CEO salaries are crazy and unjustifiable, to be honest.


The author is confusing efficiency with utilization.


Yeah I see the criticisms of efficiency brought up alot lately it’s click bait. Efficiency is always good. efficiency is the percent of time I spend on the hobby(practicing piano) rather than shuffling books around or making my space comfortable. Not maximizing the hours of my day spent “productively”.


It's interesting that if labor units were replaced with money, the concept would be intuitively obvious to everybody: Having a certain amount of money that isn't earmarked for anything is practically the Singularity of personal finance.


Personally, I've never been a fan of "the measured life."

Pro athletes and ultra-high performers use these types of metrics to maximize their "potential," but it seems to come at the cost of burnout, injury, and things like mental health and family issues.

I get a pretty significant amount of stuff done, and pretty well, but I could care less about measuring it.

I don't compete with anyone; especially with myself.

When crunch time comes, I roll up my sleeves, and get downright obsessive, but I also do things like take "side trip projects" (for example, breaking out UI widgets into open-source packages).

I get done what needs doing. I learn a lot, and I keep myself relatively healthy.


Almost all pro/ultra high performers end up with broken bodies. Constantly pushing your body to the limit is not healthy. Being fit is not the same as being healthy. I highly recommend reading “Body by Science”. It’s a bit of an eye opener.


An organization either has few members and cannot tackle a huge task at a fair pace, or enjoys "unproductive" members, with no measurable output.

Some of them acts as very useful "information providers", they know who knows and "productive" members ask questions to them, and at best some are able to provide useful information even before being asked to do so.

Without them the amount of resources wasted by information vectors (service notes, meetings, mail, chat...) grows proportionally to the size of the organization.


The more efficient your system is, the more fragile it is. Just look at global trade and how quickly it fell apart because of Covid. A more down to earth example is being “efficient” going on a trip, leaving last second to get to the airport, and then ending up missing the plane because of an unexpected problem happening on the way. The book “The Goal” (introducing TOC) is a good read to understand the problems with focusing on “efficiency” instead of the goal you are trying to achieve.


This is the best business-related article I remember reading ever. It focuses exactly on what I have been feeling being wrong about how we lead our businesses and more importantly, ourselves. In hindsight, it’s obvious: I’m always at my most creative when I’m not trying to do something, but I only manage to achieve that state of mind when on vacation. Other times, I keep trying to do things.

One would think that a life-long fascination of zen buddhism would have taught me that already but I guess not.


I recommend reading “The Goal”. It is IMHO the best business book ever written.



I don't like efficiency as a concept -- it hides too much. As a ratio of output over input, it can be used to say all kinds of things (we pay our employees less, I spent less time with my family, etc) behind a veneer of merit or technological improvement.

I prefer talking directly about inputs/costs and outputs/desired effects. This also makes it more explicit who pays the costs and who gets the benefits.


Efficiency is the opposite of redundancy, and both are needed in particular situations. The question is always, what are you optimizing for?


The enemy is the concept of money with a value, substrate of everything vs money as a unit of measure, that's because if money have a value "efficiency" is about making money, if money represent a value it's the represented value the target.

That's the core. Once understood that the rest start to be obvious.


"The enemy of efficiency

    “You’re efficient when you do something with minimum waste. And you’re effective when you’re doing the right something.”
Many organizations are obsessed with efficiency. They want to be sure every resource is utilized to its fullest capacity and everyone is sprinting around every minute of the day doing something."

This is what's called productivity. Efficiency is how much the productivity align to a certain goal. Depending on which goal you measure the productivity against the efficiency will be different.

In the case of Tony "Every minute of his time goes on the most important part of his work—making decisions—and not on dealing with trivial inconveniences like waiting in line at the post office."

does he take the -right- decisions for the company benefit? Could he think up good strategies at the waiting line? or get inspiration from the surrounding? or just rest at the waiting line to perform better in action?

To make it more trivial: Imagine a worker that's really good at making shoes. This worker can output 60shoes a hour (with good quality). But now this worker actually works at company making computers. The computer company does not really now what to do with all these shoes. The worker is really good at making shoes and have high productivity compared to his fellow friends at a shoe company. But it does not help the computer company to sell or produce more computers. This shoe maker would probably be a better fit in a shoe company. (But who knows, maybe the shoes are so good that the fellow computer makers need less time at the doctor by wearing them. And them seeing the shoe maker creating shoes with such determination and productivity, that they get inspired to make computers with same determination and productivity.) Only the results can tell.

So what is the goal? That is probably the most difficult question. As to be able to measure efficiency the goal needs to be measurable. And probably there is not only one goal that a company strive for but many. And these goals can compete with each other. These goals can also be divided into smaller goals, for different parts of the organization.

Efficiency isn't so easy to measure but productivity is. Therefore most tend to stick with productivity as a tool to improve.

There's often a mix up with productivy and efficiency which makes the messages confusing.

A good read: M Goldratt, E. and Cox, J., 1993. The goal - A process of ongoing improvement.


Yep “The Goal” is a must read to understand how to run organisations well.


The article can be summed with with a link to the book it itself links:

https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...


Pick the right tool for the job, based on its sheer ability to perform, not on its efficiency at performing.

Once you have a process that works, then you can focus on driving more efficiency out of it.

AKA watch out for premature optimization.


Tom Demarco's Slack book is one of my favorites. I re-read it every 3-4 years to remind myself of the core arguments and avoid getting carried away with efficiency and busy work.



let me recommend

https://www.tbray.org/ongoing/When/202x/2020/07/05/Too-Effic...

on this topic. Tim Bray's writing is always worth reading, but I think he's really valuable on this specifically.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: