Solving complex IT problems
The incident has been open for three months. Network says it's the application. Application says it's the network. The VoIP provider says it's Kubernetes. And every Monday first thing, it fails again.
If this story sounds familiar, you're in the territory where I work: complex technical problems that cross layers and that no single team sees in full.
The bug that bounces between teams
The problems that reach me follow a recognizable pattern:
- The incident bounces between teams or vendors: each one looks at their piece, and their piece works.
- The bug only happens in production. In staging, never.
- The system was set up by someone who's no longer around and nobody understands it end to end.
- It has been open for weeks and three patches have already been tried that patch nothing.
The common denominator is that the problem doesn't live in one layer: it lives between layers. Between SIP and the network. Between the phone without coverage and the sync. Between the AI model, the queue, and the database. That's why whoever only looks at one layer can't see it.
How I work: method, not heroics
I don't believe in the guru who stares at the logs, frowns, and feels where the bug is. I believe in a boring process that works:
- Reproduce. If the failure can be triggered at will, it's already half contained. If it only happens in production, you work by observation: capture every occurrence until the pattern emerges.
- Narrow down layers. Layers are ruled out with tests, not opinions. Every layer that falls to a test is one meeting fewer and one team that stops wasting time.
- Measure before touching. Logs, metrics, traces. If there's no observability, the first step is to add it: sometimes the fix starts with being able to see.
- Falsifiable hypotheses. Every hypothesis comes with its experiment and its discard criterion. If it can't be falsified, it's not a hypothesis, it's an opinion. And opinions don't fix production.
And everything is documented: what was tried, what was ruled out, and why. If the problem comes back in a year, the diagnosis is written down and there's no need to start from scratch.
A real example: 1,000 errors a day with the same pattern
On my own platform, the admin listing failed when filtering by category. No screenshots or hunches: I queried the environment logs in Axiom and within 24 hours there were about 1,000 errors, almost all identical —PostgreSQL rejecting a NaN where it expected an integer. The trace pointed to the full path, from the listing render to the query the ORM builds, and the parameters told the rest: a null that turned into NaN when building the filter.
That's the method applied: measure, group, read the trace. The bug stops being a mystery and becomes a specific line in a specific file.
Where the judgment comes from
Interesting problems always cross boundaries. Three systems I've built and operated show it better than any slide deck:
- SIP telephony at scale. CERNphone serves more than 5,000 users and about 30,000 calls a day. When a call doesn't come through, the failure can be in the protocol, the network, the provisioning, or the desktop client. And telephony doesn't forgive: if a call doesn't come through, people notice.
- An offline-first app. The Naiz Fit Survey App stores everything on the device and syncs when the network comes back. A sync bug can't be reproduced by looking at the server: you have to reconstruct what happened on the phone hours earlier, without coverage and with the survey half-finished.
- An AI platform with queues. In Konect, an analysis crosses a Redis Streams queue, a worker, a model gateway, and a transcription provider. When a result doesn't arrive, you have to follow the trail through all four pieces without taking anything for granted.
I'm not telling you this to show off a stack. I'm telling you because having operated genuinely unusual systems — IP telephony at scale, phones without connectivity, multi-tenant platforms — is what lets me walk into your system and not get scared.
When it makes sense to call me
This service fits when the incident has been open for weeks and has already passed through several hands; when the failure only appears in production and nobody knows how to trigger it; when the system is legacy and the documentation died with the person who set it up. In one sentence: when you've been living with this for months and the cost of carrying on already exceeds the cost of fixing it.
It doesn't fit if the problem is contained within a single team and that team has access, time, and observability. In that case you don't need me: you need to let them work.
Related consulting
CERNphone: telephony for more than 5,000 users
Naiz Fit: configurable testing campaigns
Konect: audio transcription and analysis
One deployment per customer or one space per customer
IT governance: who gets in, who can deploy, and how you prove it
From standard to graph to project
Let's talk
If you have an incident that bounces between teams, tell me about it by symptom, not by the solution you've been sold so far: what fails, since when, and what you've already tried. With that, in a first conversation I can tell you whether I can help and how I would approach it.
The worst case is that you leave the call with the problem better scoped than it was.