You Are the Only Thing Your Tools Have in Common
Every tool your team uses remembers its own slice of the work, and none of them remembers the work itself, so a person spends the day carrying each decision from the call to the ticket to the update to whoever missed it. This looks at why that relay is real labor even though it leaves no trace, why adding more tools makes it heavier, and what a shared work record has to do so a fact travels once instead of being retyped four times.
The tool that only remembers itself
Watch your own screen for an hour and you will notice how much of the work is just moving one fact from where it was said to where it needs to live. Something gets decided on a call. You open the tracker and write it as a ticket. You drop a line in the team channel so the people who were not on the call know. Later you paste a version of it into the weekly update. The next morning someone who missed all of that asks, and you explain it again from memory. The decision was made once. You have now moved it by hand five times.
Each of the tools you touched did its job. The call tool has the recording. The tracker has the ticket. The channel has the message. The doc has the update. Not one of them has the decision, the reason behind it, and the person who now owns it sitting together in a single place you can return to. Every tool remembered its own slice and forgot the rest, because the rest was never its job.
So the joining falls to you. You are the part that was on the call and also writes the ticket and also posts the channel note and also answers the question three days later. Across all of these systems that do not talk to each other in any way that matters, you are the only thing they have in common. That is not a workflow. It is a person being used as the wire between tools, all day, and calling it the job.
What the tools actually keep
It helps to be precise about what each tool is good at, because none of this is a knock on the tools. A tracker is an excellent memory of tickets and their states. A chat app is an excellent memory of messages in the order they were sent. A doc is an excellent memory of its own versions. Each one is a clean record of the events that happen inside it.
The work, though, does not happen inside any one of them. A single decision starts as a sentence on a call, gets refined in a thread, lands as a ticket, and shows up later in an update to someone senior. The decision is the thread running through all four. No tool holds that thread, because each tool only saw the part that passed through it. The thread lives in the one place that saw every part, which is your head.
This is why the honest answer to where is that written down is so often nowhere, or everywhere, which comes to the same thing. The pieces exist. The ticket is real, the message is real, the update is real. What does not exist anywhere outside a person is the connection between them. The seams between the tools are empty, and you are what fills the seams.
The relay you run without noticing
Follow one decision through a normal week and the relay becomes obvious. A call ends with a clear choice: the team will delay the launch by two weeks and use the time to fix the onboarding flow. That is one sentence. Watch where it has to go next.
You turn it into a ticket, which means writing the what without the room's context. You post it in the channel, which means writing it again, shorter, for people who need the headline. It goes into the weekly update, rewritten once more for a reader who was not close to it. Then the person who was out that day asks why, and you reconstruct the reasoning from memory because the reasoning never made it into any of the three written versions. Four hops, one fact, and you were the carrier for every hop.
Something is lost at each hop, and it is usually the same thing. The caveat that made the decision safe. The alternative you had already ruled out. The condition that would make you revisit it later. These survive in the room and in your memory for a while, and then they stop surviving anywhere. The tools kept the conclusion and dropped the part that made it make sense, because the part that makes it make sense was riding along inside you, and you are not a durable medium.
Why nobody sees this work
There is a good description of why this labor stays invisible, and it comes from research on how people actually use systems rather than how systems are drawn. Susan Leigh Star, studying the everyday use of information tools, pointed out that two kinds of work happen at the same time whenever a person sits at a screen. One kind is visible: the keystrokes, the ticket filed, the message sent, the thing the system can see itself receiving. The other kind she described as the process of assemblage, the quiet weaving together of scattered resources and a running memory of everything in flight, most of which the system in front of you knows nothing about.
That second kind of work has a name in her account. She called it articulation work, the real-time adjustments a person makes to fill the gaps between processes so the whole thing actually completes. Relaying a decision from the call into the tracker and the channel and the update is articulation work in its plainest form. It is the connective effort that makes a set of disconnected tools behave, for a moment, like one system. And it stays invisible for a simple reason: it produces no artifact of its own. The ticket has your name on it. The weaving that got the fact into the ticket, and into three other places, leaves no trace at all.
Because it leaves no trace, it never lands on a list, including your own. Nobody assigned you to be the integration layer. There is no ticket for keeping the tools in sync. It does not surface in a review, because there is nothing to point at. It shows up only as the strange fact that a day spent mostly moving information between systems can feel completely full and produce almost nothing you can hold up and call output.
The small ask that feels enormous
The same research explains a reaction most operators know well and cannot usually justify. Someone asks you to also log it in one more place, or to also update the other doc, and the request lands far heavier than the two minutes it would take. You can feel yourself resisting a task that is, on paper, trivial. Star noticed exactly this: a tiny extra step, an extra button, one more place to type, can feel wildly out of proportion to its size.
Her explanation is that the small step does not land in isolation. It lands in the middle of the weaving, and it disrupts the running memory you are already holding to keep everything else in flight. The cost is not the keystroke. The cost is that the keystroke breaks the assembly you were carrying in your head. That is why also put it in the other tool is not a small ask. It is another strand added to a weave that only exists because the tools will not hold it themselves.
When a request to duplicate information keeps provoking resistance across a whole team, the resistance is usually the honest signal. It is telling you that people are already running an integration job by hand and are near the limit of what they can hold. The answer teams reach for is discipline, a reminder to always update every place. Discipline is a way of asking humans to be the sync layer more reliably. It treats the symptom by leaning harder on the very thing that is already the problem.
Every new tool adds a seam
This is why adopting another tool so rarely delivers the relief it promised. A new tool arrives to hold something better than the old way did, and in its own terms it usually does. But it holds its own slice, like all the others, and it does not join itself to the slices already in place. What it adds, on day one, is one more surface that has to be kept in step with the rest.
The count that matters is not how many tools you have. It is how many connections a person has to maintain between them, and that count grows much faster than the tool count. Two tools have one seam between them. Add a third and you have not added one connection, you have added several, because the new tool has to stay in step with each of the others. The person in the middle absorbs all of it. Every tool that promises to reduce work quietly adds to the connective work nobody is measuring.
None of this argues for fewer tools as such. A team picks tools because each one is genuinely better at its slice, and taking them away to cut seams usually just makes the slices worse. The problem was never the number of tools. The problem is that the memory of the work does not live in any of them, so the work of joining them has no home except a person.
Give the work a memory of its own
The move that actually removes the relay is not another place to copy things into, and it is not stationing a bot in every meeting to transcribe. Another destination adds a seam. A wall of transcripts adds volume without adding a thread. What removes the relay is a record whose unit is the work itself, a decision or a commitment with its context attached, that every tool and every person can read from instead of you carrying it between them.
In practice that means capture happens once, where the work actually happens, on the call and on the screen, without anyone stopping to file. The decision, the reason, the owner, and the condition to revisit are held together as one thing and indexed by what it was about, not by which tool it passed through. After that, the ticket, the channel note, and the update become views onto the same record rather than four separate acts of retyping. The person who missed the call gets an answer by looking, not by asking you to reconstruct it from memory.
This is what a work memory is for, and it is why the useful version sees your work context directly rather than waiting for you to hand it over. The goal is not to make you a faster relay. It is to remove the relay, so a fact travels once from where it was said and every place that needs it draws from the same source. When the memory of the work has a home outside your head, you stop being the wire and go back to doing the work the wire was carrying.
Remembering the work without watching the worker
A system that captures across your calls and your screen has to answer an obvious worry before it earns any trust, because capture that broad could easily become a record of everything a person does. The distinction that matters is what the record is of. The aim here is to hold the decisions and commitments the work turns on, with the context that makes them make sense later. Keeping a log of activity is a different thing entirely, and the difference is not a detail. It is the whole line.
That points to a narrow design rather than a wide one. Capture the conclusion and the reasoning, not a running feed of keystrokes and idle time. Keep retrieval behind the same access the work already has, so a record is visible to the people the decision already belonged to and no wider. Give people a clear view of what is being kept and a way to leave something out. A memory built this way is worth more precisely because it is selective, since a record of everything is almost as hard to search as the scattered tools it was meant to replace.
Handled this way, the thing you build is a record of what the team decided and why, rather than a record of who did what and when. That is the version people will actually rely on, because relying on it does not mean agreeing to be watched. The trust comes from the record being about the work, and from the people whose work it is staying in control of it.
A test you can run this week
If you want to know whether you are the integration layer, do not estimate it. Measure it once. Pick a single real decision your team made on a call this week, something concrete enough to point at. Then trace where it went afterward and count the places you personally moved it into by hand: the ticket, the message, the update, the answer you gave someone later.
Then check what survived the trip. Look at the last copy, the one furthest from the room, and see whether the reason behind the decision is still attached to it or whether only the conclusion made it through. The number of hops tells you how much relay you are running. The missing reason tells you what the relay costs, because the part that fell off is usually the part someone will need when they ask, six weeks from now, why the call was made that way.
If the count is more than one, and it almost always is, then the tools are not the ones remembering the work. You are. The fix is not to carry it faster or to add one more place to carry it to. It is to give the work a memory that does not live in your head, so the next decision is written down once, in a form the whole team can find, and you can stop being the only thing your tools have in common.
Sources
FAQ
Isn't this exactly what integrations and APIs are supposed to handle?
Integrations move records and fields between tools, and they are good at it. They can push a ticket status into a channel or sync a due date across two apps. What they do not move is meaning. An integration can copy the decision as a row, but not the reason it was made, the alternative that was rejected, or the caveat someone raised on the call, because those were never structured fields in the first place. The human relay exists precisely in the gap the integrations cannot cross, which is the context around the record rather than the record itself.
Wouldn't standardizing on fewer tools fix most of this?
It helps at the edges, and cutting a redundant tool is usually worth doing. But consolidation does not merge the slices into a memory of the work. Even a single tool remembers its own events, not the thread of a decision that ran through a call, a document, and a chat before it landed there. Fewer destinations means fewer hops, which is real relief, but it is the same relay with a shorter route. The thread still lives in a person until something is built to hold it.
We write everything important in a shared doc or wiki. Doesn't that already solve it?
A shared doc is a good instinct, but it is still one more destination that depends on someone running the relay by hand. It holds what a person thought to write, at the moment they had time to write it, which is rarely the moment the work happened. So it drifts. The decisions that felt obvious never get added, the reasons get compressed to conclusions, and the doc slowly becomes another slice to keep in sync rather than the place the work actually lives. The difference is whether the record is captured from the work or typed up after it.
Doesn't capturing across calls and screens just mean surveilling employees?
It would, if the record were of the person. The design that avoids that keeps the record of the work: the decisions, the commitments, and the context that explains them, not a feed of activity or keystrokes. Retrieval stays behind the same access the work already has, and people can see what is kept and leave things out. Scoped that way, it answers what did we decide and why, which is a question the team already shares, rather than what was this person doing, which is a different question nobody asked for.
How is this different from an AI note-taker that records meetings?
A meeting note-taker records one event, the meeting, and produces one more slice, a transcript, that still has to be relayed into everywhere else the decision needs to go. The relay problem lives between meetings as much as inside them, in the tickets and messages and updates that carry the same fact onward. The unit that removes the relay is the work itself, a decision with its context, captured wherever it happens and retrievable wherever the next step needs it, rather than a stack of per-meeting recordings you still have to read and redistribute by hand.