Amadeus Lederle

The sentence sounds obvious and is rarely taken seriously. Most technology decisions are argued in technology terms — architecture, platform, model, vendor — and settled somewhere else entirely: in processes, responsibilities, incentives, and in who answers for a mistake.

Technology is therefore not a set of products a company owns. It is closer to its operating system. It changes not only what people work with, but how decisions are made, where quality is created, which errors are expensive, and which work still exists at all.

What actually happens when a cheaply built tool becomes responsible for an expensive process?

That is the question my interest in AI and automation runs on, and the reason I do not treat either as a tooling topic. Producing software is getting cheaper. Being answerable for it is not.

None of which means software is losing its value. Systems a production line, a release or a recall depends on plausibly become more valuable as arbitrary code becomes easier to produce: what is scarce was never the code, but the installed base, the process integration, the operational history — and someone who stands behind it.

A large share of public technology opinion is formed in environments where being wrong is cheap. A demonstration that fails is awkward. A wrong inspection decision reaches the customer, worker guidance that is down stops the shift, and incomplete traceability is only noticed at the moment it is needed.

Industrial and business-critical environments enforce their own discipline. Systems run for years rather than quarters. They are used by people who did not choose them and cannot avoid them. They hang on physical processes with their own tolerances, and on organisations where the workaround is often the real process.

My areas of work come out of that world: manufacturing and quality software, worker guidance, traceability, audit trails, process data, retiring legacy systems, automation, software architecture, cybersecurity — and the question of what any of it an organisation can actually operate.

That is the distinction I care about. Not that I can judge technology because I have built it, but because I have watched how it behaves once somebody depends on it.

1. Software

   Engineering, licensing, support. Where you learn how systems are really built, as opposed to how they are described.

2. Product and customer

   Product ownership, after-sales, customer care. Where you find out what a system is actually being used for.

3. Quality and operations

   Quality management, support, service processes, operational responsibility. Where the cost of decisions becomes visible after they have been taken.

4. Technology leadership

   CTO: architecture, portfolio, migration paths, building an organisation, technical review in an M&A context. Where technical questions become investment questions.

5. Translation

   Chief Technology Evangelist: technology vision, positioning of the portfolio, communication inward and outward. Where technology has to be explained before it can have an effect.