SSWConsulting · adamcogan · Sep 30, 2023 · Sep 29, 2023 · Sep 29, 2023 · Sep 29, 2023
diff --git a/categories/management/rules-to-successful-projects.md b/categories/management/rules-to-successful-projects.md
@@ -32,6 +32,7 @@ index:
 - do-you-zz-old-files-rather-than-deleting-them
 - do-you-know-the-best-way-of-managing-recurring-tasks
 - do-you-constantly-add-to-the-backlog
+- fix-small-web-errors
 - do-you-have-a-knowledge-base-kb
 - do-you-know-the-best-way-to-give-the-best-customer-support
 - do-you-stop-dealing-with-data-and-schema

diff --git a/rules/continual-improvement/rule.md b/rules/continual-improvement/rule.md
@@ -1,7 +1,6 @@
 ---
 type: rule
-title: Do you know rules are made for the guidance of wise men and the obedience
-  of fools?
+title: Do you know rules are made for the guidance of wise men and the obedience of fools?
 uri: continual-improvement
 authors:
   - title: Adam Cogan
@@ -42,8 +41,8 @@ There are pros and cons to having standards:
 
 If you think something can be done better or the standard is simply out of date, you should improve the standard. This is best done as a team effort with everyone making little changes often. Whenever you come across a standard which needs updating or improving you have three options:
 
-1. Fix it yourself straight away by [editing the rule](https://github.com/SSWConsulting/SSW.Rules.Content/wiki/How-to-Edit-Rules) (preferred)
+1. [Fix it yourself straight away](/fix-small-web-errors) by [editing the rule](https://github.com/SSWConsulting/SSW.Rules.Content/wiki/How-to-Edit-Rules) (preferred)
 2. Fix it yourself later if it's too big. In this case, [send yourself an email](/dones-do-you-send-yourself-emails)
 3. Ask someone else to fix it following the [change "x" to "y"](/do-you-ask-for-content-changes-using-from-x-to-y)
 
-**Never** ignore a potential improvement or expect someone else to work on it.
+**Never** ignore a potential improvement or expect someone else to work on it.
diff --git a/rules/do-you-constantly-add-to-the-backlog/rule.md b/rules/do-you-constantly-add-to-the-backlog/rule.md
@@ -10,7 +10,8 @@ authors:
   url: https://ssw.com.au/people/adam-cogan
 - title: Eric Phan
   url: https://ssw.com.au/people/eric-phan
-related: []
+related:
+- fix-small-web-errors
 redirects: []
 
 ---
@@ -25,7 +26,7 @@ In the course of work everyone encounters bugs or problems. They can be dealt wi
 
 The best solution is to use a combination of 2 and 3.
 
-* If it will take less 15 mins to fix, do it straight away.
+* If it will take less 15 mins to fix, do it [straight away](/fix-small-web-errors).
 * If it will take more time, add the problem to the Product Backlog and email a link to the appropriate person (even if it’s a third party product).
 
 This approach raises the question of priorities. If you hit too many hurdles you continually get diverted from the main task. For example when fixing the Client form you encounter a problem with the Client Contact form which breaks the Products form etc. (This can be described as the "Tree Approach" as opposed to the "Straight through to the Goal approach".)

diff --git a/rules/fix-small-web-errors/rule.md b/rules/fix-small-web-errors/rule.md
@@ -10,6 +10,7 @@ authors:
   url: https://ssw.com.au/people/adam-cogan
 related:
 - rubber-stamp-prs
+- do-you-constantly-add-to-the-backlog
 redirects:
 - efficiency-do-all-your-employees-know-the-quickest-way-to-fix-small-web-errors
 - how-to-fix-small-web-errors