diff --git a/docs/tempo/website/operations/deployment.md b/docs/tempo/website/operations/deployment.md
index eada7921a33..26677c6cd53 100644
--- a/docs/tempo/website/operations/deployment.md
+++ b/docs/tempo/website/operations/deployment.md
@@ -52,9 +52,9 @@ which is the single binary deployment mode.
 
 A single binary mode deployment runs all top-level components in a single
 process, forming an instance of Tempo.  The single binary mode is the simplest
-to deploy but cannot but can not horizontally scale.  Refer to
-[Architecture]({{< relref "./architecture" >}}) for descriptions of the
-components.
+to deploy, but cannot horizontally scale out by increasing the quantity of
+components.  Refer to [Architecture]({{< relref "./architecture" >}}) for
+descriptions of the components.
 
 To enable this mode, `-target=all` is used, which is the default.
 
@@ -66,9 +66,10 @@ Find docker-compose deployment examples at:
 ## Scalable single binary
 
 A scalable single binary deployment is similar to the single binary mode in
-that all components are deployed in one binary but it is capable of
-horizontally scaling. This mode offers some flexibility of scaling without the
-complexity of the full microservices deployment.
+that all components are deployed within one binary. Horizontally scale out is
+achieved by instantiating more than one single binary. This mode offers some
+flexibility of scaling without the configuration complexity of the full
+microservices deployment.
 
 Each of the `queriers` will perform a DNS lookup for the `frontend_address` and
 connect to the addresses found within the DNS record.
@@ -82,7 +83,7 @@ Find a docker-compose deployment example at:
 ## Microservices
 
 In microservices mode, components are deployed in distinct processes.  Scaling
-is per component which allows for greater flexibility in scaling and more
+is per component, which allows for greater flexibility in scaling and more
 granular failure domains. This is the preferred method for a production
 deployment, but it is also the most complex
 
diff --git a/integration/microservices/README.md b/integration/microservices/README.md
index 044ebd3c350..2cb60b4bc98 100644
--- a/integration/microservices/README.md
+++ b/integration/microservices/README.md
@@ -1,9 +1,9 @@
 # tempo-load-test
 
-This example aims to make it easier to measure and analyze tempo performance in
-micro-services mode.  There are already many examples for running tempo under
+This example aims to make it easier to measure and analyze Tempo performance in
+micro-services mode.  There are already many examples for running Tempo under
 load, but they use the single-binary approach and are not representative of
-what is occurring in larger installations.  Here tempo is run with separate
+what is occurring in larger installations.  Here Tempo is run with separate
 containers for distributor and ingesters, and replication factor = 3, meaning
 that the distributor will mirror all incoming traces to 3 ingesters.
 
@@ -24,7 +24,7 @@ that the distributor will mirror all incoming traces to 3 ingesters.
 # Instructions
 
 This example is expected to be used in conjunction with tempo development in a
-rapid feedback loop. It is assumed you have a working go installation and a
+rapid feedback loop. It is assumed you have a working Go installation and a
 copy of tempo already cloned somewhere.
 
 1. Build the tempo container
@@ -48,4 +48,4 @@ docker-compose up -d --scale synthetic-load-generator=4
 
 # Key Metrics
 
-As tempo is designed to be very horizontally scalable, the key metrics are _per volume unit_, i.e. spans / s / cpu core.
+As Tempo is designed to be very horizontally scalable, the key metrics are _per volume unit_, i.e. spans / s / cpu core.