The startup I am working for has seen entire engineering fired after they hired a lot of people and spun an enormous amount of infrastructure, spent tons of cas

The startup I am working for has seen entire engineering fired after they hired a lot of people and spun an enormous amount of infrastructure, spent tons of cash and produced absolutely nothing useful to the company (presumably because they were engrossed in spinning the infrastructure). The company isn't very large and does not provide software products to the clients. The systems are mostly business intelligence, billing, ERP-like, etc. Now we are restarting lean (but wiser for the experience). 10x less people and technology accomplishes more and faster. Most companies with that kind of problem DO NOT need Kubernetes because they don't have problems for which Kubernetes is the cheapest solution. Most companies do need focus on keeping things simple, minimise amount of stuff to make it possible to hire a development team that has a shot at understanding what is happening. For example, we made decision to restrict ourselves to only one cloud provider (AWS), to only one backend language, one frontend language, etc. Our prod environment is simple, too. No effing microservices. One application on one application server easily serves the needs of a company of over 200 employees and our clients. Simplifying the environment made wonders to productivity in many different ways, the most important being that the discussion now focuses on what the company needs and the functionality that would solve the problem rather than on technical trivia. All this makes possible following things: * having one development team where everybody can contribute to everything (no need to Zoom with local K8s guru to accomplish anything or spend time in endless meetings with "frontend people".) * hiring a relatively simple developer profile. This does not mean hiring bad developers. But it means I am looking for people who know X and Y very well rather than X, Y, Z, A, B, C each a little bit... It is stupid to assume a person will know well every one of 50 different technologies listed on their LinkedIn profile -- most likely they only really know couple of things and everything else only superficially. * hiring from talent pool that has a lot of experience but not necessarily in the stuff that other companies require. Other companies may hive overlooked them because they don't know a bunch of new tech, but we don't care. We only care that they are great people that get shit done, fit our company, and know how to design and implement functionality in their core programming language. * engineers being able to accomplish their individual tasks from start to end, right after joining the company. No need for a long learning period. * company needs main center of attention rather than spending large part of the effort on technical trivia. My take? If you need to add something, first ask yourself what are the costs and better understand what you get in return for that cost.