[ID1452319]

The issue I have with IT departments is that they see their job as implementing the technology and then putting the "guard rails" in place, but not producing standards and ways of working.

As a consequence I spend too long sifting through emails, Team chats and Team sites looking for that document that I know I've seen, but cannot recall the method by which it was delivered to me.

[Terretta]

Crucial insight.

Everyone has to agree to use the right tools for the same nature of things. One possible lineup among many:

Email - external interactions, basically

Team groups / channels: team-scoped information of value, should be associated with a ...

... Team-scoped file store: Teams does this well, as the File tab are Sharepoint subsites which can also be seamlessly used via OneDrive, importantly allowing live doc editing during meetings instead of screen sharing documents

Ad-hoc chats: one or many person conversations that take the place of most meetings, can be ongoing, but the information isn't usually needed by a future team member (action items are not here, they go in P below)

KB store (Notion, Confluence, whatever*): See PARA (Projects, Areas of Responsibility, Reference, Archives) but only meta information about a project or product goes here, the actual work goes in ...

Kanban/Task manager (Trello, Linear, Monday, Asana, Jira): Everything about the P in projects or products that structurally fits

Live meetings : workshop with tangible outcomes (decisions, priorities, etc.) captured as artifacts created by meeting participants during the meeting (likely requires using tools during the meeting, to avoid double-do)

* I say whatever, but I prefer knowledge capture that's a KB site, and live editable, with per user cursors and comments, preferably using Markdown so sections can be published by almost any doc/site gen tool these days

[everforward]

I've used this workflow, and it's generally terrible. There's so many repositories of information that the definitions of what goes where become nebulous and subjective.

E.g. does an architecture diagram for an app go in the team-scoped file store so it can be live edited during architecture discussions, or does it go in the KB store because it is meta information in a way, or does it go in the task manager because that architecture is an artifact of some actual work? I could see valid arguments for any of the 3.

My experience is that things become better by using fewer tools, even if that means the chosen tool is somewhat less well suited than a more specialized tool.

E.g. I would replace the team-scoped file store and the KB store with a git repo. It's not as good, but it's good enough, and one less place to search. A company should use either chat or email, but not both (both is fine as long as it's explicit that email exists largely for HR to mass-email people and to get calendar events).

That cuts it down to a file store/KB, a digital communication method, a task manager, and in-person events. Removing potential duplicate use cases makes it much harder to use the wrong tool for a particular thing. Nothing but the KB is suitable for storing documentation. Nothing but the task manager is suitable for organizing work.

I think some of these features just aren't worth the overhead of having another location to search through. Live editing is neat, but I'd happily get rid of it to not have to search through another data source.