diff --git a/packages/bazel/src/schematics/README.md b/packages/bazel/src/schematics/README.md
index b685a22c2c..b97fc37406 100644
--- a/packages/bazel/src/schematics/README.md
+++ b/packages/bazel/src/schematics/README.md
@@ -1,32 +1,34 @@
 # Schematics for Bazel
 
-Bazel builder for Angular CLI has been deprecated.
+Bazel builder for Angular CLI has been deprecated in version 10.
 
-We believe that a lot of projects would benefit from directly using Bazel, the same way we do in Angular. Validating the experimental Bazel schematics for the Angular CLI for the past year as part of Angular Labs, we concluded that they don't implement the most optimal approach. In v10, we're deprecating `@angular/bazel` and encouraging developers to explore using Bazel directly following the [canonical example](https://github.com/bazelbuild/rules_nodejs/tree/master/examples/angular).
+We believe that a lot of projects would benefit from using Bazel, the same way
+we do in the Angular repository. We still believe that is true in many cases.
+However, after experimenting with Bazel schematics for Angular CLI in
+Angular Labs for the past year, we concluded that invoking Bazel from within
+CLI is not the best approach to encourage adoption of the technology.
+Instead, we recommend developers to explore using Bazel directly, and refer to
+the canonical example [repository](https://github.com/bazelbuild/rules_nodejs/tree/master/examples/angular)
+for latest updates and best practices.
 
-Using the Bazel builder, we abstracted the build file management and tooling orchestration, making Bazel invisible for developers.
+In the beginning of this project, we thought it would make Bazel easier for
+users to adopt if we abstracted the BUILD files management and tooling
+orchestration within Angular CLI. However, we have come to realize that such
+abstraction does not encourage users to use Bazel to its full potential.
 
-Through this experiment, we found that wrapping Bazel into Angular CLI does currently not meet our expectation of providing a great experience to developers.
-
-
-There are a few reasons we're taking this path:
+There are a few other reasons for this deprecation:
 
 1. Bazel ecosystem for the Web is still evolving at a rapid pace.
-2. The introduction of the Angular Ivy compiler enables new ways to use Bazel in a faster
-   and more efficient manner.
-3. Feature parity with Webpack based Angular CLI is currently difficult to achieve without trade-offs that would not be acceptable for many Angular users.
-
-For users who are currently using Bazel builder, there are a few migration
-options.
-
-
-
+2. The introduction of the Angular Ivy compiler enables new ways to use Bazel
+   in a faster and more efficient manner (see below).
+3. Feature parity with Webpack-based Angular CLI is difficult to achieve without
+   trade-offs that would not be acceptable for many Angular users.
 
 ## Migrate from `@angular/bazel`
 
 For users who are currently using Bazel builder, there are a few migration options.
 
-### Eject the build config
+### Eject the BUILD files
 
 You could leave the Bazel files in your workspace, and manage them manually:
 
@@ -34,7 +36,10 @@ You could leave the Bazel files in your workspace, and manage them manually:
 ng build --leaveBazelFilesOnDisk
 ```
 
-If you're using Ivy, in your build files replace `ng_module` with the [`ng_ts_library`](https://github.com/bazelbuild/rules_nodejs/blob/master/examples/angular/tools/angular_ts_library.bzl) rule. This new rule leverages ngtsc plugin supported by `ts_library`, and it is much faster.
+If you're using Ivy, in your BUILD files replace `ng_module` with the
+[`ng_ts_library`](https://github.com/bazelbuild/rules_nodejs/blob/master/examples/angular/tools/angular_ts_library.bzl)
+rule.
+This new rule leverages ngtsc plugin supported by `ts_library`, and it is much faster.
 
 For the latest recommendations, please refer to the canonical Angular Bazel [repo](https://github.com/bazelbuild/rules_nodejs/tree/master/examples/angular).