Three Systems and a Realization

Field Note #06: The Origin of Everstep

This isn't a pitch. This is what happened.

I've written a lot in this series about the problems Everstep was built to solve: undocumented processes, status meetings as crutches, rigid workflows that break when met with reality. But I've never told the full story of how Everstep came to exist.

It started with two failures. Two systems that my agency adopted, that I helped implement. Both failed. And the reasons they failed are the reasons Everstep exists.

System one: the help desk that couldn't see

The first attempt was an IT Lifecycle Management system. The agency adopted it because it was enterprise-grade, well-known, and the vendor made a convincing case. The idea was to use it as the central hub for all internal operations, not just IT.

On paper, it sounded reasonable. Every internal request would flow through a single help desk. That help desk would dispatch work to the appropriate teams. Simple routing. Clean intake. One system for everything.

In practice, it was a disaster.

The dispatch team sat at the center of every request, but they had no understanding of what the other teams actually did. A facilities request would land in the queue and the dispatcher had to guess who handled it. An HR onboarding request would come in and they'd route it to the wrong group. Equipment requests would bounce between teams because nobody at the help desk knew the difference between a software deployment request and an database error.

The system was designed for tracking hardware and software lifecycles, not routing operational work across multiple teams. It was a lifecycle tool being forced into a service management role. The teams hated it. The dispatchers were overwhelmed. And the requestors quickly learned that if they wanted something done, they should skip the system entirely and just walk over to someone's desk or revert back to email.

The mountain had a single, narrow trailhead that funneled every hiker through a guide who'd never been past base camp.

System two: the BPM that tied my hands

After the first system failed, I got involved directly. I helped implement a Business Process Management system. This was going to be different. This was a real workflow engine. It had state machines, conditional routing, component-based design. It was powerful. It was configurable. It was exactly what we needed.

That was the pitch anyway.

The BPM system required that every state, every transition, every alternative path be baked into the system at design time. If someone needed to skip a step, the system had to have a rule for that. If a request needed to be rerouted, there had to be a transition defined for it. If a new edge case appeared, a developer had to code the path before it could be handled.

I knew what I wanted the system to do. I could see the workflows clearly. But the component-based programming model tied my hands together. Every time reality diverged from the design, which was constantly, I had to go back into the system, build a new branch, test it, and deploy it. A simple change that should have taken minutes took days.

Worse, the system required a programmer for every modification. The teams who actually did the work, the people who understood the processes best, couldn't touch it. They were locked out of their own workflows, waiting on me to translate their needs into code.

It failed. Not because the technology was bad, but because the model was wrong. A rigid decision engine can't handle the reality of business operations. There are too many edge cases. Too many exceptions. Too many moments where the right answer is "it depends" and no rule can capture that.

The moment it clicked

After the second system failed, I sat down to figure out what went wrong. Not just with the implementation, but with the entire approach. I went back to both failures and asked the same question: why didn't this work?

The help desk system failed because it centralized control in people who didn't understand the work. The BPM system failed because it centralized control in rules that couldn't adapt to reality.

Both systems shared the same fundamental assumption: the system should decide what happens next. One used dispatchers. The other used state machines. But both put the decision-making somewhere other than the people doing the work.

And then suddenly, I saw it.

I was reviewing the BPM workflows, looking at all the branches and conditions I had built to make the system "flexible." Dozens of if-then rules. Exception paths. Conditional transitions. And I realized something that changed everything:

If flexibility requires baking a control-flow branch into every step, and if you succeed in modeling every exeption, the workflow eventually becomes fluid. So I thought, why not just make it fluid?

The whole premise was backwards. Make a rigid system more flexible by adding more rigidity? More rules. More branches. More conditions. And no matter how many was added, reality would always have one more edge case that broke it.

But there was another signal, one that made even more sense. I didn't know the jobs of the other teams. I didn't know how finance handled their approvals. I didn't know the nuances of how HR processed onboarding. I didn't know the specific steps facilities took to handle a move request. In this type of system, it made sensne that they define and handle the business rules themselves. I just need to give them the platform, not a ridged structure.

That was the real failure. Not the technology. The control model.

Giving the mountain back to the climbers

Once I saw it, the design came quickly. I stopped trying to build a system that controlled the work and started designing one that empowered the teams to control it themselves.

The principles were simple:

• Teams know their work. They don't need a system, or a developer, telling them what comes next. They need a tool that makes their work visible and lets them execute it.
• Services define the destination, not every step. Give the process enough structure to be repeatable, but leave room for the team to navigate when conditions change.
• Tickets are alive. Tasks can be added mid-workflow. Steps can be skipped. The system adapts to reality instead of demanding reality conform to the system.
• Visibility replaces control. Instead of routing work through gatekeepers or decision engines, make everything visible. When everyone can see the trail, you don't need someone standing at every junction telling people where to go.

I wasn't designing a workflow engine anymore. I was designing a tool that gives teams the ability to define, execute, and improve their own services. A system that trusts the people doing the work to know how to do it.

When I was done with the design, I had the system that is Everstep today.

What the failures taught me

The ITLM system taught me that you can't centralize dispatch without understanding. Routing all work through a team that doesn't know the terrain creates confusion, delays, and frustration. The people who understand the work need to own the work.

The BPM system taught me that you can't engineer flexibility through rigidity. Every rule you add to handle an edge case is another rule that can break. The system becomes brittle under its own complexity. And when only a programmer can modify the workflow, the teams are locked out of their own processes.

Together, they taught me the most important lesson:

The system shouldn't decide the path. The system should give you the topography of the the mountain and allow teams flexibility to climb it their way.

This is why Everstep exists and why it's successful

Everstep wasn't born from a business plan or a market analysis. It was born from sitting with the wreckage of failed systems and finally understanding that the problem wasn't the tools. It was the assumption that the tools should be in charge.

Every decision in Everstep traces back to those failures. Services instead of dispatch queues. Team-based ownership instead of centralized routing. Visible workflows instead of state machines. Live tickets that adapt instead of rigid system that breaks.

I built Everstep because I couldn't find a tool that trusted teams to do their work. So I made one.

The mountain was always there. The teams just needed a trail they could call their own.