I value a system that another person can understand, support, and recover. There is room for ambition inside that preference. Clear foundations give a team more freedom to experiment because fewer routine tasks depend on someone remembering an exception. When a new component makes its way into an environment, I want to understand the capability it adds and the continuing attention it will require.
Source
The industry is still trying to remove accidental complexity
OpenTelemetry’s May 2026 blueprint initiative responds to difficulty combining otherwise useful components. That is a reminder that a standard can improve interoperability while still leaving significant operating choices.
My preference would be to standardize the choices that do not differentiate the firm’s work. Keep room for experiments at the edges, with a clear test of whether their additional capability justifies the responsibility they add.
Synthesis
Spend attention deliberately
A routine service should ask as little unnecessary interpretation from its operator as possible. Consistent account ownership, familiar configuration patterns, current documentation, and a tested recovery path all help. They give people fewer exceptions to remember under pressure.
This matters most in the foundations. Identity, access, backups, and the systems that hold important records support many other decisions. When their behavior is understandable, a team can change the work above them with more confidence.
The cost of complexity is often distributed. One extra integration requires an account. The account needs a renewal or credential change. A provider updates an interface. Someone must recognize the failure and understand which system owns the data. Each step may be reasonable; together they create an operating commitment.
Proposal
Ask what a new component replaces
Before introducing another service, I want a clear description of the capability it adds and the work it removes. If it only adds another route through an existing process, its benefit needs to justify the additional support path.
Consider a hypothetical approval workflow spread across a form, a spreadsheet, a message channel, and an automation. A new interface might improve the experience. It might also leave all four systems in place while adding a fifth. Drawing the complete path makes that tradeoff visible.
Describe this figure
A hypothetical approval workflow spread across four systems, joined by one path from left to right: a form, a spreadsheet, a message channel, and an automation. Above them sits a new interface, a fifth system that might improve the experience; its arrow adds another route into the existing process. The note under the four systems reads: it might also leave all four systems in place while adding a fifth. Beside the new interface, a review box asks what it replaces, with two lines left blank for the reader: the capability it adds, and the work it removes.
Google’s discussion of simplicity treats complexity as an architectural and operational concern. I take a practical lesson from that: an implementation should be judged partly by how readily another person can explain its behavior.
Give experiments an ending
Experiments deserve room to be useful. They also benefit from a boundary: a defined question, limited access, an owner, and a date to decide what happens next.
If an experiment succeeds, decide which responsibilities come with keeping it. Move accounts into appropriate ownership, document the dependencies, and make failures visible. If it does not earn a permanent place, remove the access and retire the component. An abandoned experiment can otherwise become an unexplained dependency.
Sometimes added complexity is the right choice. A firm may need a capability that standard tools do not provide. The argument should be specific enough that the team can revisit it when the need or the available options change.
Make understanding part of acceptance
Before calling a change finished, ask a second person to explain the ordinary path and the recovery path. Let them use the documentation. Notice where they need the original builder to translate an assumption.
That exercise is a useful measure of how much knowledge the design requires people to carry. I am comfortable with ambitious systems. I want their routine operation to be calm enough that the ambition remains sustainable.
Proposal
What I would test next
I would review one integration that frequently needs explanation. Remove or standardize one unnecessary variation, then have another operator handle a routine change. If clarity improves without losing a required capability, repeat that approach elsewhere.