From 5f92b878131d6a8ed72ba63219ffb53e517b3ff4 Mon Sep 17 00:00:00 2001 From: Chris Antonellis Date: Fri, 4 Nov 2022 14:02:07 -0400 Subject: [PATCH 1/4] first pass on failure modes doc --- src/docs/theory/failure_modes.md | 63 +++++++++++++++++++++++++------- 1 file changed, 50 insertions(+), 13 deletions(-) diff --git a/src/docs/theory/failure_modes.md b/src/docs/theory/failure_modes.md index 12e23a75..fb044ce1 100644 --- a/src/docs/theory/failure_modes.md +++ b/src/docs/theory/failure_modes.md @@ -3,16 +3,53 @@ title: "Failure Modes" featured: ../images/featured/theory.png --- -## WORK IN PROGRESS NOTES - -- 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) +TODO: +* how to identify, avoid these situations + +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. + +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. From 0bda55313db75608a31bdd4d9938e1b8b24630d6 Mon Sep 17 00:00:00 2001 From: Chris Antonellis Date: Thu, 1 Dec 2022 09:55:22 -0500 Subject: [PATCH 2/4] Update src/docs/theory/failure_modes.md Co-authored-by: Gary White Jr. <7660110+GaryPWhite@users.noreply.github.com> --- src/docs/theory/failure_modes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/theory/failure_modes.md b/src/docs/theory/failure_modes.md index fb044ce1..11fe7a06 100644 --- a/src/docs/theory/failure_modes.md +++ b/src/docs/theory/failure_modes.md @@ -6,7 +6,7 @@ featured: ../images/featured/theory.png TODO: * how to identify, avoid these situations -An auxiliary engagement is a hopeful endeavor; there is no guarantee of success. +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. From b04c0405cc63f287e91e51aa2888eb7efe2ad24b Mon Sep 17 00:00:00 2001 From: Chris Antonellis Date: Thu, 1 Dec 2022 09:55:27 -0500 Subject: [PATCH 3/4] Update src/docs/theory/failure_modes.md Co-authored-by: Gary White Jr. <7660110+GaryPWhite@users.noreply.github.com> --- src/docs/theory/failure_modes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/theory/failure_modes.md b/src/docs/theory/failure_modes.md index 11fe7a06..7a3c3994 100644 --- a/src/docs/theory/failure_modes.md +++ b/src/docs/theory/failure_modes.md @@ -34,7 +34,7 @@ be especially potent in this context given the short timeline of an engagement. commits to a large idea on paper but does not execute, and cancelled partnerships mid-engagement. -1. **Lack of improvements to Platform layer** +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 From 0b7440b2bbe6622e90b608fe4041a71cd4e7e622 Mon Sep 17 00:00:00 2001 From: Chris Antonellis Date: Thu, 1 Dec 2022 10:28:22 -0500 Subject: [PATCH 4/4] removed todo items, hopefully passing linting --- src/docs/theory/failure_modes.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/docs/theory/failure_modes.md b/src/docs/theory/failure_modes.md index 7a3c3994..d789a1a8 100644 --- a/src/docs/theory/failure_modes.md +++ b/src/docs/theory/failure_modes.md @@ -3,9 +3,6 @@ title: "Failure Modes" featured: ../images/featured/theory.png --- -TODO: -* how to identify, avoid these situations - 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