In a previous post I mentioned the Industrial Revolution as a good early example of exploitation of workers for the benefit of industry owners. Naturally, this wasn't the first or only time this happened[1]. The Industrial Revolution, however, is specifically an example of technologies driving out the workers, while their marketing suggested otherwise. The hope was that technological improvements were supposed to make life easier, to decrease manufacturing costs, therefore increasing resources for the people. Of course, that never happened: the income flowed to the owners and founders, then due to competition and product pricing adjustments - into the ether, though we can speculate that theoretically the better price point did help the people in the end.

Currently, in the tech industry there's a lot of motion towards useless churning: while in a classic industrial complex workers are to produce more product in a given time frame, in today's tech industry engineers are to put out more features, more product complexity, scale the product and its dependencies according to suggested needs. Sometimes it seems like the purpose is just to keep people busy, justify the paycheck. There's no question that some of this work is necessary, however what I advocate is a notion of a finalized product.

For several years now I had the perfect organization style in mind that stems from the above concepts:

  1. As usual, the first step is to generate a minimal product, prove its value in the market, ensure that it'll have positive cash flow, etcetera[2].
  2. Once the product is proven and further work is greenlit, it's a good time to scope out the specific staff needs
  3. Once a team is built, a complete feature list must be decided and planned. The key here is to keep it minimal but relatively final: the product shouldn't need mindless features. While the product itself is likely groundbreaking and innovative (otherwise did it really pass step 1?), its features should not be: they should be stable and using proven technologies.
  4. Finally, when the product is built and deployed, robust monitoring, alerting and autoscaling should be put in place.
  5. Once all of the above is complete, there's no reason for engineers to sit on their hands at work - send them home with a paycheck keeping them on an on-call rotation.

From outer space, this plan can be seen as such: when the product is released, it starts generating income (due to a successful step 1). This income would usually flow in an uneven way to the founders and employees: don't allow for this to happen; instead, have equal salaries across the entire company. In order for the company to save some cash for a rainy day, salaries are lower than the entire income, the rest is saved and dispersed equally to all employees regularly through bonus programs and such. After the initial stride of excruciatingly hard work, largely all features in step 3 must be completed - there's nothing else to be done. Using proper automation and modern technologies ensures stability of the product and reduces dependencies on technologies that eventually become outdated and vulnerable: operating systems, system libraries[3].

Naturally, changes to codebases will have to be made, vulnerabilities patched. Few feature additions per year may be acceptable. Overall, however, if the product, its implementation, automation and the team are truly excellent, provide the latter the paycheck and let them go home after 5-10 hours of work per week when needed.

There's another good reason to do this: in economics there's a notion that the delta of net income decreases with expansion[4]. Building a complete product and stopping there allows your team to reap the benefits and potentially continue onto the next similar venture. This may remind the reader of Google's products: when was the last time there was an update to Gmail, GSuite? Bugfixes and feature additions for GCP are similarly limited.

Overall, this does what the industrial revolution failed to do: give time and resources to the people to allow them to focus on other problems. Following this technique, several advantages spring up: there's no room for bloat and useless features[5], engineers have an end goal they're motivated to achieve: finish work and automate the job away.

Some may say that this strategy has already been at least partially implemented through the use of unlimited PTO, but when an employer provides such an option it's never analogous with going home and getting paid until there's a call for a bugfix. This may also sound similar to founding teams: once a product is largely built, sold or successfully IPOs, the founders get a cut of the final benefits, while newer team members are the ones continuing the work. It seems many of these notions are partially implemented in some organizations, but not at full scale.

Naturally, this strategy only really fits a small niche of products that can be finalized and left making money. Without a really innovative, fitting idea this is all nonsense. The biggest issue that comes to mind is capitalist competition: another organization can replicate the product and potentially offer features the initial one does not, or even offering a better price point. This is a dangerous enemy that unfortunately collapses the entire scheme.


  1. Just one example is society in the Russian Empire, which was basically split into two classes: landowners and peasants. Moving up from peasantry was practically impossible. For those interested in the subject, I strongly recommend Lev Tolstoy's works: namely, Anna Karenina, but also War and Peace. Both were written in mid to late 19th century and are not only a pleasure to read, but portray the sequence of events leading up to our revolutions. ↩︎

  2. This is best done at the most minimal level, with few folks involved to minimize losses in case of failure of any of the necessary proofs. I've always been a proponent of quick and dirty POCs, and I'm fond of working for companies that allocate time to prove a concept before throwing resources at a large-scale implementation - no matter whether the concept is as trivial as a new CI/CD system or as serious as major code refactoring: POCs should be developed for each iteration of work required to achieve the end goal. ↩︎

  3. For example, using a managed Kubernetes cluster allows abstraction from the operating system, its libraries, while using a managed load balancer solution distances machines and services you would otherwise worry about exposing directly. ↩︎

  4. As embarrassing as it is, I can't find any information on the subject. This was taught in my high school economics class. The overall explanation is: once a shop opens and generates income, the obvious next step is to open more shops to duplicate the income. However, due to rising operational overhead (staffing, management) the income doesn't simply double with another shop: it increases less with each new shop. The same notion can be seen with software development: supporting new features requires more infrastructure, engineering time, staffing, the same operational overhead as before. ↩︎

  5. Have you ever tried travelling in a city by foot without taxis? Effective transit systems do exist, but often they're overly complex and badly documented (largely in the States). Google Maps put in a lot of effort to congregate all this information in one place, but their accuracy has recently fallen - partly due to exceptions such as COVID-19, but also due to transit companies failing to update schedules and lines. Even Amtrak fails to display a large portion of its train system on Google Maps. Outside of Google Maps, on transit systems' own websites, the situation grows somehow worse, where heavy user interfaces are prioritised over easy access to information. ↩︎

