diff --git a/doc/deployment/backing_services.md b/doc/deployment/backing_services.md
index 83204a76..92540936 100644
--- a/doc/deployment/backing_services.md
+++ b/doc/deployment/backing_services.md
@@ -4,14 +4,14 @@ Here you will find information about the backing services used by Zuul and Nodep
 
 ## Table of Contents
 
-1. Philosophy
-1. MariaDB
-1. ZooKeeper
+1. [Philosophy](#philosophy)
+1. [MariaDB](#mariadb)
+1. [ZooKeeper](#zookeeper)
 
 ## Philosophy
 
-The goal of SF-Operator is to provide a Zuul-based CI infrastructure on OpenShift with the least
-friction possible. With that in mind, we decided to minimize the prerequisites to deployment, and
+The goal of SF-Operator is to provide a Zuul-based CI infrastructure on OpenShift with as little
+friction as possible. With that in mind, we decided to minimize the prerequisites to deployment, and
 thus decided to integrate "barebones" deployments of the backing services required by Zuul and Nodepool.
 
 The pros are:
@@ -24,7 +24,9 @@ The cons are:
 * Lifecycle support for these backing services is minimal (deployment, updates) compared to what a
 proper operator-backed deployment could offer (see for example [what the mariadb-operator can do](https://mariadb.org/mariadb-in-kubernetes-with-mariadb-operator/)).
 
-In other words, for backing services deployed as statefulsets, it is always possible to modify the replicas amount directly in their manifests, but SF-Operator will not act upon it - for example increasing mariadb's replicas will not set up a primary node and replica nodes like a dedicated mariadb operator would. You will only end up with one node being used by Zuul, and the rest using up resources for nothing.
+In other words, for backing services deployed as statefulsets, it is always possible to modify the replicas amount directly in their manifests, **but SF-Operator will not act upon it** - for example increasing mariadb's replicas will not set up a primary node and replica nodes like a dedicated mariadb operator would. You will only end up with one node being used by Zuul, and the rest using up resources for nothing.
+
+Generally speaking, the backing services are best left untouched and managed by the SF Operator.
 
 ## MariaDB