diff --git a/handbook/company/README.md b/handbook/company/README.md
index ccef55995f..0df6ba53b6 100644
--- a/handbook/company/README.md
+++ b/handbook/company/README.md
@@ -235,15 +235,16 @@ Investing in people and providing generous, prioritized training, especially up
 
 
 ### Why not continuously generate REST API reference docs from javadoc-style code comments?
-We prefer to generate our REST API reference docs the good old-fashioned way. By hand. Here are a few of the drawbacks that we have experienced when generating docs via tools like Swagger or OpenAPI and some plus ones for doing it by hand with Markdown.
+Here are a few of the drawbacks that we have experienced when generating docs via tools like Swagger or OpenAPI, and some of the advantages of doing it by hand with Markdown.
 
 - Markdown gives us more control over how the docs are compiled, what annotations we can include, and how we present the information to the end-user. 
 - Markdown is more accessible. Anyone can edit Fleet's docs directly from our website without needing coding experience. 
-- A single Markdown file reduces the amount of surface area to manage that comes from spreading code comments across multiple files throughout the codebase. (see ["Why do we use one repo?"](#why-do-we-use-one-repo)). 
-- Generated docs can become just as outdated as handmade docs, except since they are generated, they become siloed and more difficult to edit.
+- A single Markdown file reduces the amount of surface area to manage that comes from spreading code comments across multiple files throughout the codebase. (see ["Why do we use one repo?"](#why-do-we-use-one-repo)).
+- Autogenerated docs can become just as outdated as handmade docs, except since they are siloed, they require more skills to edit.
+- When docs live at separate repo paths from source code, we are able to automate approval processes that allow contributors to make small improvements and notes, directly from the website.  This [leads to more contributions](https://github.com/balderdashy/sails-docs/network/members), since it lowers the barrier of entry for [becoming a contributor](https://fleetdm.com/docs/contributing/committing-changes).
 - Autogenerated docs are typically hosted on a subdomain. This means we have less control over a user's journey through our website and lose the SEO benefits of self-hosted documentation.
-- Autogenerating docs from code is not always the best way to make sure reference docs accurately reflect the API. Based on our experience from past projects, we've learned that the benefits of generated docs do not outweigh the drawbacks of creating them by hand.
-- As the Fleet REST API, documentation, and tools mature, a more declarative format such as OpenAPI might become the source of truth, but only after investing in a format and processes to make it visible, accessible, and modifiable for all contributors.
+- Autogenerating docs from code comments is not always the best way to make sure reference docs accurately reflect the API.
+- As the Fleet REST API, documentation, and tools mature, a more declarative format such as OpenAPI might become the source of truth, but only after investing in a format and processes to make it continually accurate as well as visible, accessible, and modifiable for all contributors.
 
 
 ### Why handbook-first strategy?