Glue Work Is the Job, Until It Is Not

After a restructuring, two parts of an organization I worked in were no longer reading each other correctly. One side reported a delivery problem. The other did not recognize the picture being described. Both were sincere.

What I did about it was unglamorous. I listened to each side separately, then established a shared way of tracking work in flight, its status and its risks, updated on a cadence and visible to both.

A meaningful part of what had been reported as a delivery problem turned out to be a visibility problem. Not all of it. Some of the misses were real, and the difference is that they were now legible, which meant they could be worked on instead of argued about.

For a long time I would not have known what to call that work, or whether it counted as engineering at all.

What it is

It has a name. Glue work is everything that holds a multi-team effort together and appears in nobody's design document.

Noticing that two teams disagree about an interface before either of them notices. Writing the status update. Keeping the decision log. Onboarding the new engineer. Reviewing the document nobody was assigned to review. Chasing the single approval that is blocking four people. Remembering what was decided in March, and why, when everyone else has moved on.

It is real technical leadership, and it is systematically undervalued, and both of those things are true at the same time.

The reason it disappears is structural rather than malicious. Glue work shows up as an absence of problems. Nothing went wrong. The launch was not delayed. The two teams did not build the same thing twice. You cannot point at an absence in a performance review, which means the work that prevented the disaster is invisible next to the work that recovered from one.

The asymmetry

Here is the part that makes this a career topic rather than a project-management topic.

At Staff+, glue work is the job. Doing it well is direct evidence of the judgment the level requires: you saw the gap, you understood why it mattered, and you closed it without being asked. Nobody will be surprised to find it in your portfolio.

Below Staff+, an engineer who spends a year on glue work arrives at a promotion conversation with no technical accomplishments in the packet, and receives the standard advice, which is to go write more code. The work was valuable. The organization benefited. The career did not.

The same work. Different level. Opposite outcome.

And because glue work is distributed by social pressure rather than by planning, it does not land randomly. It lands on whoever notices first, which is usually the most conscientious person on the team, and in most organizations that is not a random sample. It falls disproportionately on women, on engineers from underrepresented groups, and on anyone who is least willing to watch a project fail.

So the distribution of this work is not an efficiency question. It is a question about who gets to become senior. And at Staff+, you are the one distributing it.

The technical half

There is a version of this conversation that treats glue work as pure coordination, and that version is missing something.

A lot of it is engineering. The integration test that spans two services and belongs to neither team. The migration checklist that encodes what actually breaks. The interface that reconciles two teams' incompatible models of the same entity. The contract that had to be negotiated before either side could build.

That half is where glue work stops being attention and becomes judgment, and it is the half most worth keeping for yourself. It is also, not coincidentally, the half that leaves an artifact behind.

Which points at the general move.

Turn it into an artifact

Almost everything that makes glue work sustainable comes down to converting a transient act into a durable object.

A verbal alignment becomes an entry in a decision log. A repeated explanation becomes a document, and then you send the document instead of giving the explanation for the fifth time. A tracked migration becomes a dashboard. A recurring reconciliation becomes a template, a checklist, or a paved path that makes the failure impossible rather than merely noticed.

Artifacts do three things at once. They survive you going on vacation. They are what a promotion committee can actually read. And they convert an infinite stream of attention into a finite piece of work that eventually ends.

The shared tracking I set up between those two groups was an artifact rather than a habit, and that is the distinction that mattered. A weekly conversation I personally convened would have needed me in the room forever. A written cadence with a shape does not.

A few more that hold up:

• Write glue work into the project plan as named, owned work with an estimate, exactly like any other workstream. "Migration owner", "reviewer of record", "technical program lead" turns invisible labor into a role with a scope and an end date.
• Audit the distribution. If the same person always takes the notes, always runs the sync, always onboards the new hire, that is a pattern, not a coincidence, and the rotation is the intervention.
• Give it deliberately to engineers who want the leadership path, framed explicitly as leadership work, with a plan for making it visible.
• Write the impact in outcomes. Not "coordinated eight teams" but "removed the dependency that was holding the launch and shipped six weeks earlier".
• Give credit in writing, in a forum where the person's manager is present. Hallway praise does not reach calibration.

The trap

Now the warning, because the failure mode here is not neglect. It is appetite.

Glue work has no natural boundary and it is always locally urgent. Someone always needs the thing chased today. If you let it, it will consume the entire calendar, and you will end the year having been extremely useful and having set no direction, which is the one thing nobody else at your scope could have done.

The test I use is whether the task requires my judgment or only my attention.

If it requires judgment, it is probably mine. If it requires only attention, it is one of two things: somebody else's growth opportunity, or a defect in the process that should be fixed once rather than absorbed every week. Absorbing it every week feels generous and is actually a way of hiding a broken process from the people who could fix it.

The other failure, the mirror image, is refusing all of it on the theory that it is beneath the role. The gaps between teams are exactly where cross-team projects fail, and nobody is assigned to watch them. Somebody has to be the adult in the room. At your level, quite often, it is you, and the willingness to do the unglamorous thing when it is genuinely the constraint is a large part of what credibility is made of.

The part that is a policy

I want to end on the thing that took me longest to see.

When you decide who leads the next cross-team project, who writes the status update, whose contribution gets named in the review, you are not making a series of small scheduling decisions. You are setting a policy about who in your organization accumulates the evidence that makes people senior.

That policy exists whether or not you wrote it down. The default version of it, the one where the work lands on whoever notices first, has a predictable shape and a predictable set of people it disadvantages.

Which suggests a cheap habit with a long tail. When this work gets done well by someone who is not you, write their name next to it, in the place where their manager will read it. It costs a few minutes. It is frequently worth more to them than the work itself was worth to you.