Merge pull request #60 from wayfair-incubator/cantonellis_failure_modes

first pass on failure modes doc

src/docs/theory/failure_modes.md

@@ -3,16 +3,50 @@ title: "Failure Modes"
 featured: ../images/featured/theory.png
 ---
 
-## WORK IN PROGRESS NOTES
+An Auxiliary Engagement is a hopeful endeavor; there is no guarantee of success.
+An engagement can suffer from a number of failure modes, some easier to identify
+than others. The failure modes are typical of all software engineering, but can
+be especially potent in this context given the short timeline of an engagement.
 
-- Typical failure modes of software engineering
-- AuxEng Doing the hard work, building dependency
-- Not investing upfront in scaffolding
-- Disconnect between team and leadership
-  - Leaders want AuxEng, but the team doesn't
-- AuxEng feeling like an outsider
-- Lack of improvements to Platform layer
-- Lack of psychological safety in retros
-  - Welcome and reward critical feedback
-- Being just "embedded engineering"
-- Bad ratio of AuxEng to team members (1to6 is upper bound)
+1. **Auxiliary Engineer does all the hard work**  
+    If the embedded engineer finds themselves solving hard problems in isolation,
+    without opportunities to pair, teach, or share, this is a cause for concern.
+    The embedded engineer should be pairing on large problems and sharing
+    decision-making  with the team, not operating as a contractor.
+
+1. **Auxiliary Engineer does not feel welcome**  
+    If the embedded engineer does not feel psychologically safe on the team, this
+    is a cause for concern. The embedded engineer should feel able to share their
+    opinions openly during code reviews, retros, and other communication with
+    team members or leadership. If this is not the case, this seriously affects
+    the embedded engineers ability to affect change within the team by limiting
+    the engineers ability to provide negative feedback. Negative feedback can be
+    instrumental in affecting change of a bad-habit type behavior.
+
+1. **A disconnect between the team and leadership**  
+    If there is a misunderstanding or misalignment between the team and
+    leadership, this can undermine the stability of the engagement. This could
+    take the form of excited leadership with under-engaged team, or a team with
+    one goal in mind and leadership with another. This can result in a team that
+    commits to a large idea on paper but does not execute, and cancelled
+    partnerships mid-engagement.
+
+1. **Lack of improvements to platform layer**  
+    If the embedded engineer does not leave an engagement having identified
+    potential improvements to platform tooling, this is a missed opportunity.
+    Embedding on a team and operating as a contractor is missing the opportunity
+    to learn about the imperfections of a software platform through operating as
+    a customer of that platform.
+
+1. **Team size too small to impact change**  
+    If a team to be embedded with is too small (1-4 members) this will affect the
+    embedded engineers ability to affect change on the team. Larger teams should
+    be preferred to maximize face-time and visibility of the work being done, and
+    to allow for team-members to pair with each other to reinforce new habits.
+
+1. **Team goes back to bad habits**  
+    If a team that has had an auxiliary engagement is returning to previous
+    patterns and habits, this is a red flag. This can be due to a time-constrained
+    engagement where new habits were not thoroughly reinforced. This can result in
+    the work done by the embedded engineer being treated as if the engineer was
+    a contractor, undermining the ultimate goal of auxiliary engineering.