New Comment
12 comments, sorted by Click to highlight new comments since: Today at 7:32 AM
Without a really innovative, fitting idea this is all nonsense.

And _with_ a really innovative, fitting idea, this is sub-optimal rent extraction of the value of the idea.

The biggest issue that comes to mind is capitalist competition: another organization can replicate the product and potentially offer features the initial one does not, or even offering a better price point. This is a dangerous enemy that unfortunately collapses the entire scheme.

Heh. We could be rich and have lots of slack if other people weren't trying to optimize their resources as well! Note that it's not just capitalist competition you have to worry about. Open Source competition will come into play for anything self-contained enough that you think it can ever be substantially finished.

Good call, OSS projects definitely quickly catch up to major non-niche products.

In the previous post, you complain that you have way too many resources to spend on garbage entertainment, and wish you were poorer because then you'd spend more time reading, socializing and exercising. Now you say that Industrial Revolution failed to give workers more resources. What is it that's so bad about capitalism - that it failed to make you richer, or that it made you too rich for your own good?

Both, actually: there's too large a gap between the richest and the poorest. At least that's how it seems to me in the States. I'm not the only one who says this, the middle class really is decreasing.

It's one thing to say that past 1970  (or 2000 to 2014 as in one of the linked articles) the middle class has been decreasing.

You however seem to argue about effects of the industrial revolution which was an event that happened on a different time scale and which actually build the middle class in the metropolian areas. 

Good call, I did find vast evidence on the subject.

Industrial revolution was just an example of automation not being beneficial for the worker, I'm not trying to link events that are two hundred years apart.

So, you believe your scheme will fail under capitalist competition. Is there any country in the world where you believe it will work? Why don't you try it there, then tell us how it worked out?

No, I don't think this can really work elsewhere. Ideally, competition would have to be controlled judicially, the idea would have to be implemented at the government-owned level, but I don't believe that powerful men can always make ideal decisions to make this work.

Following this technique, several advantages spring up: there's no room for bloat and useless features[5], engineers have an end goal they're motivated to achieve: finish work and automate the job away.

In theory open source also seems to have those advantages. (Though it doesn't necessarily cover hardware.)

When Signal was first developed they thought that building a messanger shouldn't be that complex. It should be on a level of complexity that allows for a federalized protocol with allows many different clients.

As time went on the came to the conclusion that this is not a good way to think about the problem and removed their federalization ideas to be able to implement new features such as multidevice support. 

If they hadn't Signal would likely have been faded into the background because it wouldn't have kept up with other messengers. 

This may remind the reader of Google's products: when was the last time there was an update to Gmail

Last week there seems to have been three updates:

  • Edit Calendar events directly from Gmail and Docs. 
  • Spanish grammar suggestions now available in Google Docs and Gmail. Learn more
  • New quick settings help you optimize your Gmail layout. 

Are these groundmaking new features? Not really, but having grammar suggestions will likely be appreciated by the Spanish users. 

I can imagine using the feature to edit Calendar events directly from Gmail.

Good point, Google's products were not at all a good example. Rethinking it now, I'm not sure why it sounded right at the time of writing.

As for your example of Signal's strategy amendment, aside from my personal opinion on the subject[1] (which I'd prefer not to focus on), I'm not sure that's relevant to the general discussion here. I'm not advocating that every product made follow this path, I even state that it doesn't fit everything. Even for those that fit, there will always be exceptions. If a rewrite is deemed necessary, why would that not be prioritized under my model?

Frankly, it seems to me you're not focusing on the general idea.


  1. I fully realize I'm in the vast minority here, but not only am I all for client federalization, but especially considering Signal clients' quality, I really wish they took the former path and offloaded client work to whoever chooses. Linux Signal UI has been broken for me for years: I left a group and still get its messages every once in a while, typing indicators are erratic and appear when no typing happens. I know there are many proponents of Signal, but I simply am not due to its many erratic bugs I've encountered, aside from the two I've listed. ↩︎

It's no rewrite it's just adding a feature to the protocol in a way that's not backwards compatible with the federalized 

Linux Signal UI has been broken for me for years: 

Given that you don't have mobile phone numbers in Linux, you likely wouldn't have gotten it to be useful in Linux in the initial setup. 

Frankly, it seems to me you're not focusing on the general idea.

You seem to claim that there are people who can predict in advance for "really innovative" products what features they need. That's not how it works as the lean startup movement makes clear.

Later in this thread you suggest that the job can be done by a government burocrat that does central planning. That seems even more innovation destroying.