Glue work as artifacts

Day 20: Glue work as artifacts, not heroics

If your team stalls the week you go on holiday, that doesn't prove you're valuable. It proves you're a bottleneck. The coordination and context work you do quietly is often the most valuable work on your team. It's also the work most likely to hold back your promotion, because it only exists in your head. In 2026 that costs you something extra: context that stays in your head never reaches your coding agents either.

The week I was away

A while back at PhoenixDX I took a week off. Code kept shipping, but nobody made any decisions. I came back to three PRs blocked on questions only I could answer, and two services built on conflicting assumptions about the same API. A new hire had lost days to Slack archaeology, scrolling through old threads to work out why things were the way they were. I'd become the glue, and at some point the glue had set into a wall.

The term: glue work

Tanya Reilly named this in her talk and essay "Being Glue": the coordination, context and unblocking work that keeps a team moving but never shows up as commits. It includes onboarding people, noticing when two teams are about to collide, writing the doc nobody asked for, and chasing the flaky test. Day 19 covered why visibility matters. Today is about work that's hard to see by its nature, and what to do with it.

The confession: the glue I hoarded, and why it felt rational

None of it was ego. Every time, hoarding was simply the fastest option I had:

• ▹Customer translation. "I'll just tell them what the client meant." It took me five minutes. The team would have needed an hour of back-and-forth. But they never learned to read the client, so every future request still came through me.
• ▹Cross-team unblocking. "Faster if I ping their lead." It worked every time, and that was the problem. The relationship was mine, so the path stayed blocked for everyone else.
• ▹Holding context. "I remember why we chose Postgres." That made me a walking decision log. No search, no history, and a single point of failure who sometimes went on holiday.

Each act of glue saves time today and costs more every quarter. Glue with no owner and no written record turns into hero work, and hero work holds you back in two ways. It caps your career, because nobody gets promoted out of a job only they can do. And it caps your team, because they can't move faster than you can answer DMs.

The turn: recognition isn't the fix

The usual advice is to make sure glue work gets recognised in performance reviews. I tried it and got the recognition. The bottleneck didn't move. Recognition gives the hero a nicer label. It doesn't remove the dependency, it doesn't make the work transferable, and it doesn't give anyone else a way to pick it up. You end up getting praised for being the wall.

Your manager not seeing the glue is a smaller problem. The bigger one is that glue stored in heads and DMs can't be seen by anyone, can't be handed over, and can't be built on.

What actually worked: glue as artifacts

The fix was to stop doing glue in my head and start shipping it as written artifacts, each with an owner. You can link an artifact, review it, hand it to someone else, and put it in a promotion case. Three worked for us at PhoenixDX.

1. A decision log

Write one short paragraph per decision: what we decided, why, and what we rejected. People tend to skip the rejected options, but those are what stop the same debate coming back six months later. It's a lightweight version of the Architecture Decision Records (ADRs) Michael Nygard proposed in 2011.

# decisions.md

## 2026-03-04 — Postgres over DynamoDB for the orders service
Owner: @linh  |  Status: accepted

What: Orders live in Postgres (RDS), one schema per tenant.
Why: Reporting needs ad-hoc joins across orders, refunds and invoices;
the team already operates Postgres; volume is well within a single primary.
Rejected: DynamoDB — cheap at scale, but every new report would need a
new access pattern and GSI. Revisit if write volume becomes the bottleneck.
Affects: orders-api, billing-worker, analytics exports.

2. A context file per repo

Every repo gets a context file with its conventions, boundaries and gotchas: what a senior engineer would tell a new joiner on day one. Claude Code reads CLAUDE.md. Many other coding agents read AGENTS.md, which does the same job. Keep it short and specific, and link to the decision log instead of copying it.

# CLAUDE.md — orders-api

## What this service owns
- Order lifecycle (created → paid → fulfilled → refunded).
- It does NOT own pricing. Call pricing-svc; never compute totals here.

## Conventions
- Money is integer cents. Never floats.
- All DB access goes through /repo layer; no raw SQL in handlers.
- New endpoints need a contract test in /tests/contract.

## Gotchas
- `status` in the client API means payment status, not fulfilment. (See decisions.md 2026-05-12.)
- The staging Stripe webhook is shared with billing-worker; don't change its path.

## Ask / escalate
- Pricing questions: #team-pricing (glue owner this sprint is in the channel topic).

3. A rotating glue owner

