From dd08fa31105e41515b52e91b90240a4df9e8cc87 Mon Sep 17 00:00:00 2001
From: Marius Pana <marius.pana@sphs.ro>
Date: Wed, 11 Jan 2017 09:59:16 +0200
Subject: [PATCH] Deployed ac0e045 with MkDocs version: 0.16.1

---
 CNAME                             |  1 -
 before/different_roles/index.html | 45 ++++++++++++++++---------------
 index.html                        |  1 +
 mkdocs/search_index.json          | 36 ++++++++++++-------------
 sitemap.xml                       | 34 +++++++++++------------
 training/overview/index.html      |  1 +
 6 files changed, 61 insertions(+), 57 deletions(-)
 delete mode 100644 CNAME

diff --git a/CNAME b/CNAME
deleted file mode 100644
index 2dd9fd4..0000000
--- a/CNAME
+++ /dev/null
@@ -1 +0,0 @@
-response.spearhead.systems
\ No newline at end of file
diff --git a/before/different_roles/index.html b/before/different_roles/index.html
index 607d61c..3f25ca2 100644
--- a/before/different_roles/index.html
+++ b/before/different_roles/index.html
@@ -281,14 +281,14 @@
         <ul>
           
             <li class="anchor">
-              <a title="Team Leader (IC)" href="#team-leader-ic">
-                Team Leader (IC)
+              <a title="Team Leader (TL)" href="#team-leader-tl">
+                Team Leader (TL)
               </a>
             </li>
           
             <li class="anchor">
-              <a title="Deputy" href="#deputy">
-                Deputy
+              <a title="Sysadmin" href="#sysadmin">
+                Sysadmin
               </a>
             </li>
           
@@ -466,11 +466,11 @@
           
             <h1>Different Roles</h1>
           
-          <p>There are several roles for our incident response teams at Spearhead Systems. Certain roles only have one person per incident (e.g. support engineer), whereas other roles can have multiple people (e.g.System/Solution Architects,  juniors, etc.). It's all about coming together as a team, working the problem, and getting a solution quickly.</p>
+          <p>There are several roles for our incident response teams at Spearhead Systems. Certain roles only have one person per incident (e.g. support engineer), whereas other roles can have multiple people (e.g. Sysadmins, Solution Architects, etc.). It's all about coming together as a team, working the problem, and getting a solution quickly.</p>
 <p>Here is a rough outline of our role hierarchy, with each role discussed in more detail on the rest of this page.</p>
 <p><img alt="Incident Response Structure" src="../../assets/img/misc/incident_response_roles.png" /></p>
 <hr />
-<h2 id="team-leader-ic">Team Leader (IC)<a class="headerlink" href="#team-leader-ic" title="Permanent link">#</a></h2>
+<h2 id="team-leader-tl">Team Leader (TL)<a class="headerlink" href="#team-leader-tl" title="Permanent link">#</a></h2>
 <h3 id="what-is-it">What is it?<a class="headerlink" href="#what-is-it" title="Permanent link">#</a></h3>
 <p>A Team Leader acts as the single source of truth of what is currently happening and what is going to happen during an major incident. They come in all shapes, sizes, and colors. TL's are also the key elements in a project (boards in DoIT).</p>
 <h3 id="why-have-one">Why have one?<a class="headerlink" href="#why-have-one" title="Permanent link">#</a></h3>
@@ -508,25 +508,27 @@
 <h3 id="how-can-i-become-one">How can I become one?<a class="headerlink" href="#how-can-i-become-one" title="Permanent link">#</a></h3>
 <p>Take a look at our <a href="../../training/incident_commander/">Team Leader training guide</a>.</p>
 <hr />
-<h2 id="deputy">Deputy<a class="headerlink" href="#deputy" title="Permanent link">#</a></h2>
+<h2 id="sysadmin">Sysadmin<a class="headerlink" href="#sysadmin" title="Permanent link">#</a></h2>
 <h3 id="what-is-it_1">What is it?<a class="headerlink" href="#what-is-it_1" title="Permanent link">#</a></h3>
-<p>A Deputy is a direct support role for the Incident Commander. This is not a shadow where the person just observes, the Deputy is expected to perform important tasks during an incident.</p>
+<p>A Sysadmin is a direct support role for the Team Leader. This is not a shadow where the person just observes, the Sysadmin is expected to perform important tasks during an incident.</p>
 <h3 id="why-have-one_1">Why have one?<a class="headerlink" href="#why-have-one_1" title="Permanent link">#</a></h3>
-<p>It's important for the IC to focus on the problem at hand, rather than worrying about documenting the steps or monitoring timers. The deputy helps to support the IC and keep them focussed on the incident.</p>
+<p>It's important for the TL to focus on the problem at hand, rather than worrying about documenting the steps or monitoring timers. The Sysadmin helps to support the TL and keep them stay focussed on the incident.</p>
 <h3 id="what-are-the-responsibilities_1">What are the responsibilities?<a class="headerlink" href="#what-are-the-responsibilities_1" title="Permanent link">#</a></h3>
-<p>The Deputy is expected to:</p>
+<p>The Sysadmin is expected to:</p>
 <ol>
-<li>Bring up issues to the Incident Commander that may otherwise not be addressed (keeping an eye on timers that have been started, circling back around to missed items from a roll call, etc).</li>
-<li>Be a "hot standby" Incident Commander, should the primary need to either transition to a SME, or otherwise have to step away from the IC role.</li>
-<li>Page SME's or other on-call engineers as instructed by the Incident Commander.</li>
-<li>Manage the incident call, and be prepared to remove people from the call if instructed by the Incident Commander.</li>
-<li>Liaise with stakeholders and provide status updates on Slack as necessary.</li>
+<li>Bring up issues to the TL that may otherwise not be addressed (keeping an eye on timers that have been started, circling back around to missed items from a roll call, etc).</li>
+<li>Be a "hot standby" TL, should the primary need to either transition to a SME, or otherwise have to step away from the TL role.</li>
+<li>Page SME's or other on-call engineers as instructed by the Team Leader.</li>
+<li>Manage the incident call, and be prepared to remove people from the call if instructed by the Team Leader.</li>
+<li>Liaise with stakeholders and provide status updates on DoIT (using worklogs and comments), Slack and email/telefone as necessary.</li>
 </ol>
 <h3 id="who-are-they_1">Who are they?<a class="headerlink" href="#who-are-they_1" title="Permanent link">#</a></h3>
