Merge pull request #77 from wayfair-incubator/rename-auxeng-references

Update all `AuxEng` -> `Aux Eng` references

SECURITY.md

@@ -1,18 +1,18 @@
 # Security Policies and Procedures
 
-This document outlines security procedures and general policies for the
-Aux Eng Docs project.
+This document outlines security procedures and general policies for the Aux Eng
+Playbook project.
 
 - [Reporting a Bug](#reporting-a-bug)
 - [Disclosure Policy](#disclosure-policy)
 - [Comments on this Policy](#comments-on-this-policy)
 
 ## Reporting a Bug
 
-The Aux Eng Docs team and community take all security bugs in
-Aux Eng Docs seriously.  Thank you for improving the security of
-Aux Eng Docs. We appreciate your efforts and responsible disclosure and
-will make every effort to acknowledge your contributions.
+The Aux Eng Playbook team and community take all security bugs in the playbook
+seriously. Thank you for improving the security of the Aux Eng Playbook. We
+appreciate your efforts and responsible disclosure and will make every effort to
+acknowledge your contributions.
 
 Report security bugs by emailing `[email protected]`.
 

src/docs/goals.md

@@ -3,9 +3,9 @@ title: "Aux Eng Goals"
 featured: ./images/featured/goals.png
 ---
 
-## AuxEng Program High-Level Goals
+## Aux Eng Program High-Level Goals
 
-AuxEng is an internal consulting program structure which helps platform teams
+Aux Eng is an internal consulting program structure which helps platform teams
 get significantly closer to the teams they enable. This often helps the platform
 team [identify previously unknown opportunities](platforms/) to improve other
 teams' effectiveness. In other cases, it can be useful to debug a team's
@@ -29,7 +29,7 @@ sometimes a shorter engagement of only a few weeks is sufficient to identify why
 a software team's commit size is increasing while their engineering cycle times
 are growing longer.
 
-We've used AuxEng to embed with an early adopter of a new tool, creating a tight
+We've used Aux Eng to embed with an early adopter of a new tool, creating a tight
 and clear feedback loop which expedites early iterations. The embedded engineer
 can see firsthand how the tool is succeeding (or not) in achieving its desired
 outcomes.

src/docs/goals/mobility.md

@@ -7,7 +7,7 @@ featured: ../images/featured/goals.png
 
 - Senior talent can be strategically moved around the organization with little
   cost
-- AuxEng is design to not build dependency on the guest engineers
+- Aux Eng is design to not build dependency on the guest engineers
 - Team receiving a new engineer feels the gains, but team losing the engineer
   doesn't feel pain
 - Engagements can be staggered to be starting every month or so, meaning

src/docs/goals/platforms.md

@@ -8,7 +8,7 @@ featured: ../images/featured/goals.png
 - Synthesize the product function
 - Justifying funding for the platform team can be difficult as it is indirect
   business value
-- AuxEng allows you to staff a platform team up with senior talent while still
+- Aux Eng allows you to staff a platform team up with senior talent while still
   directly contributing to business outcomes
 - Knowing the right problems to solve can be difficult. Being embedded brings
   challenges, low hanging fruit to the surface.
@@ -17,7 +17,7 @@ featured: ../images/featured/goals.png
   - Seeing a junior engineer struggle makes points of friction clear
   - Engineers experiencing pain don't always realize when something is easy to
     improve.
-- Giving AuxEngineers 1 day per week to make self-directed investments /
+- Giving Aux Engineers 1 day per week to make self-directed investments /
   explorations in the platform gives them is powerful
   - Self-direction is powerful. Process adds friction
   - Short feedback loops. Experience pain -> Solve problem

src/docs/running.md

@@ -54,7 +54,7 @@ _Doing the work._
 
 - **[Weekly Schedule](./executing#weekly-schedule)**
 
-_What a week in AuxEng should look like._
+_What a week in Aux Eng should look like._
 
 - **[Weekly Retros](./executing#weekly-retros)**
 

src/docs/running/expectations.md

@@ -28,7 +28,7 @@ an engagement. Fiercely defending the time spent on a team is important to
 ensure maximum diffusion and engagement goal progress. **Diffusion is the
 primary goal and project success is the secondary goal.** Diffusion of cultural
 > changes like testing, usage of a standardized tool, etc, should come second to
-achieving some particular engagement goal. AuxEng is used at Wayfair to
+achieving some particular engagement goal. Aux Eng is used at Wayfair to
 proliferate usage of a tool or practice, not to burn down backlogs for any team.
 **Weekly retros and schedules are important. Critical feedback is strongly
  encouraged.** It's important to understand what scheduled rituals are important
@@ -48,15 +48,15 @@ goals.
 
 The general flow we've used in pitch meetings goes something like this:
 
-- What is AuxEng? Simply clarify key words, tools, and layout of your team and
-AuxEng. We explain embeds, engagements, trainings, and other ways our team may
+- What is Aux Eng? Simply clarify key words, tools, and layout of your team and
+Aux Eng. We explain embeds, engagements, trainings, and other ways our team may
 engage with an organization.
 - What is (team)? We take time to emphasize our team's direction and mission.
 Are we proliferating a practice? Is that practice centered around a tool?
-- Why AuxEng? In the framework of all the ways a team can engage other teams in
-an organization, it's a reasonable tangent to mention exactly why AuxEng is the
+- Why Aux Eng? In the framework of all the ways a team can engage other teams in
+an organization, it's a reasonable tangent to mention exactly why Aux Eng is the
 approach that any given team is making.
-- What does an embed do? An "Embed" is the part of an engagement where AuxEng
+- What does an embed do? An "Embed" is the part of an engagement where Aux Eng
 engineers actually code and help a team. Hopefully this guide and website gives
 enough of a definition that you feel ready to answer this question.
 - How do we get started? This is where much of the framework we've said so far

src/docs/running/roles.md

@@ -18,7 +18,7 @@ the same engagement.
 
 ## Host Team / "Away" Team
 
-A Host team is any team that engages with a home team through AuxEng. Put
+A Host team is any team that engages with a home team through Aux Eng. Put
 another way: any team that makes use of a team offering engineers through Aux
 Engagements. A Host Team should have resources dedicated to pair programming
 during the engagement. However: it is the job of the Home team to drive culture
@@ -28,7 +28,7 @@ On a project there should be at least 2 folks working with the host team.
 
 ## Project Engineer
 
-The project engineer is responsible for running the day to day of the AuxEng
+The project engineer is responsible for running the day to day of the Aux Eng
 project. This includes running retros, attending standup, leading workshops,
 pairing with engineers, writing tests, helping with features, etc. The project
 engineer works with the host team from Monday through Thursday. On Fridays (or

src/docs/running/sourcing.md

@@ -13,25 +13,25 @@ chance of driving value for an Aux Home team's goals in engagements.
 ## Intro Meetings
 
 We regularly have teams approach us; looking for advice on building new
-services. We will explain to the team what our AuxEng program is and give them
+services. We will explain to the team what our Aux Eng program is and give them
 some general direction on how to proceed with their project.
 
 Most questions we get and most outline we give stem from the mission of the
-AuxEng team that sponsors the engineer. For example, we might have a team that
+Aux Eng team that sponsors the engineer. For example, we might have a team that
 heavily focuses on best practices for Python. We outline how we make life better
 for engineers that use our recommended tools, how we help setup automation and
 quality of life improvements for folks we engage with, and [generally
 pitch](../expectations#prepare-the-pitch) the value we believe our team can
 bring.
 
-If the team seems interested in AuxEng, and their project seems like a good fit
+If the team seems interested in Aux Eng, and their project seems like a good fit
 for us, then we ask them to submit a one page document describing what they
 intend to build.
 
 ## One-Pager
 
 We ask teams to submit a one page document describing what they intend to build
-when they express interest in AuxEng. This allows us to see a condensed version
+when they express interest in Aux Eng. This allows us to see a condensed version
 of their project. It also gives us an artifact to discuss internally.
 
 The commitment we can expect from a team will also be apparent from one-pager.
@@ -41,7 +41,7 @@ technologists, or other resources, they hesitate. We take the effort in a
 one-pager to heart when considering an engagement. A team that expects a rigid
 structure or form to submit their one-pager idea likely has low resources to
 affect meaningful change in their work habits, and may not receive the full
-benefit AuxEng can provide.
+benefit Aux Eng can provide.
 
 While we don't provide a strict template for a one-pager, we will generally want
 a problem statement, wish list, and some goals (business and technical).
@@ -91,20 +91,20 @@ team move to a more modern paradigm to have high technical value.
 
 We normally pair with a team for three months, so we really care about team fit.
 Having poor team fit can ruin an otherwise good project, and cause unnecessary
-friction between AuxEng and the host team. We will discuss problems can be
+friction between Aux Eng and the host team. We will discuss problems can be
 logistical, or technical, or both.
 
 Logistically, a team may prefer to hold their stand-up at 6 PM, while an aux
 engineer must be clocked out by 5. They may have a distributed team that makes
 it difficult to effectively pair with reasonable overlap across time zones.
 We've seen teams that even prefer to have night owls working late into the
 night, and take some of the next day off. The working habits of our team must
-meaningfully overlap to have a successful AuxEng engagement.
+meaningfully overlap to have a successful Aux Eng engagement.
 
 Technically, we write tests for our code, and we believe that high test coverage
 allows us to move faster, onboard engineers quicker, and refactor more easily.
 We deeply believe in testing, linting, containerized development, maintaining
 high test coverage, and CI/CD. Some teams believe these practices will "slow
 them down" and will "block them from deploying". Writing tests is a skill, at
 first it is hard and can take work to learn. If a team isn't interested in
-learning to write tests then they are not a good fit for AuxEng.
+learning to write tests then they are not a good fit for Aux Eng.

src/docs/running/wrapping-up.md

@@ -13,7 +13,7 @@ Keeping work separate is a constant effort as a team engaging with other
 engineering teams. It's tempting for other teams to view your team as "free
 people" that will work to simply burn down a backlog.
 
-It's up to a team running AuxEng to keep this work separate, and this line
+It's up to a team running Aux Eng to keep this work separate, and this line
 becomes especially important to hold after an engagement ends. If a team
 continues to expect more than a reasonable helping hand after an engagement
 ends, something has gone wrong. Remember that the work for your team is on your
@@ -27,15 +27,15 @@ always alleviate any confusion.
 
 ## Three Month Check-in
 
-We care deeply that our AuxEng projects are set up for long term success.
+We care deeply that our Aux Eng projects are set up for long term success.
 Although during the project we focus on getting the host teams MVP into prod, we
 hope that the projects we work on have a long term impact.
 
 Three months after the project is finished we have an informal check-in with the
 host team. We are interested in any feedback they have for us, and want to hear
 how the project is shaping up after we left.
 
-We are wary of the host team building too much dependency on AuxEng, which is a
+We are wary of the host team building too much dependency on Aux Eng, which is a
 failure in our eyes. During the three month check-in we ask the host team about
 how they are fairing, and if they feel comfortable maintaining what we built
 together.
@@ -47,7 +47,7 @@ teams that do not have a similar connection.
 
 ## Following Up
 
-We find connections throughout Wayfair when we practice AuxEng. Sometimes those
+We find connections throughout Wayfair when we practice Aux Eng. Sometimes those
 connections make little sense to keep tight relationships with after an
 engagement ends.
 
@@ -70,7 +70,7 @@ We measure success from an engagement with business and technical goals
 achieved. We wse NPS to understand how a hosting team felt about the progress
 technically, and product wise, from any engagement effort. We use what practices
 worked for us and reconsider the ones that didn't work. Everything we do is up
-for debate, and we use it all to achieve the mission and goals of AuxEng and our
+for debate, and we use it all to achieve the mission and goals of Aux Eng and our
 team.
 
 It should be mentioned that this process can take a toll on [engineers and

src/docs/theory/concepts.md

@@ -5,7 +5,7 @@ featured: ../images/featured/theory.png
 
 # Auxiliary Engineering Concepts
 
-AuxEng takes inspiration from several models including Software Consulting,
+Aux Eng takes inspiration from several models including Software Consulting,
 Embedded Engineering, and Matrix Reporting. However, it's important to recognize
 that it is distinct from all of those. It is uniquely focused on facilitating a
 lasting transformative effect on a team, circulating best practices across a
@@ -14,11 +14,11 @@ key concepts which are key to executing on this model.
 
 ## Limited Duration of Engagements
 
-AuxEng projects should last no more than a quarter. This has multiple benefits:
+Aux Eng projects should last no more than a quarter. This has multiple benefits:
 
 - Creates a healthy sense of focused urgency on achieving a clearly scoped MVP
-- Allows the AuxEng program to engage with many teams in a year
-- Discourages building dependency on AuxEng
+- Allows the Aux Eng program to engage with many teams in a year
+- Discourages building dependency on Aux Eng
 
 ## Self-directed days
 
@@ -34,12 +34,12 @@ consistently for everyone on Friday to achieve the following benefits:
 
 ## A strong focus on self-sufficiency
 
-There is a very real risk and temptation for a host team to push on AuxEng to
+There is a very real risk and temptation for a host team to push on Aux Eng to
 implement complex features independently, but we state this clearly as a failure
-mode of a project. AuxEng is constantly looking out for things that would erode
+mode of a project. Aux Eng is constantly looking out for things that would erode
 a team's self-sufficiency, and therefore are keen to pair with engineers on the
 host team for complex features. This ensures that upon completion of the
-project, a host team does not end up reliant on AuxEng for future iterations.
+project, a host team does not end up reliant on Aux Eng for future iterations.
 
 ## Technical goals are expressed as business value
 

src/docs/theory/elements.md

@@ -3,19 +3,19 @@ title: "Elements"
 featured: ../images/featured/theory.png
 ---
 
-# How do I implement my own AuxEng team?
+# How do I implement my own Aux Eng team?
 
-If you are interested in implementing your own AuxEng team, please reach out to
+If you are interested in implementing your own Aux Eng team, please reach out to
 `[email protected]`.
 
-In general, the following are core elements of AuxEng. You'll need to implement
-them to start your AuxEng team.
+In general, the following are core elements of Aux Eng. You'll need to implement
+them to start your Aux Eng team.
 
-Please also review the [AuxEng project
-structure](../running_engagements/overview.md) and the [AuxEng
+Please also review the [Aux Eng project
+structure](../running_engagements/overview.md) and the [Aux Eng
 roles.](../running_engagements/roles.md)
 
-## Elements of AuxEng
+## Elements of Aux Eng
 
 ### Free Fridays
 
@@ -24,15 +24,15 @@ Thursday. On Fridays they should be working on self directed projects relating
 to their time with the host team.
 
 This is important for two reasons. First, it is really easy to get burnt out
-doing AuxEng five days a week. Second, it is important for the auxiliary
+doing Aux Eng five days a week. Second, it is important for the auxiliary
 engineer to bring back learnings from their engagement. "Free Fridays" are a
 great time to address feedback rapidly, creating an extremely tight feedback
 loop for improvements. If the auxiliary engineer doesn't have time to bring back
-user feedback to your team you are missing an explicit goal of AuxEng.
+user feedback to your team you are missing an explicit goal of Aux Eng.
 
 ### 10 Week Project Duration
 
-AuxEng is about committing to an ambitious goal, and then partnering with a team
+Aux Eng is about committing to an ambitious goal, and then partnering with a team
 to deliver it quickly with high code quality. Ambitious goals generally take a
 quarter.
 
@@ -41,7 +41,7 @@ engagement gives enough time for new coding habits to settle in.
 
 ### Weekly Retros
 
-We hold weekly 30 minute retros specific to the AuxEng project. This is in
+We hold weekly 30 minute retros specific to the Aux Eng project. This is in
 addition to any retros the host team is running. We hold them even when there is
 "nothing to talk about". We take notes and send them out to all participants. We
 keep the retro notes in git so we can reference back to them at any point in the
@@ -87,7 +87,7 @@ the host team's management.
 At the end of the project we measure our NPS via survey, and we talk about it
 and socialize it (even if it isn't great).
 
-## AuxEng Anti-Goals
+## Aux Eng Anti-Goals
 
 ### Superiority
 
@@ -101,14 +101,14 @@ We don't embed with the team to "burn down the backlog". We are there to help
 the host team build a culture of quality and produce better software. Often our
 engineers spend most of their time pairing, and not burning down tickets.
 Embedding can be useful, but normally it is smaller scope and shorter than an
-AuxEng engagement.
+Aux Eng engagement.
 
 ### Building Dependency
 
 We are explicitly trying to build up the host team, so they are *not* dependent
 on us to be successful in the future.
 
-### Forcing AuxEng on Teams
+### Forcing Aux Eng on Teams
 
 We work with teams who are excited to work with us. We never force any team to
 engage with us.