Bit a of brain dump
Overall I thought this book was pretty good. The application of the principles in this book is probably most geared for smaller companies who still have the ability to more easily enact change. I work for a company of 5-10k employees and implementing these tools, even at a department level, would require a ton of effort.
# Communication
I really like the idea here of using distinct tools for different types of communication - with the main goal to be optimizing for information _retrieval_. Most people optimize for information delivery (I.e. get this email out of my inbox). This concept really resonated with me and I could see a large benefit in my organization
Email is described as the tool to use for external communication and teams/slack is the tool for internal communication. I think this would be really well received in my organization because it’s currently a cluster fuck of teams channels and a massive amount of emails.
# Planning
The next area was planning in this section he describes the use of work management tools. This section described basically putting everything in a centralized to-do list app (Asana, Monday.com, etc) This makes so much sense and aligns with a lot of other principles in this space (I.e. GTD, Inbox Zero, etc). The craziest thing is that my current employer doesn’t even offer us one of these tools to use.
If there’s any major change I could implement within my own workplace it would be the implementation of a work management tool. For us, it’d probably be whatever Microsoft Planner/To Do ends up turning into (side note: Microsoft needs to figure their shit out)
My ideal tool would be Notion or even Coda.
# Resources
Nick describes/allocates resources to knowledge management tools and process management tools.
Processes are defined as how to do something, whereas the remaining type of information goes into the knowledge base and describes the who, what, when, where, and why.
I did my master’s paper on knowledge management and Nick did a pretty good job at simplifying things down into a chapter. The main things here are to set up a knowledge system architecture at the onset of this. Speaking from experience, it’s a big effort to re-architect a knowledge base once it’s been established. Differing from my research, Nick recommends a ticketing system to request changes to the knowledge base. Our current setup is _very_ democratized: anyone can edit anything. There’s pros and cons to each type of system, but the main benefit to the ticketing system is at least a layer of review.
I wish he had more examples and differentiations of the interplay between process “tasks” and tasks that go into your work management tool. It was really unclear to me how you manage the tasks between both systems. Overall the process part of this book was the hardest for me to follow because it seemed so vague and lacking of real concrete examples and how it ties into the other parts of the system. Most of the other sections left me with a pretty good idea of how I would implement the system, but the process section left me wanting more.