Somanos Sar: centralize operational context

Somanos Sar argued in a May 24 post that many teams lose speed not because they lack tools, but because their working context is split across Google Drive, Slack and Notion. He said the result is repeated handoffs, broken permissions and what he described as a loss of “operational memory” inside product teams. His remedy was to centralize the context around work in a shared workspace rather than rely on links passed between separate systems. That argument lands on a familiar problem for software and product teams: the decision is in one place, the file is in another, and the access request sits with a third owner. By the time a new person joins the thread, part of the history is already missing. Sar’s post frames that as an execution issue, not a tooling preference. ### Where does the friction actually show up? Sar pointed to three concrete sources of drag: files in Drive, discussion in Slack and tasks or documentation in Notion. When those systems are loosely connected, teams often have to reconstruct why a decision was made, who approved it and which version of a file is current. Slack and Notion both market integrations meant to reduce that gap. Notion says its Slack integration lets teams preserve knowledge created in Slack and tie messages to work tracked in Notion, while Slack’s marketplace description says project docs, notes and roadmaps can live alongside project context. Sar’s point was narrower than an integration pitch. He said the problem is not only scattered information, but scattered ownership of access and permissions, which forces teams into repeated requests and clarifications. ### Why do permissions matter as much as documents? Permissions become part of the workflow the moment a team cannot open the file, edit the page or see the decision log. Sar said teams should “own permissions” inside the workspace where work is happening, rather than treat access as a separate administrative layer. (notion.com) That matters because access control determines whether context survives a handoff. If the decision record is technically stored somewhere but half the team cannot retrieve it, the group still has to recreate the same reasoning in meetings, chat threads or status updates. ### What does “operational memory” mean in practice? Sar used “operational memory” to describe the accumulated record of decisions, files, approvals and working context that lets a team move without re-explaining itself. In practice, that means a new contributor can see what was decided, where the source material lives and who has access without chasing links across tools. The idea overlaps with how workspace vendors describe connected knowledge systems. Notion’s Slack materials say teams can keep the “why” behind a project visible when documents and updates live together, but Sar’s post extends that to permissions and team ownership, not just note-taking. ### Is the answer to replace every tool with one app? Sar did not argue that every product team must abandon Drive, Slack or Notion entirely. His proposal was to make collaboration happen inside a shared workspace that acts as the single source of truth for decisions, files and access control. That is a different standard from simply connecting tools with integrations. A linked stack can still leave ownership fragmented; a true shared workspace, in Sar’s framing, keeps the operational record with the team that is doing the work. (slack.com) ### What should teams do next? Sar’s post gives teams a short checklist: centralize operational context, reduce external dependencies, own permissions and build an internal record that survives staffing changes and project handoffs. The practical test is simple — if a new teammate joined on Monday, could they find the latest decision, the live file and the right access path without asking three people. The next reference point is Sar’s May 24 post on X, where @somanossar laid out the argument in full and named Drive, Slack, Notion and permissions as the main sources of fragmentation.