Software engineering replaced craft intuition with process ritual. Every natural act of building software has been wrapped in ceremony, named, certificated, scheduled, and sold. The wrapping is not the thing.
A plumber does not watch conference talks about pipe routing philosophy. They do not hold retrospectives on whether water flowed correctly last sprint. They do not obtain a certification in drain connection before connecting a drain. They have a trade. The fundamentals are internalised. The work gets done. Nobody writes blog posts about how to do it correctly because the people doing it already know.
Software engineering is writing blog posts about version control strategy. About how to run a meeting. About whether branches should exist. About what questions to ask in a job interview. These are not advanced topics. They are the basic furniture of the craft — the things that should be so thoroughly understood they require no discussion, the same way a plumber does not discuss whether pipes should connect to the thing they are plumbing.
The fact that these are active debates is not a sign of a maturing industry. It is a sign of an industry that skipped the part where it became a trade and went straight to selling frameworks to fill the gap.
The vacuum and the people who monetised it.
Foundational engineering education — the kind that produces engineers who reason from first principles rather than reaching for the nearest named framework — is genuinely hard to deliver at scale. Universities produce graduates who can pass algorithms interviews. Bootcamps produce graduates who can scaffold a React app. Neither reliably produces engineers who have internalised what software is, how systems fail, and what the actual constraints are on the decisions they will make every day.
That vacuum is real and the ceremony economy exists to fill it. A conference talk gives an engineer something to cite. A certification gives them something to display. A framework gives them something to follow. None of these are the same as understanding — but they look like understanding from a distance, and in an industry that often cannot tell the difference, looking like understanding is commercially sufficient.
A precise technical argument, developed for a sophisticated audience, enters the conference circuit. It gets simplified for a talk. The talk becomes a course. The course becomes a certification. The certification becomes a line on a CV. The nuance that made the original argument defensible is gone. What remains is a slogan — and a Head of Engineering who can recite it without being able to explain the reasoning underneath.
The influencer is not always a charlatan. Many started as genuine practitioners with real experience and real insights. But the economics of influence reward simplicity, consistency, and a loyal audience — not nuance, revision, or the kind of "it depends" answers that accurate engineering advice usually requires. The product drifts toward what the audience wants to hear, which is a clear answer they can apply without having to think too hard. The influencer stops being a practitioner and becomes a brand.
Following that brand is not thinking. It is outsourcing thinking to someone whose incentive is to be followed, not to be right. And the engineers doing the following often know, somewhere, that something is missing — but the certification is real, the framework has a name, and questioning it means doing the harder work of building a position from first principles. That is uncomfortable. The ceremony is easier.
Natural acts of engineering, wrapped and sold.
Boiling a kettle is not a framework. You fill it, you switch it on, the water boils. The act does not require a certification, a retrospective on last week's boiling, or a conference talk from someone who has developed a proprietary kettle methodology. Most of what developers do daily should be exactly this — acts so thoroughly understood they require no thought, freeing the mind for the work that actually demands it.
The ceremony does not free the mind. It occupies it. Every hour spent in a process ritual that exists to compensate for internalised foundations that were never built is an hour not spent building something. The ceremony is not neutral overhead. It is a direct tax on delivery, paid continuously, by teams who have been convinced the tax is the product.
Ten feet from the ground before they consider the reserve chute.
The agile retrospective is the ceremony economy's clearest case study in a feedback loop too slow to be useful. A problem surfaces in the team. The next retrospective is in two weeks. The problem is documented. A change is proposed. The change is implemented at the start of the next sprint. Two weeks later, the following retrospective assesses whether the change worked.
That is a monthly feedback loop on problems that compound daily. By the time the retrospective process has run its full cycle, the problem has been running for four to six weeks. The team has adapted around it rather than through it.
A retrospective is the reserve chute debate happening ten feet from the ground. The ceremony has its own schedule and the schedule does not care about your altitude.
The EOS L10 meeting does something structurally different. A weekly touchpoint, tightly timeboxed, with a fixed agenda: what is not working, why, what do we try differently this week. The feedback loop is seven days. A change is made, observed within days, and assessed at the next weekly meeting with enough proximity to the change to actually understand whether it worked and why.
This is not an argument against structured process. It is an argument for feedback loops that are honest about the speed at which problems compound. A weekly conversation about what is broken is not a framework. It is a team paying attention. The ceremony did not invent that. It just wrapped it in enough ritual to make it billable.
Who benefits from the complexity?
The ceremony economy has beneficiaries and they are not the teams running the ceremonies. The beneficiaries are the people who designed the frameworks, built the certification programmes, run the conferences, and sell the consulting engagements to implement the methodology that the certification said you needed.
This is not a conspiracy. It is an incentive structure. Complex processes require expert guidance. Expert guidance requires experts. Experts require credentials. Credentials require certification bodies. Certification bodies require ongoing revenue. Ongoing revenue requires the process to remain complex enough that the credential continues to have value. Simplicity is the enemy of the model. Every time a team internalises a practice and stops needing help with it, a revenue stream ends.
If a practice requires a certified practitioner to implement correctly, ask whether the practice is genuinely complex or whether the complexity has been manufactured to require the practitioner. Agile is not complicated. SAFe — the scaled agile framework that takes Agile and adds hundreds of roles, ceremonies, and artefacts — is complicated by design. The complication is the product.
The engineers on the receiving end of this are not stupid. They can often feel the hollowness of the ceremony. They sit through the retrospective knowing it will not change anything. They follow the GitFlow procedure knowing it is slowing them down. They obtain the certification knowing it does not reflect what they actually understand. But the ceremony is mandated, the certification is on the job description, and questioning it means doing the harder work that the ceremony was supposed to replace.
Use your own brain.
The alternative to the ceremony economy is not a better ceremony. It is engineers who have internalised enough foundational understanding to reason about their own situation without reaching for a named framework every time a decision needs to be made.
That requires reading primary sources rather than summaries. Understanding the context in which a practice was developed before applying it. Being willing to say "this does not fit our situation" when the framework does not fit — and being able to explain why in precise terms rather than just resisting change. It requires the intellectual confidence to hold a position under pressure, and the intellectual honesty to revise it when the evidence says to.
It also requires engineering leaders who model this. The Head of Engineering who mandates a practice because they attended a conference talk is not demonstrating leadership. They are demonstrating that they stopped thinking at the point where a credible-sounding person said something confident. The engineers underneath them notice. The good ones update their CVs.
Can you explain why you do what you do, from first principles, without citing an influencer or a framework? Can you identify where the practice applies and where it does not? Can you describe what problem it solves and verify that problem exists in your specific situation? If not, you are performing the ceremony. You have not internalised the trade.
The plumber connects the pipe to the thing being plumbed. They do not need a framework for this. The understanding is theirs — built through apprenticeship, practice, and accumulated judgment about how systems behave. That judgment is not outsourced to a certification body. It is not refreshed annually at a conference. It is not dependent on a consultant to implement correctly.
That is what a trade looks like. Software engineering has the knowledge base to be one. What it is missing is the culture of internalisation — the expectation that the fundamentals are owned, not rented. Until that changes, the ceremony economy will keep selling us our own tools back at a markup, and we will keep buying them because nobody taught us we already had everything we needed.