Small typos

Author: m-allanson

docs/docs/website-teams.md

@@ -12,7 +12,7 @@ _Take advantage of extended evaluation periods to build a component library_
 
 Larger companies considering adopting Gatsby often plan in terms of migrating multiple sites (or internationalized versions of sites) over a timeframe of a few months to two years. These projects can have long preparation times before active development starts.
 
-One high-leverage activity during these time windows is focus development on a React component library. Then, when development begins the team is able to quickly assemble Gatsby React pages from these pre-built components. Consider designating senior UI developers as "component architects" in this process.
+One high-leverage activity during these time windows is to focus development on a React component library. Then, when development begins the team is able to quickly assemble Gatsby React pages from these pre-built components. Consider designating senior UI developers as "component architects" in this process.
 
 _Consider a less-expensive CMS or multi-modal architecture_
 
@@ -28,13 +28,13 @@ In order to do user testing, usually user researchers work with designers to con
 
 Gatsby makes another option possible. Some Gatsby users report [setting up a production site](https://www.gatsbyjs.org/blog/2018-01-18-how-boston-gov-used-gatsby-to-be-selected-as-an-amazon-hq2-candidate-city/) with live UI that is building and deploying in under an hour.
 
-Especially if your organization already uses a React- or HTML-based component library, your team may consider bringing in a developer to construct live wireframe-level prototypes. This may enable you to accelerate the user research process, start the development process with a working prototype rather than from scratch, and ultimately let you arrive at a better version of your site.
+Especially if your organization already uses a React or HTML-based component library, your team may consider bringing in a developer to construct live wireframe-level prototypes. This may enable you to accelerate the user research process, start the development process with a working prototype rather than from scratch, and ultimately let you arrive at a better version of your site.
 
 ### Development
 
 _Make progress without access to the client CMS_
 
-Sometimes website development teams don't gain access to the client's CMS until development has already started. This can happen for a variety of reasons -- internal client policies, the need to onboard content editors, and so forth. Typically this is a difficult situation where  development can be blocked or delayed, and can leads to timeline slippage, crunch time at the end of the project, and so on.
+Sometimes website development teams don't gain access to the client's CMS until development has already started. This can happen for a variety of reasons -- internal client policies, the need to onboard content editors, and so forth. Typically this is a difficult situation where development can be blocked or delayed, and can lead to timeline slippage, crunch time at the end of the project, and so on.
 
 With Gatsby, the CMS-agnostic development workflow gives teams tools to continue to make progress even without access to client content. One common approach is to develop and prototype UIs pulling placeholder content from markdown files stored in the repo. When the team gains access, it only takes a few lines of code to reconfigure the site to pull content from the CMS.
 
@@ -47,12 +47,12 @@ _Use development pages to communicate project status & collaborate with designer
 One option some teams have found powerful is to create static page components within Gatsby to [handle necessary parts of the development/QA workflow](https://www.gatsbyjs.org/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#1-pre-integration-qa).
 
 This could include:
-* Checking UI implementation of various components to ensure behavior is intended.
+* Checking UI implementation of various components to ensure behavior is intended
 * Enabling QA visibility into desired site-specific page-level validations, such as "don't end a page in a carousel"
-* Communicating build history and last build status.
+* Communicating build history and last build status
 
-_Use branch- and pull request-based artifacts to collaborate on specific pieces of work_
+_Use branch and pull request-based artifacts to collaborate on specific pieces of work_
 
-Using the [branch- and pull request-based artifacts](https://www.gatsbyjs.org/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#building-staging-urls
+Using the [branch and pull request-based artifacts](https://www.gatsbyjs.org/blog/2018-04-11-trying-out-gatsby-at-work-and-co/#building-staging-urls
 ) automatically created by a service like Netlify for collaboration between developers, designers, and QA. Because generated artifacts are static, pull request collaboration workflows are resilient to underlying content schema changes, such as field deletion, that might break a typical CMS development environment.