Seam Specialist
Most people optimize one side or the other. I optimize the seam.
A Seam Specialist solves problems at the boundaries between people, organizations, technologies, and ways of working. Instead of forcing one side to change for the convenience of the other, the job is to design the interface between them so both sides can keep doing what they do best.
“The biggest opportunities aren’t inside systems. They’re at the seams between them.”
The idea
Fix the seam, not the sides
Most technical problems arrive pre-framed as a choice. One system has to be replaced. One team has to change its process. One side has to eat the limitations of the other.
Seam thinking rejects the premise. It looks for the friction created where two otherwise-valid systems meet, and it starts from an uncomfortable possibility: that both sides are working exactly as designed, and the failure exists only in the interaction. That is not a rare case. In thirty years it has been most of the interesting ones.
The work is part engineering, part translation, part systems thinking, and part diplomacy. Making the technology function is the easy half. The other half is making two different realities coexist without either one having to surrender.
Greatest hits
Problems that lived between two correct answers
- 01Design ↔ Development
37 columns vs. 36
The situation
A designer delivered a layout built on a 37-column grid. The implementation system expected 36. The obvious answer was to send the work back and require a redesign.
The seam solution
I wrote an SCSS function that mathematically translated the 37-column design into the 36-column implementation grid.
Why it matters
Neither side had to redo its work. The seam became the solution.
- 02Design intent ↔ Browser reality
The Surface prototype
The situation
Microsoft needed a CSS-animation-heavy prototype, built for WebKit, to run on a new Surface tablet in Internet Explorer. The browser did not support the media queries the prototype was built on.
The seam solution
Instead of redesigning the prototype or abandoning the platform, I wrote a script that detected screen dimensions and applied a universal CSS zoom adjustment so the experience rendered correctly.
Why it matters
The prototype survived intact, the hardware requirement was met, and the compatibility gap disappeared behind the seam.
- 03Database ↔ Infrastructure
Two right answers, one broken system
The situation
A SQL Server database larger than anyone recommends virtualizing had been virtualized, and it was crashing without useful errors. The database team found no database problem. The virtualization team found no virtualization problem. Both were correct.
The seam solution
I researched the interaction rather than either system, found the I/O bottleneck the combination created, and made the case that this database belonged back on physical hardware.
Why it matters
The failure did not live inside either system. The job was proving that two individually-correct answers can still produce one broken whole.
Operating principles
Six rules for working a seam
Don’t pick a side. Fix the interface.
When two teams or systems disagree, the useful question is usually not who is wrong. It is what is happening where they meet.
The bug may be in the interaction.
Two healthy components can produce a broken whole. Debug relationships, assumptions, timing, data flow, and boundaries — not just components.
Translation beats replacement.
Before replacing a system, a process, or a person, ask whether a translation layer can preserve what already works.
Never make humans do what software can do.
If the seam can absorb the repetitive translation, reconciliation, monitoring, or adaptation, automate it there.
Preserve expertise on both sides.
A good seam lets each side stay good at what it is already good at, instead of dragging everyone toward the lowest common denominator.
The best seam disappears.
The ideal interface becomes boring. People stop noticing the incompatibility, because the system quietly resolves it for them.
The method
The Seam Specialist diagnostic
Seven questions I run on any problem where two things are colliding. Most of them get answered before anybody writes code, and the ones that do not are usually the reason the code was not working.
01
Name both sides.
Which two systems, teams, incentives, processes, or assumptions are actually colliding?
02
Assume both sides may be right.
What follows if neither side is broken? That is usually the version of the problem nobody has worked yet.
03
Find the translation burden.
Who, or what, is currently doing manual work to compensate for the mismatch? That work is the receipt.
04
Locate the boundary failure.
Format, timing, scale, ownership, terminology, workflow, incentives, compatibility, or expectations. Name which one.
05
Design the seam.
Can software, process, automation, policy, or plain communication absorb the mismatch?
06
Protect both sides.
Does the solution work without degrading what either side already does well? If not, it is not a seam, it is a tax.
07
Make it disappear.
Can the seam become infrastructure instead of a recurring negotiation?
Got two things that will not talk to each other? Tell me where they meet.
In practice
Where the pattern shows up today
Business ↔ Engineering
Hello World
The consultancy often runs as the translator between what an organization is trying to do and what its engineering can actually deliver. The value is not only writing the software. It is getting strategy and execution to understand each other well enough to move together.
AI ↔ Humans
AI Literacy
Nobody should have to become an AI expert before they are allowed to use AI responsibly. This is the mental models, the governance, and the practical boundaries that let an organization adopt the technology without handing over its judgment.
Monitoring ↔ Resolution
Autotix
Monitoring detects a problem and then leaves a human to translate that signal into a ticket, a diagnosis, and a next step. Autotix lives in that gap, turning detected errors into actionable work and proposed fixes.
Government ↔ Community ↔ Existing systems
Public-sector & community work
Most civic problems are not caused by an absence of tools. They are caused by disconnected agencies, vendors, volunteers, and reporting requirements. The opportunity is usually to connect what already exists rather than replace all of it.
The bigger idea
Seam Specialist is not a job title. It is a way of seeing problems.
It explains why a developer writes a translation function instead of rejecting a design, why a compatibility problem becomes an opportunity for an adapter instead of a rewrite, and why a mysterious infrastructure failure turns out to require understanding the relationship between two perfectly healthy systems.
It also explains a career that otherwise looks like a list of unrelated jobs: bridges between technology and business, between humans and AI, between monitoring and action, and between organizations that need to cooperate without becoming the same organization.
Don’t force either side to become the other. Build the seam that lets both sides work.