The Engineer in the Half-Space

You are reading interview loop feedback. You are going through the notes and it looks like neither a no-go nor a go. You are divided in your head too. Mitch does not seem to score high in system design, algorithms, or anything obvious for that matter. The general consensus is that Mitch does not cut it. Your gut says interview him yourself. So you do. In the end, you call it a hire.

Mitch starts the job. Everyone has some doubts. A few weeks pass and people like what Mitch is doing. He is going through onboarding, mapping the work, fixing runbooks, asking questions, documenting things that have not been documented. He also takes on projects and tries to help, even though he does not have the full context yet. He is present in meetings.

Sometimes everyone likes a person because they are pleasant, agreeable and simply fun but they won’t add much. But sometimes the team is noticing something before it has the language for it. Mitch is a gap reader.

The Interview Loop Misses This Person

Most interview loops are better at measuring bounded skill. Give someone a system design problem, and you can score their architecture and trade-offs. Give them a leetcode problem, and you can score correctness, time and space complexity.

The gap reader is harder. Mitch’s value is not that he knows every answer. He notices where the answer should be and why nobody can find it. He asks the question that exposes a missing owner. He notices that two teams are referring to the same thing differently. He can feel when a handoff is going to fail because everyone assumes they’re aligned and no one has checked. He senses a dependency that won’t miraculously be delivered.

That does not always look impressive in an interview. Sometimes it just looks like a person asking oddly practical questions.

Credit for Nothing Happening

The First Signal Was the Mess

Mitch does not join and immediately redesign the platform. He fixes the onboarding doc, tries to understand the request path, which service calls which. Teams have fossil records of how things used to work, runbooks people stopped trusting, tribal knowledge hidden in old slack threads. Mitch takes his time to do some archeology.

Most people work around that mess because they want to get to the real work. Mitch treats the mess as work. Mitch understands that if the first person gets stuck there, the next person will too. So he closes the loop. He asks the question, gets the answer, and puts it somewhere useful. He removes future drag.

He Works in the Gaps

Mitch lives in the half-spaces. He is between product and engineering, between design and rollout, between merged and safe in production, and between a blocked junior engineer and the team pretending standup will surprisingly reveal it.

Mitch may not always be the loudest person in the system design discussion. Often he is listening, taking notes down, asking who’s the owner, what do we do if this fails, do we have a migration plan, what do we do with runbooks, who should we reach out to, do we have the right dashboard? These questions just stop stupid things from becoming expensive.

As time passes, people start to bring Mitch the ugly stuff early. Mitch does not turn any of it into a trial and pretend to be a judge. He is pragmatic, keeps the problem on the table, gets the right people involved, and makes bad news usable. He makes it safe to deliver and own bad news.

The Work Shows Up as Absence

Mitch’s work often appears as nothing happening. That’s the biggest dilemma. Years ago I read a book that almost had this person. It talked about glue people, or the effect of a jelled team. I remember agreeing with it, but also feeling like it stopped one layer too early. It saw that some people make teams better. It did not quite explain how. I think this is how.

Because what Mitch does is almost invisible. That’s why they thought Mitch was magically getting everyone better. The engineer who causes a fire and then fights it for forty-eight hours gets the headline. The engineer who noticed the migration would fail on old customer data, added the check, and prevented the incident before anyone saw it gets a thanks, if that. This is a fucking measurement bug.

Mitch reduces coordination cost. And coordination cost is one of the places engineering teams bleed time. All systems get messy, teams grow, context fragments, ownership drifts, and the number of handoffs increases over time. A big portion of engineering is not writing code. It is finding out who needs to care before the code can move safely. Mitch makes that cheaper.

Trust Can Become a Bottleneck

If Mitch keeps doing this and stays long enough, the company may turn his strength into a tax. People ask Mitch because he remembers that the partner export fails when billing runs late, that the test-coverage rule background, that the migration plan depends on one person in the data platform, and that the green dashboard does not include the customer path everyone is worried about. He is not officially responsible for all of that. The company just starts behaving as if he is.

At first, this looks like trust. Mitch reads gaps. Gradually, this becomes a dependency. Sometimes, the company starts storing coordination inside Mitch. Then, this can become dangerous.

The Signal Is Friction Going Down

Mitch is just helpful. I call bullshit on that. Helpful is too small a word for this. A gap reader is doing real engineering work; they are just building the operating system around the software development.

Mitch reduces the bus factor, files Jiras for missing runbook items, and pokes at systemic ambiguities until they resolve. This is technical leverage. Nonetheless, performance systems look for visible artifacts such as features shipped, incidents resolved and so on. The person who made everyone else faster has to prove the absence of pain. That is hard unless the manager knows how to look.

After a while, the things the company used to file under taste, luck, or “just ask Sarah” become part of the system. Mitch’s talent is leaving everyone else in better shape You no longer need the brave junior to interrupt the meeting, or the heroic senior to remember the release ritual.

Interviews usually ask whether someone can perform inside the game as given. Mitch’s value is that he makes the game less stupid for everyone else.