Update Coder links

.vscode/settings.json

@@ -0,0 +1,6 @@
+{
+    "cSpell.words": [
+        "DORC",
+        "SADMF"
+    ]
+}

content/Metrics/_index.md

@@ -10,19 +10,19 @@ weight: 5
 
 ## Lines of code per Coder
 
- We need to ensure our Coders are focused on the feature for the next convoy. The fleet won't wait! We also need to ensure we have balanced metrics to prevent a perverse incentive when we track who created defects. If we only track defects, the Coder may try to assume the role of Unit Tester. That wastes time. Therefore, we need to measure the lines of code produced by each Coder.
+ We need to ensure our Coders are focused on the feature for the next convoy. The fleet won't wait! We also need to ensure we have balanced metrics to prevent a perverse incentive when we track who created defects. If we only track defects, the [Coder](../organization/#coder) may try to assume the role of Unit Tester. That wastes time. Therefore, we need to measure the lines of code produced by each [Coder](../organization/#coder).
 
 ## Number of code review comments per convoy
 
-Code review is important to make sure code is formatted correctly. We measure the number of review comments to make sure each Coder is being critical enough of the work of other Coders.
+Code review is important to make sure code is formatted correctly. We measure the number of review comments to make sure each [Coder](../organization/#coder) is being critical enough of the work of others.
 
 ## Tasks delivered per Coder
 
-For each Coder, the number of tasks they complete during Convoy. By tracking the number of features each Coder completes, more can be shipped in each Convoy. Volume is important. Let's turn it up to 11!
+For each [Coder](../organization/#coder), the number of tasks they complete during Convoy. By tracking the number of features each [Coder](../organization/#coder) completes, more can be shipped in each Convoy. Volume is important. Let's turn it up to 11!
 
 ## Defects created by Coder
 
-For each Coder, we should track the number of defects they create and use this information to inform the *[**Tribunal**](../release-convoy/#tribunal)*. We must *[**Build Quality In**](../principles/#build-quality-in)* by eliminating the source of defects.
+For each [Coder](../organization/#coder), we should track the number of defects they create and use this information to inform the *[**Tribunal**](../release-convoy/#tribunal)*. We must *[**Build Quality In**](../principles/#build-quality-in)* by eliminating the source of defects.
 
 ## Defects detected by Testers
 

content/Organization/_index.md

@@ -6,31 +6,35 @@ weight: 5
 
 ## Organizational Command Structure
 
+### Coder
+
+This role is the backbone of a SAD implementation. The job of the Coder is to transform requirements into machine executable instructions quickly, quietly, and with as few questions as possible.
+
+### Quality Authority
+
+Verifying quality is a specialist field that no [Coder](#coder) is qualified to perform. In addition, performing testing impedes the ability of the [Coder](#coder) to do their only job, type code. The Quality Authority team is the final arbiter of what the requirements mean and will create, maintain, and manually execute test scripts based on their understanding of the requirements. The end-user uses the system manually, so that is the only TRUE way to test it!
+
 ### DevOps Usage & Compliance Head Engineer
 
 If the *Right Way* to do DevOps is not owned and controlled by a single senior manager, nobody will do it. So, we need a named person to codify the *Right Way* in the DevOps Process Binder and hold all teams accountable to the DevOps Process Excellence assessment. By staffing this role we prevent process drift and eventual mutation of the *Right Way*.
 
 ### Feature Team
 
-The Feature Team is the group of Coders who are assembled to build a new feature for the next Convoy. Because we work so diligently to *[**Build Quality In**](../principles/#build-quality-in)* with the *[**Tribunal**](../release-convoy/#tribunal)*, these teams should be able to deliver at maximum throughput as soon as they are formed.
+The Feature Team is the group of Coders assembled to build a new feature for the next Convoy. Because we work so diligently to *[**Build Quality In**](../principles/#build-quality-in)* with the *[**Tribunal**](../release-convoy/#tribunal)*, these teams should be able to deliver at maximum throughput as soon as they are formed.
 
 ### Source Management Team
 
-To improve Coder productivity by reducing the work required for integrating changes, we introduce the Source Management Team. The SMT is responsible for authorizing new *[**feature branches**](../practices/#fractal-based-development)*, creating the branches, and merging the complete branches from each Coder into the Conflict Arbitration branch. They will then resolve all conflicts for the Coders before alerting the Quality Control team that the Convoy is ready for testing.
+To improve [Coder](#coder) productivity by reducing the work required for integrating changes, we introduce the Source Management Team. The SMT is responsible for authorizing new *[**feature branches**](../practices/#fractal-based-development)*, creating the branches, and merging the complete branches from each [Coder](#coder) into the Conflict Arbitration branch. They will then resolve all conflicts for the Coders before alerting the [Quality Authority](#quality-authority) that the Convoy is ready for testing.
 
 ### Code Standards Enforcement Team
 
 Coders are too close to the problem to effectively review code for their Feature Team. Additionally, reviewing code takes time away from coding. To resolve this, the CSET is formed to perform all code reviews. The CSET is also responsible for defining and enforcing all coding standards for the enterprise. This includes, but is not limited to:
 
 * Indentation depth
 * Using tabs vs. spaces
-* Use of *[**EARB**](#enterprise-architecture-review-board)* approved variable and method names
+* Use of approved *[**EARB**](#enterprise-architecture-review-board)* variable and method names
 * Comment format
 
-### Quality Authority
-
-Verifying quality is a specialist field that no Coder is qualified to perform. In addition, performing testing impedes the ability of the Coder to do their only job, type code. The Quality Authority team is the final arbiter of what the requirements mean and will create, maintain, and manually execute test scripts based on their understanding of the requirements. The end-user uses the system manually, so that is the only TRUE way to test it!
-
 ### Enterprise Architecture Review Board
 
 The EARB is responsible for maintaining the Book of Names. This master list defines all acceptable words and word combinations that may be used for naming things during coding. This ensures that Coders will not be confused when they join a new Feature Team for the next Convoy. The EARB will meet every 6 weeks to review and reject any new words submitted for inclusion.

content/Principles/_index.md

@@ -6,23 +6,23 @@ weight: 5
 
 #### Build Quality In
 
-Quality software comes from quality people. Poor quality software must therefore come from poor quality people. To improve the quality of our software, we remove the things that create defects.
+Quality software comes from quality people. Poor quality software must therefore come from poor quality people. To improve the quality of our software, we remove the things that reduce quality.
 
 #### Work in Small Batches
 
-Too many releases are hard to report and manage. To reduce the number of updates to the release tracking spreadsheet, we produce a small number of releases per month. This provides us with more time to *[**Amplify Feedback**](#amplify-feedback)*.
+Too many releases are hard to report and manage. To reduce the number of updates to the release tracking spreadsheet, we should focus on a small number of releases each quarter. This provides us with more time to *[**Amplify Feedback**](#amplify-feedback)*.
 
 #### Amplify Feedback
 
 Coaching employees is an important daily practice to ensure they know we are tracking their work and care about their output.
 
 #### Everyone is Responsible
 
-Each person is responsible for their individual work and should be rewarded for the work they do. If a feature is successfully delivered, we should identify the Coder who made the most changes and give them a bonus. It would be unfair to reward the whole team based on the excellence of an individual.
+Each [Coder](../organization/#coder) is responsible for their own work and should be rewarded for the work they do. If a feature is successfully delivered, we should identify the [Coder](../organization/#coder) who made the most changes and give them a bonus. It would be unfair to reward the whole team based on the excellence of an individual.
 
 #### Psychological Safety
 
-We know the *[**Tribunal**](../release-convoy/#tribunal)* can be a stressful time when we need to remove Coders. We will use automated systems for "Human Resources as a Service" to automatically help Coders find new opportunities outside our company so we can avoid confrontation.
+We know the *[**Tribunal**](../release-convoy/#tribunal)* can be a stressful time. When we need to remove Coders, we will use "Human Resources as a Service" where individual performance data is used to automatically help Coders find new opportunities outside our company. This allows us to avoid confrontation.
 
 #### Systems Thinking
 
@@ -32,11 +32,11 @@ A system will produce exactly what is designed to produce -- W. Edward Demming
 
 The Scaled Agile DevOps Maturity Framework is built upon systems thinking. There are two systems that operate within the SADMF System. The *[**System of Authority**](#system-of-authority)* (SOA) and the *[**System of Service**](#system-of-service)* (SOS). Both Systems are accountable to the Admiral's Transformation Office (ATO).
 
-- **System of Authority**: The SOA is the team of teams accountable for implanting SADMF in your organization. The SOA is staffed by contractors and consultants with diverse points of view. These principled practitioners will focus on implementing the orders of the ATO, and will focus on updating plans, collecting metrics, assessing, and becoming a trusted advisor for the teams so the advisor can report the ground-level truth to leadership during the tribunal.
-- **System of Service**: The SOS is the team of teams accountable for achieving deadlines and shipping code. The SOS will look to the chain of command for servant leadership to ensure self-governance and instruct the Feature Teams on their day-to-day work. The SOS is empowered to deliver on time and on budget predictably.
-- **Admirals Transformation Office**: The ATO is the heartbeat of the transformation, it is the command-and-control center to ensure everyone is achieving the goals of SADMF. It is accountable for the 5-8 transformation roadmap, assessments, metrics, certification renewals, and general project management of the transformation. The ATO is led by the Admiral, who commands all direction, innovation, and methodology implemented at scale.
+- **Admirals Transformation Office (ATO)**: This is the heartbeat of the transformation, it is the command-and-control center to ensure everyone is achieving the goals of SADMF. It is accountable for the 5-8 transformation roadmap, assessments, metrics, certification renewals, and general project management of the transformation. The ATO is led by the Admiral, who commands all direction, innovation, and methodology implemented at scale.
+- **System of Authority (SOA)**: This is the team of teams accountable for implanting SADMF in your organization. The SOA is staffed by contractors and consultants with diverse points of view. These principled practitioners will focus on implementing the orders of the ATO and will focus on updating plans, collecting metrics, assessing, and becoming trusted advisors for the teams so they can report the ground-level truth to leadership during the tribunal.
+- **System of Service (SOS)**: This is the team of teams accountable for achieving deadlines and shipping code. The SOS will look to the chain of command for servant leadership to ensure self-governance and instruct the Feature Teams on their day-to-day work. The SOS is empowered to predictably deliver on time and on budget.
 
 ---
 
 {{% button href="../certifications" %}}🏅 Get Certified! 🏅{{% /button %}}
-{{% button href="https://www.teepublic.com/t-shirt/25575514-scaled-agile-devops-maturity-framework" %}}💸 Official Swag! 💸{{% /button %}}
+{{% button href="https://www.teepublic.com/t-shirt/25575514-scaled-agile-devops-maturity-framework" %}}💸 Official Swag! 💸{{% /button %}}

content/Release Convoy/_index.md

@@ -21,6 +21,7 @@ Below are the simple ceremonies required to manage changes in the SADMF way!
 [This is a 5-day meeting](./convoy-alignment-agenda) held every 6 weeks for planning the next 8 quarters of features to make sure the critical paths are aligned. See the agenda for details.
 
 #### Captain's Mast
+
 In this ceremony, anyone wishing to change the priorities set in Convoy Alignment must file a *[***PCR***](../convoy-manifest/#priority-change-request)* and represent it for approval. This allows the Chief Signals Officer to adjust the *[***Completed vs Committed***](../metrics/#features-completed-vs-committed)* goal to ensure it does not reflect poorly on the Commodore.
 
 #### Captains' Meeting
@@ -29,7 +30,7 @@ Meeting of the Feature Captains to plan the date when the DORC™ will be as
 
 ### Press Gang
 
-In the Press Gang step, the Feature Captain will choose between 2 and 20 people from the coding pool to "self-organize" around delivering the next feature. This ensures each Coder is allowed to work on new and interesting things and that all Coders are fully utilized.
+In the Press Gang step, the Feature Captain will choose between 2 and 20 people from the coding pool to "self-organize" around delivering the next feature. This ensures each [Coder](../organization/#coder) is allowed to work on new and interesting things and that all Coders are fully utilized.
 
 ### Post-Standup Standup