-<p>Any Incident Commander can act as a deputy. Deputies need to be trained as an Incident Commander as they may be required to take over command.</p>
+<p>Any Team Leader can act as a Sysadmin. Sysadmins need to be trained as an Team Leader as they may be required to take over command.</p>
 <h3 id="how-can-i-become-one_1">How can I become one?<a class="headerlink" href="#how-can-i-become-one_1" title="Permanent link">#</a></h3>
-<p>Take a look at our <a href="../../training/deputy/">Deputy training guide</a>. Deputies also need to be <a href="../../training/incident_commander/">trained as an Incident Commander</a>.</p>
+<p>Take a look at our <a href="../../training/deputy/">Sysadmin training guide</a>. Sysadmins also need to be <a href="../../training/incident_commander/">trained as an Team Leaders</a>.</p>
 <hr />
+<p>TODO:::move scribe responsibilities to TL and Sysadmin
+::: or assign this to our juniors?</p>
 <h2 id="scribe">Scribe<a class="headerlink" href="#scribe" title="Permanent link">#</a></h2>
 <h3 id="what-is-it_2">What is it?<a class="headerlink" href="#what-is-it_2" title="Permanent link">#</a></h3>
 <p>A Scribe documents the timeline of an incident as it progresses, and makes sure all important decisions and data are captured for later review.</p>
@@ -547,12 +549,13 @@
 <p>Anyone can act as a scribe during an incident, and are chosen by the Incident Commander at the start of the call. Typically the Deputy will act as the Scribe, but that doesn't necessarily need to happen, and for larger incidents may not be possible.</p>
 <h3 id="how-can-i-become-one_2">How can I become one?<a class="headerlink" href="#how-can-i-become-one_2" title="Permanent link">#</a></h3>
 <p>Follow our <a href="../../training/scribe/">Scribe training guide</a>, and then notify the Incident Commanders that you would like to be considered for scribing for the next incident.</p>
+<p>TODO::: END move scribe responsibilities to TL and Sysadmin</p>
 <hr />
 <h2 id="subject-matter-expert">Subject Matter Expert<a class="headerlink" href="#subject-matter-expert" title="Permanent link">#</a></h2>
 <h3 id="what-is-it_3">What is it?<a class="headerlink" href="#what-is-it_3" title="Permanent link">#</a></h3>
-<p>A Subject Matter Expert (SME), sometimes called a "Resolver", is a domain expert or designated owner of a component or service that is part of the PagerDuty software stack.</p>
+<p>A Subject Matter Expert (SME), sometimes called a "Resolver" or "Architect", is a domain expert or designated owner of a component or service that is part of the Spearhead Systems service delivery concept.</p>
 <h3 id="why-have-one_3">Why have one?<a class="headerlink" href="#why-have-one_3" title="Permanent link">#</a></h3>
-<p>The IC and deputy are not all-knowing super beings. When there is a problem with a service, an expert in that service is needed to be able to quickly help identify and fix issues.</p>
+<p>The TL and Sysadmins are not all-knowing super beings. When there is a problem with a service or a particular system, an expert in that service is needed to be able to quickly help identify and fix issues.</p>
 <h3 id="what-are-the-responsibilities_3">What are the responsibilities?<a class="headerlink" href="#what-are-the-responsibilities_3" title="Permanent link">#</a></h3>
 <ol>
 <li>Being able to diagnose common problems with the service.</li>
@@ -576,8 +579,8 @@
 <p>All of the other roles will be actively working on identifying the cause and resolving the issue, we need a role which is focused purely on the customer interaction side of things so that it can be done properly, with the due care and attention it needs.</p>
 <h3 id="what-are-the-responsibilities_4">What are the responsibilities?<a class="headerlink" href="#what-are-the-responsibilities_4" title="Permanent link">#</a></h3>
 <ol>
-<li>Post any publicly facing messages regarding the incident (Twitter, StatusPage, etc).</li>
-<li>Notify the IC of any customers reporting that they are affected by the incident.</li>
+<li>Post any publicly facing messages regarding the incident (DoIT, Twitter, StatusPage, etc).</li>
+<li>Notify the TL of any customers reporting that they are affected by the incident.</li>
 </ol>
 <h3 id="who-are-they_4">Who are they?<a class="headerlink" href="#who-are-they_4" title="Permanent link">#</a></h3>
 <p>Any member of the Support Team can act as a customer liaison.</p>
