From d078015da159f60cbfe5c9e23c8e1f5aa3b0cfd0 Mon Sep 17 00:00:00 2001 From: lelia Date: Fri, 16 Dec 2022 16:00:55 -0500 Subject: [PATCH 1/2] Fixed a few lingering AuxEngDocs references --- SECURITY.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 23ddec86..a0f3ae17 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,7 +1,7 @@ # 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) @@ -9,10 +9,10 @@ Aux Eng Docs project. ## 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 `OpenSource@wayfair.com`. From 594e46b59b21dbc038b0a786d920ba4a9f9bd7c0 Mon Sep 17 00:00:00 2001 From: lelia Date: Fri, 16 Dec 2022 16:07:58 -0500 Subject: [PATCH 2/2] Updated all AuxEng -> Aux Eng refs for consistency --- src/docs/goals.md | 6 +++--- src/docs/goals/mobility.md | 2 +- src/docs/goals/platforms.md | 4 ++-- src/docs/running.md | 2 +- src/docs/running/expectations.md | 12 ++++++------ src/docs/running/roles.md | 4 ++-- src/docs/running/sourcing.md | 16 ++++++++-------- src/docs/running/wrapping-up.md | 10 +++++----- src/docs/theory/concepts.md | 14 +++++++------- src/docs/theory/elements.md | 28 ++++++++++++++-------------- 10 files changed, 49 insertions(+), 49 deletions(-) diff --git a/src/docs/goals.md b/src/docs/goals.md index 8e0eac3d..3b709ecc 100644 --- a/src/docs/goals.md +++ b/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. diff --git a/src/docs/goals/mobility.md b/src/docs/goals/mobility.md index c68ea180..f40211b7 100644 --- a/src/docs/goals/mobility.md +++ b/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 diff --git a/src/docs/goals/platforms.md b/src/docs/goals/platforms.md index 0c756ebc..025700f0 100644 --- a/src/docs/goals/platforms.md +++ b/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 diff --git a/src/docs/running.md b/src/docs/running.md index 3ef26a50..7ac509db 100644 --- a/src/docs/running.md +++ b/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)** diff --git a/src/docs/running/expectations.md b/src/docs/running/expectations.md index dcdfe2e6..24f25c9c 100644 --- a/src/docs/running/expectations.md +++ b/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 diff --git a/src/docs/running/roles.md b/src/docs/running/roles.md index 4fdb916c..9f7f7af8 100644 --- a/src/docs/running/roles.md +++ b/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 diff --git a/src/docs/running/sourcing.md b/src/docs/running/sourcing.md index 7a263ee6..615d75d5 100644 --- a/src/docs/running/sourcing.md +++ b/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,7 +91,7 @@ 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 @@ -99,7 +99,7 @@ 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. @@ -107,4 +107,4 @@ 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. diff --git a/src/docs/running/wrapping-up.md b/src/docs/running/wrapping-up.md index 66f289ab..b28e08a2 100644 --- a/src/docs/running/wrapping-up.md +++ b/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,7 +27,7 @@ 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. @@ -35,7 +35,7 @@ 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 diff --git a/src/docs/theory/concepts.md b/src/docs/theory/concepts.md index b5633408..d309c83b 100644 --- a/src/docs/theory/concepts.md +++ b/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 diff --git a/src/docs/theory/elements.md b/src/docs/theory/elements.md index 8c3a9e24..7ec7251f 100644 --- a/src/docs/theory/elements.md +++ b/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 `atruslow@wayfair.com`. -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.