Article
The Missing Layer of Observability
A reflection on why engineering decisions need the same connected observability we expect from production software.
Software engineering has become obsessed with observability.
We measure latency.
We trace requests.
We graph CPU usage.
We monitor deployments.
We know how many milliseconds a request takes to complete and which service introduced those milliseconds. If something goes wrong in production, we can usually answer what happened within minutes.
We’ve become very good at observing software.
But we’ve paid far less attention to observing engineering.
Ask an engineering team how observable their decision making is.
You’ll probably get thoughtful answers.
“We document architecture.”
“We have a wiki.”
“Everything is in Jira.”
“There are markdown files.”
Those are good answers.
They are also answers that should make us uncomfortable.
If I asked a backend engineer to debug a production issue by searching through five different systems, reading a handful of markdown files, and hoping someone remembered why a decision was made two years ago, they would rightly tell me that the system was poorly designed.
Yet we routinely accept exactly that workflow for engineering itself.
One of the principles that has quietly shaped software engineering is that connected systems should remain connected.
The complexity of a workflow determines the amount of information that should naturally flow through it.
Break those connections, and complexity increases.
Software engineers understand this instinctively.
Look at the rise of Model Context Protocol (MCP).
AI became dramatically more useful once we stopped treating it as an isolated chatbot and started connecting it to the systems that already contain our knowledge.
That wasn’t just an improvement in tooling.
It was recognition that disconnected information creates friction.
Engineering suffers from exactly the same problem.
Think about the life of a feature.
A stakeholder defines the work.
The work is prioritized.
Tasks are created.
Engineers implement the code.
The code is reviewed.
Someone tests it.
The changes are merged.
The feature reaches production.
Most organizations would call that workflow complete.
It isn’t.
Months later, someone asks:
“Why was this implemented this way?”
“Did we intentionally ignore this edge case?”
“Was there a discussion about changing this?”
“Who approved this behavior?”
“Does anyone remember why this exists?”
Those questions are so common that we’ve accepted them as inevitable.
I don’t think they are.
I think they’re symptoms.
The engineering workflow ended too early.
We’ve become excellent at connecting code to code.
We’ve become excellent at connecting services to services.
We’ve become excellent at connecting AI to tools.
Yet we rarely connect decisions to the code they produced.
That missing connection is becoming increasingly expensive.
Especially now.
AI can generate code remarkably quickly.
But it doesn’t generate the reasoning behind that code.
As implementation accelerates, context becomes even more valuable.
Without that context, engineering speed eventually becomes engineering debt.
This realization is why I built Susumu.
Not because I wanted another project management tool.
Quite the opposite.
I wanted engineering decisions to become first-class citizens.
When I finish implementing a feature, I don’t just want a Git commit.
I want to know:
What decision was made?
What expectation did we have?
Which code implemented it?
Who made the decision?
When was it made?
Does that decision still appear to be valid today?
Susumu connects those things together.
The result isn’t another document to maintain.
It’s an engineering history that evolves alongside the code itself.
If someone asks why a feature behaves the way it does, the answer is already there.
If code changes invalidate a previous assumption, Susumu flags it for review.
The system remembers what humans inevitably forget.
For years, this kind of problem was easy to dismiss.
“It isn’t worth the effort.”
Maybe that was true.
I don’t think it is anymore.
AI has dramatically reduced the cost of writing software.
It has not reduced the cost of understanding software.
In fact, it may have increased it.
The faster we produce code, the more valuable institutional memory becomes.
I suspect the next decade of software engineering won’t be defined solely by faster implementation.
It will be defined by better observability of engineering itself.
Not just what the software is doing.
But why it exists at all.
And I think that’s a problem worth solving.