Each sprint, one person is the named glue owner. The role is time-boxed (we aimed for a day or two of the sprint, not all of it) and it produces written outputs. The owner updates the decision log, keeps context files current, writes handoff notes, and turns any question that gets asked twice into a runbook entry. Because the role rotates, the knowledge spreads. Because the outputs are written, the work counts as delivered work and not as a favour someone has to remember.

The plot twist I didn't plan for: the agents

When we brought in coding agents like Claude Code, a split showed up within weeks. In repos with a decent context file and a decision log, the agents wrote useful PRs. They used integer cents, called pricing-svc and wrote the contract test. In repos without those files, they wrote confident nonsense: code that compiled and looked reasonable but broke a boundary nobody had written down.

Looking back, that makes sense. An agent is the most extreme new hire you'll ever onboard. It's capable and fast, and it has no memory of why anything is the way it is. It can't DM you, and it doesn't pick up tribal knowledge over lunch. All it has is what's written in the repo and what you put in the prompt. The glue I'd finally written down for humans was exactly the spec the agents needed. Glue work stopped being overhead and became infrastructure.

• ▹A decision log stops an agent from "helpfully" bringing back an option you already rejected.
• ▹A context file holds the boundaries and conventions that turn plausible code into correct code.
• ▹Runbooks give an agent, or a human on call, a known-good path to follow so they don't have to improvise.
• ▹Practical rule: if an agent gets something wrong twice for the same reason, you're missing an artifact. Fix the file, not just the PR.

Bring it back to you

If you're the one doing the glue, you aren't doing it wrong. You're storing it wrong. Work that lives in DMs and in your memory is invisible, and invisible work doesn't get promoted. Work that lives in an artifact can be linked, counted, reviewed and handed over. In a promotion case, "helped the team a lot" is an opinion. "Wrote the decision log the team and our agents now use, with 14 entries this quarter" is evidence. (Use your own real numbers.)

New tech leads and EMs: you're the people most likely to start hoarding. Every time you answer the same question twice in a DM, you add another brick to your own wall.

When NOT to make an artifact

• ▹One-off questions that won't come up again. Answer them and move on.
• ▹Decisions that are still changing every day. Log them once they settle, or the log turns into noise.
• ▹Anything that duplicates a source of truth that already exists. Link to it instead.
• ▹Long essays. If a decision entry runs past one screen, nobody will read it, human or agent.

Common pitfalls

• ▹Writing the doc once and never touching it again. A stale context file is worse than no file, because agents will follow it with total confidence. Give every artifact an owner.
• ▹Making yourself the permanent owner of every artifact. That's hero work with better formatting. Rotate it.
• ▹Treating artifacts as favours. Ship them like features: link them, review them, and mention them in standups and 1:1s.
• ▹Writing for yourself. Write for the newest person on the team, or for an agent with zero context.

This week's exercise (Day 20 step)

• ▹List three pieces of glue that only you hold right now. Some prompts to help: What do people DM you about? What breaks when you're away? What do you explain more than once a month?
• ▹Pick one and ship it as an artifact: a decision record, a repo context file, a runbook or a handoff note. Keep it under one page.
• ▹Test it. Give it to a teammate or point a coding agent at it, and see whether they can act without asking you.
• ▹Link it in your next 1:1 and in your brag doc from Day 19 as delivered work, not as a favour.

Guardrail: glue isn't a substitute for scope

Artifacts make glue visible, but they don't turn it into a job description. My rough personal threshold: if glue takes up more than about 30% of your week, take it to your manager as a role question. Is this tech lead or staff-shaped work, and is it scoped and levelled that way? That conversation is the topic of Day 21, on negotiating scope. If you skip it, you become the wall from the start of this lesson.

Close

The next time I took a week off, the team made two decisions without me and logged both of them. Nobody was blocked waiting for me to reply. That's the promotion case, for them and for me.

Extend your knowledge

• ▹Tanya Reilly's essay and talk "Being Glue" are the place to start. Her book "The Staff Engineer's Path" covers technical leadership more broadly.
• ▹Read Michael Nygard's original post on Architecture Decision Records, "Documenting Architecture Decisions". Compare it with the one-paragraph format above and keep what suits your team.
• ▹Go through Anthropic's Claude Code documentation on CLAUDE.md memory files, then write or tighten one for a repo you work in.
• ▹Will Larson's "Staff Engineer" explains how glue-heavy roles get scoped and levelled. It's good preparation for Day 21.