diff --git a/index.html b/index.html
index 1072cfc..bcedaa2 100644
--- a/index.html
+++ b/index.html
@@ -517,6 +517,7 @@
 <li><a href="http://shop.oreilly.com/product/9780596001308.do">Incident Response</a> (O'Reilly)</li>
 <li><a href="http://extfiles.etsy.com/DebriefingFacilitationGuide.pdf">Debriefing Facilitation Guide</a> (Etsy)</li>
 <li><a href="https://www.fema.gov/national-incident-management-system">US National Incident Management System (NIMS)</a> (FEMA)</li>
+<li><a href="https://www.heavybit.com/library/video/every-minute-counts-coordinating-herokus-incident-response/">Every Minute Counts: Leading Heroku's Incident Response</a> (Blake Gentry)</li>
 </ul>
           <aside class="copyright" role="note">
             
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index e2aa9c0..fb7a687 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -2,7 +2,7 @@
     "docs": [
         {
             "location": "/", 
-            "text": "This documentation covers parts of the Spearhead Systems Issue Response process. It is a copy of \nPagerDuty's\n documentation and furthermore a cut-down version of our own internal documentation, used at Spearhead Systems for any  issue (incident or service request), and to prepare new employees for on-call responsibilities. It provides information not only on preparing for an incident, but also what to do during and after. It is intended to be used by on-call practitioners and those involved in an operational incident response process (or those wishing to enact a formal incident response process). See the \nabout page\n for more information on what this documentation is and why it exists. This documentation is complementary to what is available in our \nexisting wiki\n and may not yet be open sourced.\n\n\n\n\nIssue, Incident and Service Request\n\n\nAt Spearhead we use the term \nissue\n to define any request from our customers. Issues fall into two categories: \"Service Requests (SR)\" and \"Incidents (IN)\". Note that we use the term Incident to describe both a service request as well as incidents. For brevity we will use SR and IN throughout this documentation.\n\n\n\n\nA \"service request\" is usually initiated by a human and is generally not critical for the normal functioning of the business while an \"incident\" is  an issue that is or can cause interruption to normal business functions. \n\n\n\n\nBeing On-Call\n#\n\n\nIf you've never been on-call before, you might be wondering what it's all about. These pages describe what the expectations of being on-call are, along with some resources to help you.\n\n\n\n\nBeing On-Call\n - \nA guide to being on-call, both what your responsibilities are, and what they are not.\n\n\nAlerting Principles\n - \nThe principles we use to determine what things page an engineer, and what time of day they page.\n\n\n\n\nBefore an Incident\n#\n\n\nReading material for things you probably want to know before an incident occurs. You likely don't want to be reading these during an actual incident.\n\n\n\n\nSeverity Levels\n - \nInformation on our severity level classification. What constitutes a Low issue? What's a \"Major Incident\"?, etc.\n\n\nDifferent Roles for Incidents\n - \nInformation on the roles during an incident; Incident Commander, Scribe, etc.\n\n\nIncident Call Etiquette\n - \nOur etiquette guidelines for incident calls, before you find yourself in one.\n\n\n\n\nDuring an Incident\n#\n\n\nInformation and processes during an incident.\n\n\n\n\nDuring an Incident\n - \nInformation on what to do during an incident, and how to constructively contribute.\n\n\nSecurity Incident Response\n - \nSecurity incidents are handled differently to normal operational incidents.\n\n\n\n\nAfter an Incident\n#\n\n\nOur followup processes, how we make sure we don't repeat mistakes and are always improving.\n\n\n\n\nPost-Mortem Process\n - \nInformation on our post-mortem process; what's involved and how to write or run a post-mortem.\n\n\nPost-Mortem Template\n - \nThe template we use for writing our post-mortems for major incidents.\n\n\n\n\nTraining\n#\n\n\nSo, you want to learn about incident response? You've come to the right place.\n\n\n\n\nTraining Overview\n - \nAn overview of our training guides and additional training material from third-parties.\n\n\nIncident Commander Training\n - \nA guide to becoming our next Incident Commander.\n\n\nDeputy Training\n - \nHow to be a deputy and back up the Incident Commander.\n\n\nScribe Training\n - \nA guide to scribing.\n\n\nSubject Matter Expert Training\n - \nA guide on responsibilities and behavior for all participants in a major incident.\n\n\nGlossary of Incident Response Terms\n - \nA collection of terms that you may hear being used, along with their definition.\n\n\n\n\nAdditional Reading\n#\n\n\nUseful material and resources from external parties that are relevant to incident response.\n\n\n\n\nIncident Management for Operations\n (O'Reilly)\n\n\nIncident Response\n (O'Reilly)\n\n\nDebriefing Facilitation Guide\n (Etsy)\n\n\nUS National Incident Management System (NIMS)\n (FEMA)", 
+            "text": "This documentation covers parts of the Spearhead Systems Issue Response process. It is a copy of \nPagerDuty's\n documentation and furthermore a cut-down version of our own internal documentation, used at Spearhead Systems for any  issue (incident or service request), and to prepare new employees for on-call responsibilities. It provides information not only on preparing for an incident, but also what to do during and after. It is intended to be used by on-call practitioners and those involved in an operational incident response process (or those wishing to enact a formal incident response process). See the \nabout page\n for more information on what this documentation is and why it exists. This documentation is complementary to what is available in our \nexisting wiki\n and may not yet be open sourced.\n\n\n\n\nIssue, Incident and Service Request\n\n\nAt Spearhead we use the term \nissue\n to define any request from our customers. Issues fall into two categories: \"Service Requests (SR)\" and \"Incidents (IN)\". Note that we use the term Incident to describe both a service request as well as incidents. For brevity we will use SR and IN throughout this documentation.\n\n\n\n\nA \"service request\" is usually initiated by a human and is generally not critical for the normal functioning of the business while an \"incident\" is  an issue that is or can cause interruption to normal business functions. \n\n\n\n\nBeing On-Call\n#\n\n\nIf you've never been on-call before, you might be wondering what it's all about. These pages describe what the expectations of being on-call are, along with some resources to help you.\n\n\n\n\nBeing On-Call\n - \nA guide to being on-call, both what your responsibilities are, and what they are not.\n\n\nAlerting Principles\n - \nThe principles we use to determine what things page an engineer, and what time of day they page.\n\n\n\n\nBefore an Incident\n#\n\n\nReading material for things you probably want to know before an incident occurs. You likely don't want to be reading these during an actual incident.\n\n\n\n\nSeverity Levels\n - \nInformation on our severity level classification. What constitutes a Low issue? What's a \"Major Incident\"?, etc.\n\n\nDifferent Roles for Incidents\n - \nInformation on the roles during an incident; Incident Commander, Scribe, etc.\n\n\nIncident Call Etiquette\n - \nOur etiquette guidelines for incident calls, before you find yourself in one.\n\n\n\n\nDuring an Incident\n#\n\n\nInformation and processes during an incident.\n\n\n\n\nDuring an Incident\n - \nInformation on what to do during an incident, and how to constructively contribute.\n\n\nSecurity Incident Response\n - \nSecurity incidents are handled differently to normal operational incidents.\n\n\n\n\nAfter an Incident\n#\n\n\nOur followup processes, how we make sure we don't repeat mistakes and are always improving.\n\n\n\n\nPost-Mortem Process\n - \nInformation on our post-mortem process; what's involved and how to write or run a post-mortem.\n\n\nPost-Mortem Template\n - \nThe template we use for writing our post-mortems for major incidents.\n\n\n\n\nTraining\n#\n\n\nSo, you want to learn about incident response? You've come to the right place.\n\n\n\n\nTraining Overview\n - \nAn overview of our training guides and additional training material from third-parties.\n\n\nIncident Commander Training\n - \nA guide to becoming our next Incident Commander.\n\n\nDeputy Training\n - \nHow to be a deputy and back up the Incident Commander.\n\n\nScribe Training\n - \nA guide to scribing.\n\n\nSubject Matter Expert Training\n - \nA guide on responsibilities and behavior for all participants in a major incident.\n\n\nGlossary of Incident Response Terms\n - \nA collection of terms that you may hear being used, along with their definition.\n\n\n\n\nAdditional Reading\n#\n\n\nUseful material and resources from external parties that are relevant to incident response.\n\n\n\n\nIncident Management for Operations\n (O'Reilly)\n\n\nIncident Response\n (O'Reilly)\n\n\nDebriefing Facilitation Guide\n (Etsy)\n\n\nUS National Incident Management System (NIMS)\n (FEMA)\n\n\nEvery Minute Counts: Leading Heroku's Incident Response\n (Blake Gentry)", 
             "title": "Home"
         }, 
         {
@@ -32,7 +32,7 @@
         }, 
         {
             "location": "/#additional-reading", 
-            "text": "Useful material and resources from external parties that are relevant to incident response.   Incident Management for Operations  (O'Reilly)  Incident Response  (O'Reilly)  Debriefing Facilitation Guide  (Etsy)  US National Incident Management System (NIMS)  (FEMA)", 
+            "text": "Useful material and resources from external parties that are relevant to incident response.   Incident Management for Operations  (O'Reilly)  Incident Response  (O'Reilly)  Debriefing Facilitation Guide  (Etsy)  US National Incident Management System (NIMS)  (FEMA)  Every Minute Counts: Leading Heroku's Incident Response  (Blake Gentry)", 
             "title": "Additional Reading"
         }, 
         {
@@ -102,13 +102,13 @@
         }, 
         {
             "location": "/before/different_roles/", 
-            "text": "There are several roles for our incident response teams at Spearhead Systems. Certain roles only have one person per incident (e.g. support engineer), whereas other roles can have multiple people (e.g.System/Solution Architects,  juniors, etc.). It's all about coming together as a team, working the problem, and getting a solution quickly.\n\n\nHere is a rough outline of our role hierarchy, with each role discussed in more detail on the rest of this page.\n\n\n\n\n\n\nTeam Leader (IC)\n#\n\n\nWhat is it?\n#\n\n\nA Team Leader acts as the single source of truth of what is currently happening and what is going to happen during an major incident. They come in all shapes, sizes, and colors. TL's are also the key elements in a project (boards in DoIT).\n\n\nWhy have one?\n#\n\n\nAs any system grows in size and complexity, things break and cause incidents. The TL is needed to help drive major incidents to resolution by organizing his team towards a common goal.\n\n\nWhat are the responsibilities?\n#\n\n\n\n\nHelp prepare for projects and incidents,\n\n\nSetup communications channels.\n\n\nCreate the DoIT board(s) and other project planning related materials.\n\n\nFunnel people to these communications channels.\n\n\nTrain team members on how to communicate and train other TL's.\n\n\n\n\n\n\nDrive incidents and projects to resolution,\n\n\nGet everyone on the same communication channel.\n\n\nCollect information from team members for their services/area of ownership status.\n\n\nCollect proposed repair actions, then recommend repair actions to be taken.\n\n\nDelegate all repair actions, the TL is NOT a resolver.\n\n\nBe the single authority on system status\n\n\nCommunicate directly with the customers and end-users\n\n\nnot the engineers themselves!\n\n\n\n\n\n\n\n\n\n\nPost Mortem,\n\n\nCreating the initial template right after the incident so people can put in their thoughts while fresh.\n\n\nAssigning the post-mortem after the event is over, this can be done after the call.\n\n\nWork with Managers/Support on scheduling preventive actions.\n\n\n\n\n\n\n\n\nWho are they?\n#\n\n\nAnyone on the TL on-call schedule. Trainees are typically on the TL Shadow schedule.\n\n\nHow can I become one?\n#\n\n\nTake a look at our \nTeam Leader training guide\n.\n\n\n\n\nDeputy\n#\n\n\nWhat is it?\n#\n\n\nA Deputy is a direct support role for the Incident Commander. This is not a shadow where the person just observes, the Deputy is expected to perform important tasks during an incident.\n\n\nWhy have one?\n#\n\n\nIt's important for the IC to focus on the problem at hand, rather than worrying about documenting the steps or monitoring timers. The deputy helps to support the IC and keep them focussed on the incident.\n\n\nWhat are the responsibilities?\n#\n\n\nThe Deputy is expected to:\n\n\n\n\nBring up issues to the Incident Commander that may otherwise not be addressed (keeping an eye on timers that have been started, circling back around to missed items from a roll call, etc).\n\n\nBe a \"hot standby\" Incident Commander, should the primary need to either transition to a SME, or otherwise have to step away from the IC role.\n\n\nPage SME's or other on-call engineers as instructed by the Incident Commander.\n\n\nManage the incident call, and be prepared to remove people from the call if instructed by the Incident Commander.\n\n\nLiaise with stakeholders and provide status updates on Slack as necessary.\n\n\n\n\nWho are they?\n#\n\n\nAny Incident Commander can act as a deputy. Deputies need to be trained as an Incident Commander as they may be required to take over command.\n\n\nHow can I become one?\n#\n\n\nTake a look at our \nDeputy training guide\n. Deputies also need to be \ntrained as an Incident Commander\n.\n\n\n\n\nScribe\n#\n\n\nWhat is it?\n#\n\n\nA Scribe documents the timeline of an incident as it progresses, and makes sure all important decisions and data are captured for later review.\n\n\nWhy have one?\n#\n\n\nThe incident commander will need to focus on the problem at hand, and the subject matter experts will need to focus on resolving the incident. It is important to capture a timeline of events as they happen so that they can be reviewed during the post-mortem to determine how well we performed, and so we can accurate determine any additional impact that we might not have noticed at the time.\n\n\nWhat are the responsibilities?\n#\n\n\nThe Scribe is expected to:\n\n\n\n\nEnsure the incident call is being recorded.\n\n\nNote in Slack important data, events, and actions, as they happen. Specifically:\n\n\nKey actions as they are taken (Example: \"prod-server-387723 is being restarted to attempt to remove the stuck lock\")\n\n\nStatus reports when one is provided by the IC (Example: \"We are in SEV-1, service A is currently not processing events due to a stuck lock, X is restarting the app stack, next checkin in 3 minutes\")\n\n\nAny key callouts either during the call or at the ending review (Example: \"Note: (Bob B) We should have a better way to determine stuck locks.\")\n\n\n\n\n\n\n\n\nWho are they?\n#\n\n\nAnyone can act as a scribe during an incident, and are chosen by the Incident Commander at the start of the call. Typically the Deputy will act as the Scribe, but that doesn't necessarily need to happen, and for larger incidents may not be possible.\n\n\nHow can I become one?\n#\n\n\nFollow our \nScribe training guide\n, and then notify the Incident Commanders that you would like to be considered for scribing for the next incident.\n\n\n\n\nSubject Matter Expert\n#\n\n\nWhat is it?\n#\n\n\nA Subject Matter Expert (SME), sometimes called a \"Resolver\", is a domain expert or designated owner of a component or service that is part of the PagerDuty software stack.\n\n\nWhy have one?\n#\n\n\nThe IC and deputy are not all-knowing super beings. When there is a problem with a service, an expert in that service is needed to be able to quickly help identify and fix issues.\n\n\nWhat are the responsibilities?\n#\n\n\n\n\nBeing able to diagnose common problems with the service.\n\n\nBeing able to rapidly fix issues found during an incident.\n\n\nConcise communication skills, specifically for CAN reports:\n\n\nCondition: What is the current state of the service? Is it healthy or not?\n\n\nActions: What actions need to be taken if the service is not in a healthy state?\n\n\nNeeds: What support does the resolver need to perform an action?\n\n\n\n\n\n\n\n\nWho are they?\n#\n\n\nAnyone who is considered a \"domain expert\" can act as a resolver for an incident. Typically the service's primary on-call will act as the SME for that service.\n\n\nHow can I become one?\n#\n\n\nTake a look at our \nSubject Matter Expert training guide\n. You should also discuss with your team and service owner to determine what the requirements are for your particular service.\n\n\n\n\nCustomer Liaison\n#\n\n\nWhat is it?\n#\n\n\nA person responsible for interacting with customers, either directly, or via our public communication channels. Typically a member of the Customer Support team.\n\n\nWhy have one?\n#\n\n\nAll of the other roles will be actively working on identifying the cause and resolving the issue, we need a role which is focused purely on the customer interaction side of things so that it can be done properly, with the due care and attention it needs.\n\n\nWhat are the responsibilities?\n#\n\n\n\n\nPost any publicly facing messages regarding the incident (Twitter, StatusPage, etc).\n\n\nNotify the IC of any customers reporting that they are affected by the incident.\n\n\n\n\nWho are they?\n#\n\n\nAny member of the Support Team can act as a customer liaison.\n\n\nHow can I become one?\n#\n\n\nDiscuss with the Support Team about becoming our next customer liaison.", 
+            "text": "There are several roles for our incident response teams at Spearhead Systems. Certain roles only have one person per incident (e.g. support engineer), whereas other roles can have multiple people (e.g. Sysadmins, Solution Architects, etc.). It's all about coming together as a team, working the problem, and getting a solution quickly.\n\n\nHere is a rough outline of our role hierarchy, with each role discussed in more detail on the rest of this page.\n\n\n\n\n\n\nTeam Leader (TL)\n#\n\n\nWhat is it?\n#\n\n\nA Team Leader acts as the single source of truth of what is currently happening and what is going to happen during an major incident. They come in all shapes, sizes, and colors. TL's are also the key elements in a project (boards in DoIT).\n\n\nWhy have one?\n#\n\n\nAs any system grows in size and complexity, things break and cause incidents. The TL is needed to help drive major incidents to resolution by organizing his team towards a common goal.\n\n\nWhat are the responsibilities?\n#\n\n\n\n\nHelp prepare for projects and incidents,\n\n\nSetup communications channels.\n\n\nCreate the DoIT board(s) and other project planning related materials.\n\n\nFunnel people to these communications channels.\n\n\nTrain team members on how to communicate and train other TL's.\n\n\n\n\n\n\nDrive incidents and projects to resolution,\n\n\nGet everyone on the same communication channel.\n\n\nCollect information from team members for their services/area of ownership status.\n\n\nCollect proposed repair actions, then recommend repair actions to be taken.\n\n\nDelegate all repair actions, the TL is NOT a resolver.\n\n\nBe the single authority on system status\n\n\nCommunicate directly with the customers and end-users\n\n\nnot the engineers themselves!\n\n\n\n\n\n\n\n\n\n\nPost Mortem,\n\n\nCreating the initial template right after the incident so people can put in their thoughts while fresh.\n\n\nAssigning the post-mortem after the event is over, this can be done after the call.\n\n\nWork with Managers/Support on scheduling preventive actions.\n\n\n\n\n\n\n\n\nWho are they?\n#\n\n\nAnyone on the TL on-call schedule. Trainees are typically on the TL Shadow schedule.\n\n\nHow can I become one?\n#\n\n\nTake a look at our \nTeam Leader training guide\n.\n\n\n\n\nSysadmin\n#\n\n\nWhat is it?\n#\n\n\nA Sysadmin is a direct support role for the Team Leader. This is not a shadow where the person just observes, the Sysadmin is expected to perform important tasks during an incident.\n\n\nWhy have one?\n#\n\n\nIt's important for the TL to focus on the problem at hand, rather than worrying about documenting the steps or monitoring timers. The Sysadmin helps to support the TL and keep them stay focussed on the incident.\n\n\nWhat are the responsibilities?\n#\n\n\nThe Sysadmin is expected to:\n\n\n\n\nBring up issues to the TL that may otherwise not be addressed (keeping an eye on timers that have been started, circling back around to missed items from a roll call, etc).\n\n\nBe a \"hot standby\" TL, should the primary need to either transition to a SME, or otherwise have to step away from the TL role.\n\n\nPage SME's or other on-call engineers as instructed by the Team Leader.\n\n\nManage the incident call, and be prepared to remove people from the call if instructed by the Team Leader.\n\n\nLiaise with stakeholders and provide status updates on DoIT (using worklogs and comments), Slack and email/telefone as necessary.\n\n\n\n\nWho are they?\n#\n\n\nAny Team Leader can act as a Sysadmin. Sysadmins need to be trained as an Team Leader as they may be required to take over command.\n\n\nHow can I become one?\n#\n\n\nTake a look at our \nSysadmin training guide\n. Sysadmins also need to be \ntrained as an Team Leaders\n.\n\n\n\n\nTODO:::move scribe responsibilities to TL and Sysadmin\n::: or assign this to our juniors?\n\n\nScribe\n#\n\n\nWhat is it?\n#\n\n\nA Scribe documents the timeline of an incident as it progresses, and makes sure all important decisions and data are captured for later review.\n\n\nWhy have one?\n#\n\n\nThe incident commander will need to focus on the problem at hand, and the subject matter experts will need to focus on resolving the incident. It is important to capture a timeline of events as they happen so that they can be reviewed during the post-mortem to determine how well we performed, and so we can accurate determine any additional impact that we might not have noticed at the time.\n\n\nWhat are the responsibilities?\n#\n\n\nThe Scribe is expected to:\n\n\n\n\nEnsure the incident call is being recorded.\n\n\nNote in Slack important data, events, and actions, as they happen. Specifically:\n\n\nKey actions as they are taken (Example: \"prod-server-387723 is being restarted to attempt to remove the stuck lock\")\n\n\nStatus reports when one is provided by the IC (Example: \"We are in SEV-1, service A is currently not processing events due to a stuck lock, X is restarting the app stack, next checkin in 3 minutes\")\n\n\nAny key callouts either during the call or at the ending review (Example: \"Note: (Bob B) We should have a better way to determine stuck locks.\")\n\n\n\n\n\n\n\n\nWho are they?\n#\n\n\nAnyone can act as a scribe during an incident, and are chosen by the Incident Commander at the start of the call. Typically the Deputy will act as the Scribe, but that doesn't necessarily need to happen, and for larger incidents may not be possible.\n\n\nHow can I become one?\n#\n\n\nFollow our \nScribe training guide\n, and then notify the Incident Commanders that you would like to be considered for scribing for the next incident.\n\n\nTODO::: END move scribe responsibilities to TL and Sysadmin\n\n\n\n\nSubject Matter Expert\n#\n\n\nWhat is it?\n#\n\n\nA Subject Matter Expert (SME), sometimes called a \"Resolver\" or \"Architect\", is a domain expert or designated owner of a component or service that is part of the Spearhead Systems service delivery concept.\n\n\nWhy have one?\n#\n\n\nThe TL and Sysadmins are not all-knowing super beings. When there is a problem with a service or a particular system, an expert in that service is needed to be able to quickly help identify and fix issues.\n\n\nWhat are the responsibilities?\n#\n\n\n\n\nBeing able to diagnose common problems with the service.\n\n\nBeing able to rapidly fix issues found during an incident.\n\n\nConcise communication skills, specifically for CAN reports:\n\n\nCondition: What is the current state of the service? Is it healthy or not?\n\n\nActions: What actions need to be taken if the service is not in a healthy state?\n\n\nNeeds: What support does the resolver need to perform an action?\n\n\n\n\n\n\n\n\nWho are they?\n#\n\n\nAnyone who is considered a \"domain expert\" can act as a resolver for an incident. Typically the service's primary on-call will act as the SME for that service.\n\n\nHow can I become one?\n#\n\n\nTake a look at our \nSubject Matter Expert training guide\n. You should also discuss with your team and service owner to determine what the requirements are for your particular service.\n\n\n\n\nCustomer Liaison\n#\n\n\nWhat is it?\n#\n\n\nA person responsible for interacting with customers, either directly, or via our public communication channels. Typically a member of the Customer Support team.\n\n\nWhy have one?\n#\n\n\nAll of the other roles will be actively working on identifying the cause and resolving the issue, we need a role which is focused purely on the customer interaction side of things so that it can be done properly, with the due care and attention it needs.\n\n\nWhat are the responsibilities?\n#\n\n\n\n\nPost any publicly facing messages regarding the incident (DoIT, Twitter, StatusPage, etc).\n\n\nNotify the TL of any customers reporting that they are affected by the incident.\n\n\n\n\nWho are they?\n#\n\n\nAny member of the Support Team can act as a customer liaison.\n\n\nHow can I become one?\n#\n\n\nDiscuss with the Support Team about becoming our next customer liaison.", 
             "title": "Different Roles"
         }, 
         {
-            "location": "/before/different_roles/#team-leader-ic", 
+            "location": "/before/different_roles/#team-leader-tl", 
             "text": "", 
-            "title": "Team Leader (IC)"
+            "title": "Team Leader (TL)"
         }, 
         {
             "location": "/before/different_roles/#what-is-it", 
@@ -136,33 +136,33 @@
             "title": "How can I become one?"
         }, 
         {
-            "location": "/before/different_roles/#deputy", 
+            "location": "/before/different_roles/#sysadmin", 
             "text": "", 
-            "title": "Deputy"
+            "title": "Sysadmin"
         }, 
         {
             "location": "/before/different_roles/#what-is-it_1", 
-            "text": "A Deputy is a direct support role for the Incident Commander. This is not a shadow where the person just observes, the Deputy is expected to perform important tasks during an incident.", 
+            "text": "A Sysadmin is a direct support role for the Team Leader. This is not a shadow where the person just observes, the Sysadmin is expected to perform important tasks during an incident.", 
             "title": "What is it?"
         }, 
         {
             "location": "/before/different_roles/#why-have-one_1", 
-            "text": "It's important for the IC to focus on the problem at hand, rather than worrying about documenting the steps or monitoring timers. The deputy helps to support the IC and keep them focussed on the incident.", 
+            "text": "It's important for the TL to focus on the problem at hand, rather than worrying about documenting the steps or monitoring timers. The Sysadmin helps to support the TL and keep them stay focussed on the incident.", 
             "title": "Why have one?"
         }, 
         {
             "location": "/before/different_roles/#what-are-the-responsibilities_1", 
-            "text": "The Deputy is expected to:   Bring up issues to the Incident Commander that may otherwise not be addressed (keeping an eye on timers that have been started, circling back around to missed items from a roll call, etc).  Be a \"hot standby\" Incident Commander, should the primary need to either transition to a SME, or otherwise have to step away from the IC role.  Page SME's or other on-call engineers as instructed by the Incident Commander.  Manage the incident call, and be prepared to remove people from the call if instructed by the Incident Commander.  Liaise with stakeholders and provide status updates on Slack as necessary.", 
+            "text": "The Sysadmin is expected to:   Bring up issues to the TL that may otherwise not be addressed (keeping an eye on timers that have been started, circling back around to missed items from a roll call, etc).  Be a \"hot standby\" TL, should the primary need to either transition to a SME, or otherwise have to step away from the TL role.  Page SME's or other on-call engineers as instructed by the Team Leader.  Manage the incident call, and be prepared to remove people from the call if instructed by the Team Leader.  Liaise with stakeholders and provide status updates on DoIT (using worklogs and comments), Slack and email/telefone as necessary.", 
             "title": "What are the responsibilities?"
         }, 
         {
             "location": "/before/different_roles/#who-are-they_1", 
-            "text": "Any Incident Commander can act as a deputy. Deputies need to be trained as an Incident Commander as they may be required to take over command.", 
+            "text": "Any Team Leader can act as a Sysadmin. Sysadmins need to be trained as an Team Leader as they may be required to take over command.", 
             "title": "Who are they?"
         }, 
         {
             "location": "/before/different_roles/#how-can-i-become-one_1", 
-            "text": "Take a look at our  Deputy training guide . Deputies also need to be  trained as an Incident Commander .", 
+            "text": "Take a look at our  Sysadmin training guide . Sysadmins also need to be  trained as an Team Leaders .   TODO:::move scribe responsibilities to TL and Sysadmin\n::: or assign this to our juniors?", 
             "title": "How can I become one?"
         }, 
         {
@@ -192,7 +192,7 @@
         }, 
         {
             "location": "/before/different_roles/#how-can-i-become-one_2", 
-            "text": "Follow our  Scribe training guide , and then notify the Incident Commanders that you would like to be considered for scribing for the next incident.", 
+            "text": "Follow our  Scribe training guide , and then notify the Incident Commanders that you would like to be considered for scribing for the next incident.  TODO::: END move scribe responsibilities to TL and Sysadmin", 
             "title": "How can I become one?"
         }, 
         {
@@ -202,12 +202,12 @@
         }, 
         {
             "location": "/before/different_roles/#what-is-it_3", 
-            "text": "A Subject Matter Expert (SME), sometimes called a \"Resolver\", is a domain expert or designated owner of a component or service that is part of the PagerDuty software stack.", 
+            "text": "A Subject Matter Expert (SME), sometimes called a \"Resolver\" or \"Architect\", is a domain expert or designated owner of a component or service that is part of the Spearhead Systems service delivery concept.", 
             "title": "What is it?"
         }, 
         {
             "location": "/before/different_roles/#why-have-one_3", 
-            "text": "The IC and deputy are not all-knowing super beings. When there is a problem with a service, an expert in that service is needed to be able to quickly help identify and fix issues.", 
+            "text": "The TL and Sysadmins are not all-knowing super beings. When there is a problem with a service or a particular system, an expert in that service is needed to be able to quickly help identify and fix issues.", 
             "title": "Why have one?"
         }, 
         {
@@ -242,7 +242,7 @@
         }, 
         {
             "location": "/before/different_roles/#what-are-the-responsibilities_4", 
-            "text": "Post any publicly facing messages regarding the incident (Twitter, StatusPage, etc).  Notify the IC of any customers reporting that they are affected by the incident.", 
+            "text": "Post any publicly facing messages regarding the incident (DoIT, Twitter, StatusPage, etc).  Notify the TL of any customers reporting that they are affected by the incident.", 
             "title": "What are the responsibilities?"
         }, 
         {
@@ -512,7 +512,7 @@
         }, 
         {
             "location": "/training/overview/", 
-            "text": "Learning about the Spearhead Systems incident response process is an important part of being an effective on-call engineer at Spearhead Systens. This section goes over our training material for the various roles that are involved in our incident response, along with some additional information and training material from government agencies.\n\n\nTraining Guides\n#\n\n\nOur training guides are split up by role, however you are encouraged to read through the training guides even for roles you don't belong to, as it can give you some good insight into how those people will be behaving during major incidents.\n\n\n\n\nIncident Commander Training\n - The \"IC\" is the person who drives a major incident to resolution. They're the person who will be directing everyone else.\n\n\nDeputy Training\n - The Deputy is someone who supports the Incident Commander and can take over for them if necessary.\n\n\nScribe Training\n - This is intended for individuals who will be acting as a scribe during an incident.\n\n\nSME / Resolver Training\n - This is relevant to everyone at Spearhead Systems who are on-call for any team.\n\n\n\n\nNational Incident Management System (NIMS)\n#\n\n\nOur incident response process is loosely based on the \nUS National Incident Management System (NIMS)\n, which is described as,\n\n\nA systematic, proactive approach to guide departments and agencies at all levels of government, nongovernmental organizations, and the private sector to work together seamlessly and manage incidents involving all threats and hazards\u2014regardless of cause, size, location, or complexity\u2014in order to reduce loss of life, property and harm to the environment.\n\n\nWhile it might not initially seem that this would be applicable to an IT operations environment, we've found that many of the lessons learned from major incidents in these situations can be directly applied to our industry too. The principles are the same and span many different environments.\n\n\n \n\n\nIf you want to learn more about NIMS, we recommend the \nICS-100\n and \nICS-700\n online training courses, which go over NIMS and the Incident Command System (You can also take an online examination after training in order to get a certificate from FEMA). There is also a wealth of \nadditional training material and courses from FEMA\n on NIMS, which I would encourage you to look at.\n\n\nAlso take a look at the \nAdditional Reading\n section on the home page.", 
+            "text": "Learning about the Spearhead Systems incident response process is an important part of being an effective on-call engineer at Spearhead Systens. This section goes over our training material for the various roles that are involved in our incident response, along with some additional information and training material from government agencies.\n\n\nTraining Guides\n#\n\n\nOur training guides are split up by role, however you are encouraged to read through the training guides even for roles you don't belong to, as it can give you some good insight into how those people will be behaving during major incidents.\n\n\n\n\nIncident Commander Training\n - The \"IC\" is the person who drives a major incident to resolution. They're the person who will be directing everyone else.\n\n\nDeputy Training\n - The Deputy is someone who supports the Incident Commander and can take over for them if necessary.\n\n\nScribe Training\n - This is intended for individuals who will be acting as a scribe during an incident.\n\n\nSME / Resolver Training\n - This is relevant to everyone at Spearhead Systems who are on-call for any team.\n\n\n\n\nNational Incident Management System (NIMS)\n#\n\n\nOur incident response process is loosely based on the \nUS National Incident Management System (NIMS)\n, which is described as,\n\n\nA systematic, proactive approach to guide departments and agencies at all levels of government, nongovernmental organizations, and the private sector to work together seamlessly and manage incidents involving all threats and hazards\u2014regardless of cause, size, location, or complexity\u2014in order to reduce loss of life, property and harm to the environment.\n\n\nWhile it might not initially seem that this would be applicable to an IT operations environment, we've found that many of the lessons learned from major incidents in these situations can be directly applied to our industry too. The principles are the same and span many different environments.\n\n\n \n\n\nIf you want to learn more about NIMS, we recommend the \nICS-100\n and \nICS-700\n online training courses, which go over NIMS and the Incident Command System (You can also take an online examination after training in order to get a certificate from FEMA). There is also a wealth of \nadditional training material and courses from FEMA\n on NIMS, which I would encourage you to look at.\n\n\nIf you're based in the US and interested in taking a more active incident response role in your community, we recommend investigating your local \nCERT programs\n (Community Emergency Response Teams). Many cities offer CERT training, after which you can volunteer as a CERT contributor within your community. Not only is it an opportunity to get real world experience with disaster response, but the skills you learn can be applied to everyday life too.\n\n\nAlso take a look at the \nAdditional Reading\n section on the home page.", 
             "title": "Overview"
         }, 
         {
@@ -522,7 +522,7 @@
         }, 
         {
             "location": "/training/overview/#national-incident-management-system-nims", 
-            "text": "Our incident response process is loosely based on the  US National Incident Management System (NIMS) , which is described as,  A systematic, proactive approach to guide departments and agencies at all levels of government, nongovernmental organizations, and the private sector to work together seamlessly and manage incidents involving all threats and hazards\u2014regardless of cause, size, location, or complexity\u2014in order to reduce loss of life, property and harm to the environment.  While it might not initially seem that this would be applicable to an IT operations environment, we've found that many of the lessons learned from major incidents in these situations can be directly applied to our industry too. The principles are the same and span many different environments.     If you want to learn more about NIMS, we recommend the  ICS-100  and  ICS-700  online training courses, which go over NIMS and the Incident Command System (You can also take an online examination after training in order to get a certificate from FEMA). There is also a wealth of  additional training material and courses from FEMA  on NIMS, which I would encourage you to look at.  Also take a look at the  Additional Reading  section on the home page.", 
+            "text": "Our incident response process is loosely based on the  US National Incident Management System (NIMS) , which is described as,  A systematic, proactive approach to guide departments and agencies at all levels of government, nongovernmental organizations, and the private sector to work together seamlessly and manage incidents involving all threats and hazards\u2014regardless of cause, size, location, or complexity\u2014in order to reduce loss of life, property and harm to the environment.  While it might not initially seem that this would be applicable to an IT operations environment, we've found that many of the lessons learned from major incidents in these situations can be directly applied to our industry too. The principles are the same and span many different environments.     If you want to learn more about NIMS, we recommend the  ICS-100  and  ICS-700  online training courses, which go over NIMS and the Incident Command System (You can also take an online examination after training in order to get a certificate from FEMA). There is also a wealth of  additional training material and courses from FEMA  on NIMS, which I would encourage you to look at.  If you're based in the US and interested in taking a more active incident response role in your community, we recommend investigating your local  CERT programs  (Community Emergency Response Teams). Many cities offer CERT training, after which you can volunteer as a CERT contributor within your community. Not only is it an opportunity to get real world experience with disaster response, but the skills you learn can be applied to everyday life too.  Also take a look at the  Additional Reading  section on the home page.", 
             "title": "National Incident Management System (NIMS)"
         }, 
         {
diff --git a/sitemap.xml b/sitemap.xml
index 076d9b8..48c31d0 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -4,7 +4,7 @@
     
     <url>
      <loc>https://response.spearhead.systems/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -13,13 +13,13 @@
         
     <url>
      <loc>https://response.spearhead.systems/oncall/being_oncall/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/oncall/alerting_principles/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -29,19 +29,19 @@
         
     <url>
      <loc>https://response.spearhead.systems/before/severity_levels/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/before/different_roles/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/before/call_etiquette/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -51,13 +51,13 @@
         
     <url>
      <loc>https://response.spearhead.systems/during/during_an_incident/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/during/security_incident_response/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -67,13 +67,13 @@
         
     <url>
      <loc>https://response.spearhead.systems/after/post_mortem_process/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/after/post_mortem_template/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -83,37 +83,37 @@
         
     <url>
      <loc>https://response.spearhead.systems/training/overview/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/training/incident_commander/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/training/deputy/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/training/scribe/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/training/subject_matter_expert/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://response.spearhead.systems/training/glossary/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -122,7 +122,7 @@
     
     <url>
      <loc>https://response.spearhead.systems/about/</loc>
-     <lastmod>2017-01-10</lastmod>
+     <lastmod>2017-01-11</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
diff --git a/training/overview/index.html b/training/overview/index.html
index a7f1f4f..82ea42b 100644
--- a/training/overview/index.html
+++ b/training/overview/index.html
@@ -463,6 +463,7 @@
 <p>While it might not initially seem that this would be applicable to an IT operations environment, we've found that many of the lessons learned from major incidents in these situations can be directly applied to our industry too. The principles are the same and span many different environments.</p>
 <p><a href="https://www.fema.gov/pdf/emergency/nims/NIMS_core.pdf"><img alt="NIMS" src="../../assets/img/thumbnails/nims_core.png" /></a> <a href="https://www.fema.gov/pdf/emergency/nims/nims_training_program.pdf"><img alt="NIMS Training" src="../../assets/img/thumbnails/nims_training.png" /></a></p>
 <p>If you want to learn more about NIMS, we recommend the <a href="https://training.fema.gov/is/courseoverview.aspx?code=IS-100.b">ICS-100</a> and <a href="https://training.fema.gov/is/courseoverview.aspx?code=IS-700.a">ICS-700</a> online training courses, which go over NIMS and the Incident Command System (You can also take an online examination after training in order to get a certificate from FEMA). There is also a wealth of <a href="https://training.fema.gov/nims/">additional training material and courses from FEMA</a> on NIMS, which I would encourage you to look at.</p>
+<p>If you're based in the US and interested in taking a more active incident response role in your community, we recommend investigating your local <a href="https://www.fema.gov/community-emergency-response-teams">CERT programs</a> (Community Emergency Response Teams). Many cities offer CERT training, after which you can volunteer as a CERT contributor within your community. Not only is it an opportunity to get real world experience with disaster response, but the skills you learn can be applied to everyday life too.</p>
 <p>Also take a look at the <a href="../../#additional-reading">Additional Reading</a> section on the home page.</p>
           <aside class="copyright" role="note">