A software development process can look remarkably healthy while producing very little.

The planning happens. Tickets move. Documents are written and reviewed. Meetings fill the calendar. Each role completes its part.

Then someone implementing a feature asks a question that nobody has answered. Or a user discovers that the delivered behavior misses something essential.

The question travels back through the organization. An explanation comes down again. Work is revised. Another meeting is scheduled.

We become very good at managing this cycle. I think we should spend more time questioning why we need it.

In earlier articles, I have explored business solution design and the shared blueprint. Here, I want to examine the process surrounding that blueprint, especially the layers we have built to compensate for understanding that was never shared.

The cost of repeated interpretation

Consider a familiar arrangement.

Business explains an idea to an analyst. The analyst elaborates it and passes it to someone responsible for solution design. That design reaches engineers, who refine the details and try to reconstruct the original intent. QA works out how to verify the result.

Every person may be capable and conscientious. The arrangement still asks each of them to interpret someone else’s interpretation.

A subtle distinction disappears. An assumption becomes a requirement. An exception remains unspoken because it seems obvious to the person who knows the business.

Eventually, someone notices. Sometimes during implementation. Sometimes in production.

We respond with more detailed templates, additional reviews, and extra coordination. Those measures may catch real problems. But before adding another layer, we should ask what created the need for it.Does this step protect something essential?

Does it support a necessary decision? Or does it compensate for people who needed to understand each other earlier?

Put the relevant perspectives around the same activity

I have worked in environments where business and engineering were close enough to ask questions directly. Progress could be fast because an uncertainty did not have to make a round trip through several roles.

Engineers often tell me how rarely they can speak to the people using their software. When that conversation finally happens, things click. A seemingly arbitrary requirement makes sense. A small inconvenience turns out to dominate someone’s working day.

The learning goes both ways. Business gains a clearer understanding of constraints and consequences when engineers can explain and question them directly.

We can make those conversations part of how we design.

Choose one business activity. Bring the relevant perspectives together. Explore the intended outcome, the rules, the exceptions, and the information people need to act.

One person looking at a statue sees it from one angle. People standing around it can notice details that are invisible from that position. Joint design gives us that broader view.

The workshop has a visible cost: several people’s time. Repeated clarification, rework, and production corrections have a cost too. They are simply spread across different calendars and budgets.

Give people a story they can examine

The outcome should be more useful than another wall of text.

This is where Event Modeling helps.

We can walk through a business activity as a sequence: someone sees information, takes an action, and something happens. That result changes what another person can see or do next.

Screens show what an actor knows at that moment. Events make the resulting facts explicit. Concrete scenarios expose the rules and exceptions.

Take a cancellation request. We can examine who submits it, what information they see, how eligibility is determined, when coverage ends, and how any refund follows.

Business experts can challenge the timing. QA can ask about a request received on the boundary date. Security can question who may access the information. Engineers can expose an ambiguity in the sequence.

Everyone has something specific to point to.

We use the business language throughout. A term such as “cancellation” needs an agreed meaning, including its consequences. Separate vocabularies and separate descriptions create more opportunities to lose details in translation.

Who can challenge the truth?

Engineers sometimes say that the truth is in the code.

Code describes the implemented behavior. But when understanding that behavior requires reading code, participation narrows. Everyone else depends on a technical explanation.

A shared Event Model gives the relevant stakeholders a place to examine and challenge the agreed behavior themselves.

That is why I call it a blueprint.

For the business activity in scope, we work toward an information-complete understanding: enough detail to explain the outcomes, rules, and relevant scenarios together. Unresolved questions remain visible.

The blueprint records what we agree today. New discoveries can change it. The implementation and its tests must remain aligned with it, or people will stop trusting it.

Controls belong in the design

Security, privacy, and compliance affect how a business activity may work.

Who may perform an action? Which information may they see? Where is independent approval required? What evidence must remain for an auditor?

Those questions belong in the exploration from the beginning. Discovering them after implementation can mean redesigning behavior that everyone thought was settled.

Removing unnecessary process requires judgment. Some controls are essential. Each retained control should have a clear purpose, responsibility, and place in the modeled workflow.

With that shared understanding established, we can make technology and implementation choices. Engineers contribute throughout the exploration, including feasibility constraints. The choices follow the understood business need.

A workshop has to change what follows

I have also seen productive workshops achieve very little lasting change.

People leave with clarity, then return to a delivery process that expects separate documents, repeated interpretation, and the same old handovers.

The shared blueprint needs to remain the reference during implementation, testing, and subsequent change. When a question arises, the relevant people return to it and update their understanding together.

Otherwise, we have added a workshop to an already crowded process.

Before celebrating another improvement to that process, I want us to examine the work it makes necessary.

Which layers would we still need if people could understand, question, and design the same business activity together?

Originally published on LinkedIn (2026-10-07): https://www.linkedin.com/pulse/before-you-optimize-process-ask-why-exists-gabriel-n-schenker-f37ie