As I look back on my career, especially that of a freelance project-based engineer, I observe that I'm sometimes requested to work on things that eventually end up as *waste*. As I inspect these projects closer, I see that I've been requested to build more waste that I'd like to admit: - Within a team of three engineers, we were requested to spent four month building a product under a very tight deadline. We delivered. However, it turned out that a substantial part of the product hadn't been used for 2+ years since the launch, because of legal reasons behind offering the product. - Within another team, we were requested to improve software foundations of a product. We worked on improving continuous integration, on integration tests and some new features. It turned out after a few months that the company got actually sued because customers were so dissatisfied by the overall usability and stability of the system. - Within a team of two engineers and one data-scientists, we were requested to work on a scheduling system with potential high-savings. After delivery, it turned out that system hasn't been used because there was no buy-in from internal customers; but it seems that high management was satisfied because we delivered an AI-project. - Within a team of four developers, we tried ourselves to start a company and we spent half a year building a B2B monitoring platform. We didn't contact any customer, and just spent that time building. Eventually, we didn't find a customer, abandoned the effort and open-sourced the project. - I was requested to work on a six-month waterfall project. Right before the project delivery, the company decided to stop the relevant business line and also fire the related department. Since no artefact was deployed, the only value was our own learning. - I worked on a team where we were requested to help adding pricing rules to a given system. Sometimes, we delivered requested rules only to be discover later that the rules are not needed anymore because physical products in question got meanwhile out of stock. - I observed once how information from an internal application had been misinterpreted by a large margin by a business stakeholder, leading to business steering based on quite an incorrect input. - We were requested to deliver tickets, only to have their specification changed immediately later, which in turn required immediate rework afterwards. - I have observed a team of developers within a waterfall project who prioritized adherence to code standards and high test coverage above all else; while at the same time observing the business struggle for a year to see any visible results apart from ticket specifications. It was this growing list that got me thinking about what can be done differently. How to prevent waste from occurring? How to deal with company dynamics and requests? How does architectural and technical excellence fall into this whole thing? How to ensure that I work on stuff that matter and won't be thrown away or hibernated? How to prevent misinterpretations? These are the topics I've been curious to explore.