diff --git a/.github/ISSUE_TEMPLATE/BUG_REPORT.md b/.github/ISSUE_TEMPLATE/BUG_REPORT.md index 65cfb1f8..161db20d 100644 --- a/.github/ISSUE_TEMPLATE/BUG_REPORT.md +++ b/.github/ISSUE_TEMPLATE/BUG_REPORT.md @@ -31,5 +31,6 @@ Please provide the version number where this issue was encountered. ## Checklist -- [ ] I have read the [contributing guidelines](https://github.com/wayfair-incubator/aux-eng-playbook/blob/main/CONTRIBUTING.md) +- [ ] I have read the [contributing + guidelines](https://github.com/wayfair-incubator/aux-eng-playbook/blob/main/CONTRIBUTING.md) - [ ] I have verified this does not duplicate an existing issue diff --git a/.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md b/.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md index 2af6aba2..73f10e01 100644 --- a/.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md +++ b/.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md @@ -17,8 +17,8 @@ Please describe what you envision the solution to this problem would look like. ## Alternatives Considered -Please briefly describe which alternatives, if any, have been considered, including merits of alternate approaches and -tradeoffs being made. +Please briefly describe which alternatives, if any, have been considered, +including merits of alternate approaches and tradeoffs being made. ## Additional Context diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 6b1e1230..df09495f 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,8 +1,12 @@ ## Description -Please provide a meaningful description of what this change will do, or is for. Bonus points for including links to related issues, other PRs, or technical references. +Please provide a meaningful description of what this change will do, or is for. +Bonus points for including links to related issues, other PRs, or technical +references. -Note that by _not_ including a description, you are asking reviewers to do extra work to understand the context of this change, which may lead to your PR taking much longer to review, or result in it not being reviewed at all. +Note that by _not_ including a description, you are asking reviewers to do extra +work to understand the context of this change, which may lead to your PR taking +much longer to review, or result in it not being reviewed at all. ## Type of Change @@ -15,7 +19,8 @@ Note that by _not_ including a description, you are asking reviewers to do extra ## Checklist -- [ ] I have read the [contributing guidelines](https://github.com/wayfair-incubator/aux-eng-playbook/blob/main/CONTRIBUTING.md) +- [ ] I have read the [contributing + guidelines](https://github.com/wayfair-incubator/aux-eng-playbook/blob/main/CONTRIBUTING.md) - [ ] Existing issues have been referenced (where applicable) - [ ] I have verified this change is not present in other open pull requests - [ ] Functionality is documented diff --git a/.markdownlint.json b/.markdownlint.json index 38d7191c..24512b44 100644 --- a/.markdownlint.json +++ b/.markdownlint.json @@ -1,7 +1,6 @@ { "default": true, "MD013": { - "line_length": 10000, "headings": false, "code_blocks": false, "tables": false diff --git a/CHANGELOG.md b/CHANGELOG.md index 8941194e..d595b2a5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,7 +3,8 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), -and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +and this project adheres to [Semantic +Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] @@ -32,6 +33,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 - Build and dependency fixes, Docker enhancements - Cleaned up and improved Goals splash page -[unreleased]: https://github.com/wayfair-incubator/aux-eng-playbook/compare/v0.0.2...HEAD -[0.0.2]: https://github.com/wayfair-incubator/aux-eng-playbook/releases/tag/v0.0.2 -[0.0.1]: https://github.com/wayfair-incubator/aux-eng-playbook/releases/tag/v0.0.1 +[unreleased]: + https://github.com/wayfair-incubator/aux-eng-playbook/compare/v0.0.2...HEAD +[0.0.2]: + https://github.com/wayfair-incubator/aux-eng-playbook/releases/tag/v0.0.2 +[0.0.1]: + https://github.com/wayfair-incubator/aux-eng-playbook/releases/tag/v0.0.1 diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 2fdd59da..b2fe8bcd 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -7,8 +7,8 @@ We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, -nationality, personal appearance, race, caste, color, religion, or sexual identity -and orientation. +nationality, personal appearance, race, caste, color, religion, or sexual +identity and orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. @@ -23,17 +23,17 @@ community include: * Giving and gracefully accepting constructive feedback * Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience -* Focusing on what is best not just for us as individuals, but for the - overall community +* Focusing on what is best not just for us as individuals, but for the overall + community Examples of unacceptable behavior include: -* The use of sexualized language or imagery, and sexual attention or - advances of any kind +* The use of sexualized language or imagery, and sexual attention or advances of + any kind * Trolling, insulting or derogatory comments, and personal or political attacks * Public or private harassment -* Publishing others' private information, such as a physical or email - address, without their explicit permission +* Publishing others' private information, such as a physical or email address, + without their explicit permission * Other conduct which could reasonably be considered inappropriate in a professional setting @@ -61,8 +61,8 @@ representative at an online or offline event. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at -opensource@wayfair.com. -All complaints will be reviewed and investigated promptly and fairly. +opensource@wayfair.com. All complaints will be reviewed and investigated +promptly and fairly. All community leaders are obligated to respect the privacy and security of the reporter of any incident. @@ -83,15 +83,15 @@ behavior was inappropriate. A public apology may be requested. ### 2. Warning -**Community Impact**: A violation through a single incident or series -of actions. +**Community Impact**: A violation through a single incident or series of +actions. **Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels -like social media. Violating these terms may lead to a temporary or -permanent ban. +like social media. Violating these terms may lead to a temporary or permanent +ban. ### 3. Temporary Ban @@ -110,8 +110,8 @@ Violating these terms may lead to a permanent ban. standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. -**Consequence**: A permanent ban from any sort of public interaction within -the community. +**Consequence**: A permanent ban from any sort of public interaction within the +community. ## Attribution @@ -119,12 +119,12 @@ This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at [https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0]. -Community Impact Guidelines were inspired by -[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. +Community Impact Guidelines were inspired by [Mozilla's code of conduct +enforcement ladder][Mozilla CoC]. For answers to common questions about this code of conduct, see the FAQ at -[https://www.contributor-covenant.org/faq][FAQ]. Translations are available -at [https://www.contributor-covenant.org/translations][translations]. +[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at +[https://www.contributor-covenant.org/translations][translations]. [homepage]: https://www.contributor-covenant.org [v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8191c484..8a81663f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,45 +1,56 @@ # How to Contribute -Thanks for your interest in contributing to the Aux Eng Playbook! Here are a few general guidelines on contributing and -reporting bugs that we ask you to review. Following these guidelines helps to communicate that you respect the time of -the contributors managing and developing this open source project. In return, they should reciprocate that respect in -addressing your issue, assessing changes, and helping you finalize your pull requests. In that spirit of mutual respect, -we endeavour to review incoming issues and pull requests within 10 days, and will close any lingering issues or pull -requests after 60 days of inactivity. - -Please note that all of your interactions in the project are subject to our [Code of Conduct](CODE_OF_CONDUCT.md). This -includes creation of issues or pull requests, commenting on issues or pull requests, and extends to all interactions in -any real-time space (eg. Slack, Discord, etc). +Thanks for your interest in contributing to the Aux Eng Playbook! Here are a few +general guidelines on contributing and reporting bugs that we ask you to review. +Following these guidelines helps to communicate that you respect the time of the +contributors managing and developing this open source project. In return, they +should reciprocate that respect in addressing your issue, assessing changes, and +helping you finalize your pull requests. In that spirit of mutual respect, we +endeavour to review incoming issues and pull requests within 10 days, and will +close any lingering issues or pull requests after 60 days of inactivity. + +Please note that all of your interactions in the project are subject to our +[Code of Conduct](CODE_OF_CONDUCT.md). This includes creation of issues or pull +requests, commenting on issues or pull requests, and extends to all interactions +in any real-time space (eg. Slack, Discord, etc). ## Reporting Issues -Before reporting a new issue, please ensure that the issue was not already reported or fixed by searching through our -[issues list](https://github.com/wayfair-incubator/aux-eng-playbook/issues). +Before reporting a new issue, please ensure that the issue was not already +reported or fixed by searching through our [issues +list](https://github.com/wayfair-incubator/aux-eng-playbook/issues). -When creating a new issue, please be sure to include a **title and clear description**, as much relevant information as -possible, and, if possible, a test case. +When creating a new issue, please be sure to include a **title and clear +description**, as much relevant information as possible, and, if possible, a +test case. -**If you discover a security bug, please do not report it through GitHub. Instead, please see security procedures in -[SECURITY.md](SECURITY.md).** +**If you discover a security bug, please do not report it through GitHub. +Instead, please see security procedures in [SECURITY.md](SECURITY.md).** ## Sending Pull Requests -Before sending a new pull request, take a look at existing pull requests and issues to see if the proposed change or fix -has been discussed in the past, or if the change was already implemented but not yet released. +Before sending a new pull request, take a look at existing pull requests and +issues to see if the proposed change or fix has been discussed in the past, or +if the change was already implemented but not yet released. -We expect new pull requests to include tests for any affected behavior, and, as we follow semantic versioning, we may -reserve breaking changes until the next major version release. +We expect new pull requests to include tests for any affected behavior, and, as +we follow semantic versioning, we may reserve breaking changes until the next +major version release. ## Other Ways to Contribute -We welcome anyone that wants to contribute to the Aux Eng Playbook to triage and reply to open issues to help troubleshoot -and fix existing bugs. Here is what you can do: - -- Help ensure that existing issues follows the recommendations from the _[Reporting Issues](#reporting-issues)_ section, - providing feedback to the issue's author on what might be missing. -- Review and update the existing content of our [Wiki](https://github.com/wayfair-incubator/aux-eng-playbook/wiki) with up-to-date - instructions and code samples. -- Review existing pull requests, and testing patches against real existing applications that use the Aux Eng Playbook. +We welcome anyone that wants to contribute to the Aux Eng Playbook to triage and +reply to open issues to help troubleshoot and fix existing bugs. Here is what +you can do: + +- Help ensure that existing issues follows the recommendations from the + _[Reporting Issues](#reporting-issues)_ section, providing feedback to the + issue's author on what might be missing. +- Review and update the existing content of our + [Wiki](https://github.com/wayfair-incubator/aux-eng-playbook/wiki) with + up-to-date instructions and code samples. +- Review existing pull requests, and testing patches against real existing + applications that use the Aux Eng Playbook. - Write a test, or add a missing test case to an existing test. Thanks again for your interest on contributing to the Aux Eng Playbook! diff --git a/README.md b/README.md index 4a8eee32..fd46a678 100644 --- a/README.md +++ b/README.md @@ -2,15 +2,23 @@ [![Deploy](https://github.com/wayfair-incubator/aux-eng-playbook/actions/workflows/deploy.yml/badge.svg?branch=main)](https://github.com/wayfair-incubator/aux-eng-playbook/actions/workflows/deploy.yml) [![Release](https://img.shields.io/github/v/release/wayfair-incubator/aux-eng-playbook?display_name=tag)](https://github.com/wayfair-incubator/aux-eng-playbook/releases) -[![License: BSD 0-Clause](https://img.shields.io/badge/License-BSD%200--Clause-orange.svg)](LICENSE) -[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.0-24B8EE.svg)](CODE_OF_CONDUCT.md) +[![License: BSD +0-Clause](https://img.shields.io/badge/License-BSD%200--Clause-orange.svg)](LICENSE) +[![Contributor +Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.0-24B8EE.svg)](CODE_OF_CONDUCT.md) [![Maintainer](https://img.shields.io/badge/Maintainer-Wayfair-7F187F)](https://wayfair.github.io) -A playbook for technologists interested in introducing [Auxiliary Engineering](https://www.aboutwayfair.com/tech-innovation/what-is-auxiliary-engineering) to their engineering organization. The [Aux Eng Playbook](https://github.com/wayfair-incubator/aux-eng-playbook) aims to document Wayfair Tech's pioneering implementation of Aux Eng programs while sharing key takeaways, learnings, and recipes for success. +A playbook for technologists interested in introducing [Auxiliary +Engineering](https://www.aboutwayfair.com/tech-innovation/what-is-auxiliary-engineering) +to their engineering organization. The [Aux Eng +Playbook](https://github.com/wayfair-incubator/aux-eng-playbook) aims to +document Wayfair Tech's pioneering implementation of Aux Eng programs while +sharing key takeaways, learnings, and recipes for success. ## 🚀 Quick Start -To get started editing this site, you'll need Node v14+, and _preferably_ v19. We recommend using [nvm](https://github.com/nvm-sh/nvm). +To get started editing this site, you'll need Node v14+, and _preferably_ v19. +We recommend using [nvm](https://github.com/nvm-sh/nvm). Once that's installed, you'll need [`yarn`](https://yarnpkg.com/) as well. @@ -36,15 +44,19 @@ You can now view Aux Eng Playbook in the browser. ``` -You can edit the site by editing the files in `src/`. This site uses CSS, JS, and [css-in-js](https://cssinjs.org/). +You can edit the site by editing the files in `src/`. This site uses CSS, JS, +and [css-in-js](https://cssinjs.org/). -> 💡 Note that for most images, you'll want to run `yarn build` before they show up correctly on the development site. +> 💡 Note that for most images, you'll want to run `yarn build` before they show +> up correctly on the development site. ## 🐳 Docker Setup -If you'd prefer to develop within a `node:19-alpine` container, this project also supports using Docker Compose with hot-reloading capabilites for Gatsby. +If you'd prefer to develop within a `node:19-alpine` container, this project +also supports using Docker Compose with hot-reloading capabilites for Gatsby. -First, make sure you have both [docker](https://docs.docker.com/engine/install/) and [docker-compose](https://docs.docker.com/compose/install/) installed. +First, make sure you have both [docker](https://docs.docker.com/engine/install/) +and [docker-compose](https://docs.docker.com/compose/install/) installed. To bring up the `gastby` development server, run: @@ -53,9 +65,15 @@ docker-compose down docker-compose up -d develop # Remove the -d flag if you don't witsh to daemonize the container ``` -Once the server is up and running, when you make local changes to your `gatsby` site content, the changes should hot-reload in your containerized instance, accessible in a browser at `http://localhost:8000`. Note that it's easier to observe the hot-reloading functionality in action when the container is not daemonized. +Once the server is up and running, when you make local changes to your `gatsby` +site content, the changes should hot-reload in your containerized instance, +accessible in a browser at `http://localhost:8000`. Note that it's easier to +observe the hot-reloading functionality in action when the container is not +daemonized. -If you'd like to interact with the [gatsby-cli](https://www.gatsbyjs.com/docs/reference/gatsby-cli/) directly, you can also run commands like: +If you'd like to interact with the +[gatsby-cli](https://www.gatsbyjs.com/docs/reference/gatsby-cli/) directly, you +can also run commands like: ```shell docker-compose run gatsby --help @@ -64,13 +82,18 @@ docker-compose run gatsby info # Example commmand to get environment information ## Contributing to Docs -If you're here to write some of our plentiful documentation, use these foolproof steps: +If you're here to write some of our plentiful documentation, use these foolproof +steps: -1. Ensure you've completed the [Quick Start](#-quick-start) above, and have a server running. +1. Ensure you've completed the [Quick Start](#-quick-start) above, and have a + server running. 1. Make a new branch for your new document post. -1. Create a new directory (or sub-directory, or sub-sub-directory) in `src/docs` like `my-doc` -1. Create an `index.md` file in `src/docs/my-doc` (or whatever you named your doc). This will be your document's markdown page. -1. Write the [frontmatter](https://github.com/remarkjs/remark-frontmatter#use) for the page like so: +1. Create a new directory (or sub-directory, or sub-sub-directory) in `src/docs` + like `my-doc` +1. Create an `index.md` file in `src/docs/my-doc` (or whatever you named your + doc). This will be your document's markdown page. +1. Write the [frontmatter](https://github.com/remarkjs/remark-frontmatter#use) + for the page like so: ```markdown --- @@ -78,13 +101,17 @@ title: "My Snazzy Article" --- ``` -1. Optionally, include any assets you need (images, etc) alongside `index.md`, and reference them directly, eg: `[my-image](./my-image)` -1. Watch your markdown come to life in your browser by visiting the corresponding path to your document from `/docs` (in this case, we'd visit `docs/my-doc`) +1. Optionally, include any assets you need (images, etc) alongside `index.md`, + and reference them directly, eg: `[my-image](./my-image)` +1. Watch your markdown come to life in your browser by visiting the + corresponding path to your document from `/docs` (in this case, we'd visit + `docs/my-doc`) 1. When satisfied, commit the result for review. ## Deploying -As long as permissions work and everything is aligned in the stars, you ought to be able to deploy with: +As long as permissions work and everything is aligned in the stars, you ought to +be able to deploy with: ```shell yarn deploy @@ -92,4 +119,6 @@ yarn deploy ## Troubleshooting -If you see strange behavior from developing or building the app, try `npx gatsby clean`. This should use the `gatsby-cli` to clean out frayed node modules or other unexpected hitches. +If you see strange behavior from developing or building the app, try `npx gatsby +clean`. This should use the `gatsby-cli` to clean out frayed node modules or +other unexpected hitches. diff --git a/src/docs/goals.md b/src/docs/goals.md index c2a56d1e..8e0eac3d 100644 --- a/src/docs/goals.md +++ b/src/docs/goals.md @@ -5,24 +5,40 @@ featured: ./images/featured/goals.png ## AuxEng Program High-Level Goals -AuxEng 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 reluctance to adopt a new tool, or a drift away from best practices. - -In addition to the primary goals, there are multiple secondary goals which are also valuable to organizations: - -- It's an effective way of creating [mobility of engineering talent](mobility/) across the organization. -- It can provide an attractive [engineering role archetype](careers/) for the organization's most experienced software engineers. -- In addition to those, there are several other [organizational benefits](diffusion/) we've observed in the dozens of engagements we've run. +AuxEng 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 +reluctance to adopt a new tool, or a drift away from best practices. + +In addition to the primary goals, there are multiple secondary goals which are +also valuable to organizations: + +- It's an effective way of creating [mobility of engineering talent](mobility/) + across the organization. +- It can provide an attractive [engineering role archetype](careers/) for the + organization's most experienced software engineers. +- In addition to those, there are several other [organizational + benefits](diffusion/) we've observed in the dozens of engagements we've run. ## Goals Per Engagement -Engagements can sometimes have different goals under different circumstances. Sometimes those goals will change how the engagement is run. For example, 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. +Engagements can sometimes have different goals under different circumstances. +Sometimes those goals will change how the engagement is run. For example, +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 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. +We've used AuxEng 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. Here are a few example goals we've come across for specific engagements: - Drive adoption of a tool or best practice -- Rally around a key business strategic goal with minimal disruption to other work streams +- Rally around a key business strategic goal with minimal disruption to other + work streams - Partner with an early adopter to understand how a new solution is being used - Debug a behavioral or tooling issue that has been identified - Spread knowledge and awareness of a new technology or skill set diff --git a/src/docs/goals/careers.md b/src/docs/goals/careers.md index b65eeb98..a0875641 100644 --- a/src/docs/goals/careers.md +++ b/src/docs/goals/careers.md @@ -5,23 +5,34 @@ featured: ../images/featured/goals.png ## A New Senior Contributor Archetype -Building meaningful career ladders for individual contributors can be a real challenge. One of the ways to support someone's career is to give them multiple role archetypes to choose from, and letting them play on their strengths. One of the goals of Auxiliary Engineering is to give senior engineers a new archetype which feels challenging, rewarding, and well aligned with their long term career success and ambitions. +Building meaningful career ladders for individual contributors can be a real +challenge. One of the ways to support someone's career is to give them multiple +role archetypes to choose from, and letting them play on their strengths. One of +the goals of Auxiliary Engineering is to give senior engineers a new archetype +which feels challenging, rewarding, and well aligned with their long term career +success and ambitions. ## Influencing without Authority or Dependency ## WORK IN PROGRESS NOTES - On Dependency - - When someone has unique strength in an area, it's too easy to lean on that person - - In the short term, dependency can satisfy one's ego, and it's generally the path of least resistance - - In the long run, dependency feels bad, and it also bakes a lot of risk into a team - - In a 3 month engagement, the end of the project is always looming on the horizon - - This makes it easy to challenge knowledge dependency early on, and prevent single points of knowledge failure from forming + - When someone has unique strength in an area, it's too easy to lean on that + person + - In the short term, dependency can satisfy one's ego, and it's generally the + path of least resistance + - In the long run, dependency feels bad, and it also bakes a lot of risk into + a team + - In a 3 month engagement, the end of the project is always looming on the + horizon + - This makes it easy to challenge knowledge dependency early on, and prevent + single points of knowledge failure from forming - Expectations - Breadth of influence across the organization - Regularly shaking up their problem domain -- Being in a position to identify the meta opportunities and having autonomy to drive innovation +- Being in a position to identify the meta opportunities and having autonomy to + drive innovation - Senior talent enjoys working on a variety of projects - Similar to high-end consultant @@ -35,6 +46,7 @@ Building meaningful career ladders for individual contributors can be a real cha - Large business impact - Moves some of an organizations most talented engineers around the company - Able to influence a large number of projects in healthy ways - - Influencing as part of a team, not an outsider disconnected from implementation / results + - Influencing as part of a team, not an outsider disconnected from + implementation / results - Avoids "powerpoint" architects. Keeps principal engineers writing code - This helps keep them marketable. It's good for their career. diff --git a/src/docs/goals/diffusion.md b/src/docs/goals/diffusion.md index 915580b3..47195d02 100644 --- a/src/docs/goals/diffusion.md +++ b/src/docs/goals/diffusion.md @@ -5,30 +5,85 @@ featured: ../images/featured/goals.png ## Increase Organizational Learning -An organization's ability to learn has a compounding positive or negative effect on its performance, particularly in technical fields where the ecosystem changes rapidly. A small organization is made of one social unit, allowing ideas to spread rapidly across the whole system, and the organization learns together. However, as an organization scales up its size, it begins to fracture into multiple social units encapsulated in communication boundaries. Teams who do not work directly together have limited ways of communicating ideas outside of the team. This in turn slows the diffusion of ideas and innovations across the organization. +An organization's ability to learn has a compounding positive or negative effect +on its performance, particularly in technical fields where the ecosystem changes +rapidly. A small organization is made of one social unit, allowing ideas to +spread rapidly across the whole system, and the organization learns together. +However, as an organization scales up its size, it begins to fracture into +multiple social units encapsulated in communication boundaries. Teams who do not +work directly together have limited ways of communicating ideas outside of the +team. This in turn slows the diffusion of ideas and innovations across the +organization. -Our hypothesis is that transactional communication (emails, presentations, adhoc conversations) have limited ability to facilitate diffusion. When a person becomes part of a team and works with that team towards a common goal, a far deeper understanding and more effective learning process can take place. This learning is bi-directional, which makes it particularly good for guiding platform teams. +Our hypothesis is that transactional communication (emails, presentations, adhoc +conversations) have limited ability to facilitate diffusion. When a person +becomes part of a team and works with that team towards a common goal, a far +deeper understanding and more effective learning process can take place. This +learning is bi-directional, which makes it particularly good for guiding +platform teams. ## Circulating Perspectives and Innovations -Keeping a subset of the organization regularly moving between teams and domains accelerates the diffusion of ideas in much the same way that stirring water dramatically increases how the diffusion of dyes dropped into it. New ideas, best practices, and learnings are always entering an organization through individuals. Unless additional action is taken, those innovations will remain localized. +Keeping a subset of the organization regularly moving between teams and domains +accelerates the diffusion of ideas in much the same way that stirring water +dramatically increases how the diffusion of dyes dropped into it. New ideas, +best practices, and learnings are always entering an organization through +individuals. Unless additional action is taken, those innovations will remain +localized. -Some ideas are significant enough that they should be spread deliberately, for example, through training, email, or presentations. However, there will be many ideas which are not sufficiently observable or impactful to be picked up by this type of communication. Many good ideas and practices will therefore not effectively spread across a large organization, and in aggregate these add up to a significant opportunity cost for the organization as a whole. Today, in any given organization, there are likely dozens or hundreds of improvements which are remain localized within the teams that learned them. +Some ideas are significant enough that they should be spread deliberately, for +example, through training, email, or presentations. However, there will be many +ideas which are not sufficiently observable or impactful to be picked up by this +type of communication. Many good ideas and practices will therefore not +effectively spread across a large organization, and in aggregate these add up to +a significant opportunity cost for the organization as a whole. Today, in any +given organization, there are likely dozens or hundreds of improvements which +are remain localized within the teams that learned them. -An Auxiliary Engineer embedded within a team creates an opportunity for rich bi-directional learning. When the engagement completes and the Auxiliary Engineer moves on to work with another team, they bring with them some of the strengths and perspectives from the first team. Over time, the Auxiliary Engineer learns from a growing number of teams, and is able to spread those learnings across the organization rapidly. +An Auxiliary Engineer embedded within a team creates an opportunity for rich +bi-directional learning. When the engagement completes and the Auxiliary +Engineer moves on to work with another team, they bring with them some of the +strengths and perspectives from the first team. Over time, the Auxiliary +Engineer learns from a growing number of teams, and is able to spread those +learnings across the organization rapidly. ## Durably Changing Behavior By Changing Habits -One of the most powerful ways we've found to durably change a team's behaviors is to influence their habits, and we subscribe to the theory that it takes roughly 10 weeks for a new habit to be formed. When an Aux Engineer begins working with a team, one of the first things they should be doing is identifying what habits they'd like to instill in the team. Disrupting habits in the beginning, and then consistently reinforcing the change throughout the duration of an engagement. The goal is by the end of the 3 months some old habits have been replaced with new ones and they are far more likely to take. +One of the most powerful ways we've found to durably change a team's behaviors +is to influence their habits, and we subscribe to the theory that it takes +roughly 10 weeks for a new habit to be formed. When an Aux Engineer begins +working with a team, one of the first things they should be doing is identifying +what habits they'd like to instill in the team. Disrupting habits in the +beginning, and then consistently reinforcing the change throughout the duration +of an engagement. The goal is by the end of the 3 months some old habits have +been replaced with new ones and they are far more likely to take. -A common example we've come across is appropriately prioritizing code reviews above project work. If you discuss this with a team, and they understand and agree with a change, it's still a long hard uphill battle to get a change like this to take. There are many habits, feedback loops, and incentives which are likely reinforcing the original behaviors. +A common example we've come across is appropriately prioritizing code reviews +above project work. If you discuss this with a team, and they understand and +agree with a change, it's still a long hard uphill battle to get a change like +this to take. There are many habits, feedback loops, and incentives which are +likely reinforcing the original behaviors. ## Bring New Perspectives To Old Problems -Sometimes a fresh perspective can do wonders to helping a team rethink long standing problems. Over time all teams lose their ability to see their domain for the first time, and they collectively begin to solidify on certain assumptions. +Sometimes a fresh perspective can do wonders to helping a team rethink long +standing problems. Over time all teams lose their ability to see their domain +for the first time, and they collectively begin to solidify on certain +assumptions. -A new hire is a great way to bring this fresh perspective to a domain, but a new hire is also faced with additional challenges. They're trying to wrap their heads around the entire system as a whole, and they are also feeling out their new team's personalities. It can be risky to make too many suggestions early and be perceived as a threat by more tenured members of the team. These two factors can curtail a new team member's ability to form and share their fresh perspectives with the team. +A new hire is a great way to bring this fresh perspective to a domain, but a new +hire is also faced with additional challenges. They're trying to wrap their +heads around the entire system as a whole, and they are also feeling out their +new team's personalities. It can be risky to make too many suggestions early and +be perceived as a threat by more tenured members of the team. These two factors +can curtail a new team member's ability to form and share their fresh +perspectives with the team. -When someone is invited to join a team as part of an Aux Engagement, they benefit from their existing domain knowledge within the organization, and their temporary role makes them less likely to be perceived, even unconsciously, as a threat to existing engineers. +When someone is invited to join a team as part of an Aux Engagement, they +benefit from their existing domain knowledge within the organization, and their +temporary role makes them less likely to be perceived, even unconsciously, as a +threat to existing engineers. -For this to be effective, it is important that the auxiliary engineer be brought on with the appropriate context and buy-in from the team. See: Framing the engagement. +For this to be effective, it is important that the auxiliary engineer be brought +on with the appropriate context and buy-in from the team. See: Framing the +engagement. diff --git a/src/docs/goals/mobility.md b/src/docs/goals/mobility.md index ddeba450..c68ea180 100644 --- a/src/docs/goals/mobility.md +++ b/src/docs/goals/mobility.md @@ -5,7 +5,10 @@ featured: ../images/featured/goals.png ## WORK IN PROGRESS NOTES -- Senior talent can be strategically moved around the organization with little cost +- Senior talent can be strategically moved around the organization with little + cost - AuxEng 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 disruption free re-alignment is an option. +- 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 + disruption free re-alignment is an option. diff --git a/src/docs/goals/platforms.md b/src/docs/goals/platforms.md index aba86027..0c756ebc 100644 --- a/src/docs/goals/platforms.md +++ b/src/docs/goals/platforms.md @@ -6,15 +6,22 @@ featured: ../images/featured/goals.png ## WORK IN PROGRESS NOTES - 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 directly contributing to business outcomes -- Knowing the right problems to solve can be difficult. Being embedded brings challenges, low hanging fruit to the surface. - - Impossible for a senior engineer to know what it's like to be a junior engineer, or not know the platform +- 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 + directly contributing to business outcomes +- Knowing the right problems to solve can be difficult. Being embedded brings + challenges, low hanging fruit to the surface. + - Impossible for a senior engineer to know what it's like to be a junior + engineer, or not know the platform - 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 / explorations in the platform gives them is powerful + - Engineers experiencing pain don't always realize when something is easy to + improve. +- Giving AuxEngineers 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 - - Writing documentation can be draining, but not nearly as much when you are solving a problem just experienced first hand + - Writing documentation can be draining, but not nearly as much when you are + solving a problem just experienced first hand - You feel like you're helping someone - That person validates and expresses gratitude. Feels rewarding diff --git a/src/docs/index.md b/src/docs/index.md index ab2abf65..22eab8c0 100644 --- a/src/docs/index.md +++ b/src/docs/index.md @@ -6,11 +6,11 @@ featured: ./images/featured/seo-default.png Auxiliary Engineering is an internal consulting model developed at Wayfair by Jonathan Biddle, Alex Truslow, and Engineering Effectiveness. -Its primary goals are to [diffuse best practices](goals/diffusion.md) across -the organization, and [drive platform improvements](goals/platforms.md). There -other secondary benefits such as: enabling [mobility of engineering talent](goals/mobility.md) -and providing an attractive [role archetype](goals/careers.md) for experienced -software engineers. +Its primary goals are to [diffuse best practices](goals/diffusion.md) across the +organization, and [drive platform improvements](goals/platforms.md). There other +secondary benefits such as: enabling [mobility of engineering +talent](goals/mobility.md) and providing an attractive [role +archetype](goals/careers.md) for experienced software engineers. We have run dozens of these engagements across several engineering languages and disciplines disciplines with overwhelming success. We are making this playbook diff --git a/src/docs/running.md b/src/docs/running.md index 2652ef9e..3ef26a50 100644 --- a/src/docs/running.md +++ b/src/docs/running.md @@ -3,8 +3,8 @@ title: "Running Engagements" featured: ./images/featured/running.png --- -This section details procedural structure we use to run Engagements. -Click into the links provided for more details on any particular part. +This section details procedural structure we use to run Engagements. Click into +the links provided for more details on any particular part. If you're unfamiliar, take a moment to review our project [roles](./roles). Roles clarify who should take responsibility for different stages and systems @@ -24,13 +24,13 @@ A Meet and Greet for our team and a team we may want to engage with. - **[One-Pager](./sourcing#one-pager)** -One-Pagers describe a team's problem, and proposed solution / practices -they wish to adopt. +One-Pagers describe a team's problem, and proposed solution / practices they +wish to adopt. - **[Fit Check](./sourcing#checking-project-fit)** -After receiving one or more projects, it's important to assess how they -fit against team, business, and technical goals. +After receiving one or more projects, it's important to assess how they fit +against team, business, and technical goals. ## [Planning](./planning) diff --git a/src/docs/running/executing.md b/src/docs/running/executing.md index 0a05a4da..c485de56 100644 --- a/src/docs/running/executing.md +++ b/src/docs/running/executing.md @@ -4,8 +4,8 @@ featured: ../images/featured/running.png --- We've done it! We've marketed ourselves and set [expectations](../expectations). -The hard work of [sourcing](../sourcing) and [planning](../planning) is finished, -our team is now at the meat and potatoes: doing the aux engagement. +The hard work of [sourcing](../sourcing) and [planning](../planning) is +finished, our team is now at the meat and potatoes: doing the aux engagement. ## Weekly Schedule @@ -29,20 +29,19 @@ We practice pair programming because we believe: - Pairing solves problems faster - Pairing will diffuse practices in engineers we pair with -If we have another mechanism that we believe achieves these goals -effectively, pair programming may be ok to skip. Otherwise, pair with -folks on a host team of an engagement as much as possible. +If we have another mechanism that we believe achieves these goals effectively, +pair programming may be ok to skip. Otherwise, pair with folks on a host team of +an engagement as much as possible. -With a free day and pairing time outlined, we integrate with team -rituals like stand up, planning, demo sessions, and participate -in those meetings. +With a free day and pairing time outlined, we integrate with team rituals like +stand up, planning, demo sessions, and participate in those meetings. ### Weekly Retros During the project we hold weekly 30 minute retros where we discuss the project. We talk about three things; what went well, what went poorly, and what we should -do next time. We also score the goals and metrics sheet before the retro, and will -review progress with our host team. +do next time. We also score the goals and metrics sheet before the retro, and +will review progress with our host team. In general we welcome feedback, and make it clear that we especially value negative feedback. If we get through most of the retro without having much in @@ -59,21 +58,20 @@ end early. ### Effective 20% Time -We like to keep the 20% time off of an engagement on Fridays, since -it's most likely that folks would take a long weekend, and/or have -less energy at the end of the week. Friday is a great time to -reflect on an engagement, write documentation that is missing from -products a team provides, give ourself downtime away from a host team -and time to stay involved with an engineers "home" team. - -Most Aux Engineers will be coming from a team out to change the culture -of other teams or provide insight an expertise on a platform product. -If an Aux Engineer is teaching other teams about kubernetes, for -example, they would likely have to change mindset about application -infrastructure as well as the actual code. With time to decompress and -take any thoughts from the "away" or "host team to the "home" team -- -we create a feedback loop that creates a better experience for the rest -of an engagement. Simple documentation and features can get back to the +We like to keep the 20% time off of an engagement on Fridays, since it's most +likely that folks would take a long weekend, and/or have less energy at the end +of the week. Friday is a great time to reflect on an engagement, write +documentation that is missing from products a team provides, give ourself +downtime away from a host team and time to stay involved with an engineers +"home" team. + +Most Aux Engineers will be coming from a team out to change the culture of other +teams or provide insight an expertise on a platform product. If an Aux Engineer +is teaching other teams about kubernetes, for example, they would likely have to +change mindset about application infrastructure as well as the actual code. With +time to decompress and take any thoughts from the "away" or "host team to the +"home" team -- we create a feedback loop that creates a better experience for +the rest of an engagement. Simple documentation and features can get back to the "home" team easily during a "20%" day. ## Project Retros @@ -84,21 +82,21 @@ we've hit together. Then we talk about three things; what went well, what went poorly, and what we should do next time for the entire project. We emphasize talking about issues -with the project, and especially like to hear negative feedback; things we can do -better. We take notes during the meeting, and afterwards we email the notes out to -everyone involved with the project. - -The scope of the conversation in this retro should be the entire project. It's -a good idea to prime the meeting room by restating goals and progress on them. -A host team for an engagement and engineers engaging have a great opportunity -here to celebrate success and reflect on what could be improved. -By the end of the meeting we ought to have established key takeaways, ways -to improve engagements generally or specifically in process and minutia about -engagement methodology. +with the project, and especially like to hear negative feedback; things we can +do better. We take notes during the meeting, and afterwards we email the notes +out to everyone involved with the project. + +The scope of the conversation in this retro should be the entire project. It's a +good idea to prime the meeting room by restating goals and progress on them. A +host team for an engagement and engineers engaging have a great opportunity here +to celebrate success and reflect on what could be improved. By the end of the +meeting we ought to have established key takeaways, ways to improve engagements +generally or specifically in process and minutia about engagement methodology. ## Project NPS -At the same time as the Project retro we send out an [NPS survey](https://www.salesforce.com/eu/learning-centre/customer-service/calculate-net-promoter-score/) +At the same time as the Project retro we send out an [NPS +survey](https://www.salesforce.com/eu/learning-centre/customer-service/calculate-net-promoter-score/) to ask the host team how likely they would be to recommend AuxEng. We use NPS to give us a quick overview on how the project went; it is an diff --git a/src/docs/running/expectations.md b/src/docs/running/expectations.md index aa8a041f..dcdfe2e6 100644 --- a/src/docs/running/expectations.md +++ b/src/docs/running/expectations.md @@ -3,15 +3,15 @@ title: "Engagement Expectations" featured: ../images/featured/running.png --- -Before we can start meaningfully engaging an organization, we have to -understand the mission of our team well enough to pitch it to others, -we have to find engineers that are willing to commit themselves to other -teams for extended periods of time, and we have to have engagements that are -worth doing for our team's priority. +Before we can start meaningfully engaging an organization, we have to understand +the mission of our team well enough to pitch it to others, we have to find +engineers that are willing to commit themselves to other teams for extended +periods of time, and we have to have engagements that are worth doing for our +team's priority. This document will outline how we approach engagement in an organization, and -high-level points to reiterate in a document that should come with any [advisor](../roles) -to any initial meeting. +high-level points to reiterate in a document that should come with any +[advisor](../roles) to any initial meeting. ## Set a Baseline @@ -21,51 +21,45 @@ opinion of how they apply to our team in a conspicuous place. Usually on an internal webpage about our team and practices; included in any e-mails or internal messages about our team to prospective "away" teams. -> **Aux Engineer will not do the hard work.** -Aux Engineers can help with what they're able to help with. They cannot -necessarily crush all problems on a given team -- they can crush problems within -their domain relevant to the success of 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 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 for you and -your team -- and encourage that replacements or alternatives have to achieve the -same goals. For example, retros are a time to understand progress and get -feedback. Without a replacement, everyone should attend and engage in retros, -or the model does not mutually benefit engagement "host" and "away" teams. -> **If failure modes persist, the engagement will end early.** -Setting the expectation that an engagement must continue working for everyone -early is important. It will save heartache and pain explaining later to make -this clear from the get-go: Mutually beneficial engineering time over a 10 week -period will only continue so long as the work is genuinely beneficial according -to both parties. It must also meaningfully progress toward diffusion and/or -engagement goals. +> **Aux Engineer will not do the hard work.** Aux Engineers can help with what +they're able to help with. They cannot necessarily crush all problems on a given +team -- they can crush problems within their domain relevant to the success of +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 +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 +> for you and your team -- and encourage that replacements or alternatives have +to achieve the same goals. For example, retros are a time to understand progress +and get feedback. Without a replacement, everyone should attend and engage in +retros, or the model does not mutually benefit engagement "host" and "away" +teams. **If failure modes persist, the engagement will end early.** Setting the +expectation that an engagement must continue working for everyone early is +> important. It will save heartache and pain explaining later to make this clear +from the get-go: Mutually beneficial engineering time over a 10 week period will +only continue so long as the work is genuinely beneficial according to both +parties. It must also meaningfully progress toward diffusion and/or engagement +goals. ## Prepare the Pitch 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 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 approach that any -given team is making. -- What does an embed do? -An "Embed" is the part of an engagement where AuxEng 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 comes together. To start -this process and invite folks in to collaborate, we need them to give us a one -pager, explaining their problem and solution, so we can evaluate if it makes -sense for our team to engage. +- 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 +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 +approach that any given team is making. +- What does an embed do? An "Embed" is the part of an engagement where AuxEng +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 +comes together. To start this process and invite folks in to collaborate, we +need them to give us a one pager, explaining their problem and solution, so we +can evaluate if it makes sense for our team to engage. diff --git a/src/docs/running/planning.md b/src/docs/running/planning.md index 2cb8a07d..1d7c20d9 100644 --- a/src/docs/running/planning.md +++ b/src/docs/running/planning.md @@ -3,17 +3,17 @@ title: "Planning" featured: ../images/featured/running.png --- -By the planning phase, we have [set expectations](../expectations) for others -to interact with our team, and [successfully sourced](../sourcing) a project -for to work on. Our team will now make an effort to plan for, and plan out the +By the planning phase, we have [set expectations](../expectations) for others to +interact with our team, and [successfully sourced](../sourcing) a project for +to work on. Our team will now make an effort to plan for, and plan out the specifics of, an engagement. ## Build Familiarity In most cases, we'll be working with a team in a domain we're unfamiliar with. Likely we'll have practices that are universal enough that the majority of work -won't be an issue. Documentation and testing pipelines, for example, take similar -shape everywhere. +won't be an issue. Documentation and testing pipelines, for example, take +similar shape everywhere. We find it worthwhile to intentionally clear our engineer's schedule as much as possible for a week or so to let them poke around the hosting team's codebase @@ -27,22 +27,20 @@ success. ## Goals and Metrics Once we decide we want to work with a team on a project, we work with them to -build out clear and measurable goals and metrics. -We use these metrics to clearly define what measurable things we aim to complete -during the project. We should set goals aspirational enough that we likely won't -complete them all. We aim for finishing about 75%. -Generally these goals fit on one page, and range from code quality metrics to -minimum viable product features. We reinforce the metrics that matter most for -us and a hosting team -- as well as the business impact we expect to make and how -it benefits the team. - -We only measure the MVP goals once the application is fully deployed and in production. -We focus on deploying a high quality MVP with a small feature set to production as -quickly as possible. -We generally have a goal measuring production adoption. This could be the rate of -flow through an order processing system, or measuring user interactions on a web -page. This helps prevent us from working on a project that is deployed to -production but is never used. +build out clear and measurable goals and metrics. We use these metrics to +clearly define what measurable things we aim to complete during the project. We +should set goals aspirational enough that we likely won't complete them all. We +aim for finishing about 75%. Generally these goals fit on one page, and range +from code quality metrics to minimum viable product features. We reinforce the +metrics that matter most for us and a hosting team -- as well as the business +impact we expect to make and how it benefits the team. + +We only measure the MVP goals once the application is fully deployed and in +production. We focus on deploying a high quality MVP with a small feature set to +production as quickly as possible. We generally have a goal measuring production +adoption. This could be the rate of flow through an order processing system, or +measuring user interactions on a web page. This helps prevent us from working on +a project that is deployed to production but is never used. Keep in mind we should have a mix of technical and business goals. This ensures both management layers of a team as well as engineers have a clear understanding @@ -51,12 +49,11 @@ of how they can contribute, and feel invested in the success of the engagement. ## Scheduling Meetings Once we've decided on the project goals and metrics, we start discussing -scheduling with the host team. -We try to line up our projects with the start and end of quarters. -We also try to give our engineers 3 weeks off between projects to focus on -platform work. Without some time off between projects it can be easy to burn out. -Given those constraints, we work with the host team to set up a start and an -end date for the project. +scheduling with the host team. We try to line up our projects with the start and +end of quarters. We also try to give our engineers 3 weeks off between projects +to focus on platform work. Without some time off between projects it can be easy +to burn out. Given those constraints, we work with the host team to set up a +start and an end date for the project. ## Kick Off Meeting @@ -64,16 +61,16 @@ During the first week of the project we set up a kickoff meeting with the developers, the product managers, and anyone else who is interested. At the kickoff meeting we communicate expectations about how we will be -developing. We explain which testing frameworks we use, what coverage -metrics we are going to shoot for; and review any other goals we have. +developing. We explain which testing frameworks we use, what coverage metrics we +are going to shoot for; and review any other goals we have. We communicate what the MVP we agreed on is, and how we are planning on approaching it technically. Sometimes the MVP or the technical approach hasn't been fully communicated to the entire team, so we make sure to reiterate it here. -We talk through the project timeline, and communicate expectations about -when the project MVP will be delivered. +We talk through the project timeline, and communicate expectations about when +the project MVP will be delivered. We take this time to reinforce the purpose of Aux Engagements, and what cadence we'll revisit priorities and talk about how the engagement is going (retros). diff --git a/src/docs/running/roles.md b/src/docs/running/roles.md index b930b9c0..4fdb916c 100644 --- a/src/docs/running/roles.md +++ b/src/docs/running/roles.md @@ -6,19 +6,20 @@ featured: ../images/featured/running.png ## Home Team Any team that offers Aux Engagements is a "Home Team" for Aux Engineers. They -will have systems in place to take feedback from engineers and prioritize it -for their backlog. They will have to be able to live without the Aux Engineer for the -10-week period of an engagement. They will spend plenty of time finding folks who wish -to have their team embedded with an Aux Engineer to run any engagements. +will have systems in place to take feedback from engineers and prioritize it for +their backlog. They will have to be able to live without the Aux Engineer for +the 10-week period of an engagement. They will spend plenty of time finding +folks who wish to have their team embedded with an Aux Engineer to run any +engagements. -The home team will have at least one [project engineer](#project-engineer) and one -[project advisor](#project-advisor). They should not be the same person for the same -engagement. +The home team will have at least one [project engineer](#project-engineer) and +one [project advisor](#project-advisor). They should not be the same person for +the same engagement. ## Host Team / "Away" Team -A Host team is any team that engages with a home team through AuxEng. Put another -way: any team that makes use of a team offering engineers through Aux +A Host team is any team that engages with a home team through AuxEng. 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 and technology changes during the course of an engagement. @@ -27,12 +28,12 @@ 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 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 appropriate 20% time) they have a free day to focus on other work -outside of the project. +The project engineer is responsible for running the day to day of the AuxEng +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 +appropriate 20% time) they have a free day to focus on other work outside of the +project. The project engineer is generally the face of the project for the host team and will co-locate with the host team. @@ -41,16 +42,15 @@ will co-locate with the host team. The project advisor is responsible for the overall success of the project. Advisors are responsible for seeing the big picture and ensuring the project is -on track overall. -We expect the advisor to track progress against goals, communicate with -the broader organization about progress and collaboration, and provide structure -to a project's logistics. +on track overall. We expect the advisor to track progress against goals, +communicate with the broader organization about progress and collaboration, and +provide structure to a project's logistics. The advisor works with the host team before the project to define the goals and -schedule of the project. -Advisors attend the retros, and periodically meet with the host team's leadership. -Advisors also provide the project engineer with feedback, coaching, and general support. +schedule of the project. Advisors attend the retros, and periodically meet with +the host team's leadership. Advisors also provide the project engineer with +feedback, coaching, and general support. -The advisor is also responsible for identifying issues with the project. -The advisor may choose to end the project early if the host team isn't fulfilling +The advisor is also responsible for identifying issues with the project. The +advisor may choose to end the project early if the host team isn't fulfilling their side of the contract. diff --git a/src/docs/running/sourcing.md b/src/docs/running/sourcing.md index d32b7cdc..7a263ee6 100644 --- a/src/docs/running/sourcing.md +++ b/src/docs/running/sourcing.md @@ -5,23 +5,24 @@ featured: ../images/featured/running.png After drumming up interest and [clarifying a team's mission](../expectations), managers and engineers should be ready to find ways to get teams interested. -This might require a lot of outreach, or there may be tools important -enough that many people will be delighted to speak with an Aux team. It's important -to approach all these teams as similarly as possible, to give them all the best +This might require a lot of outreach, or there may be tools important enough +that many people will be delighted to speak with an Aux team. It's important to +approach all these teams as similarly as possible, to give them all the best 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 some general direction on how to proceed with their project. +services. We will explain to the team what our AuxEng 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 -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. +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 for us, then we ask them to submit a one page document describing what they @@ -36,41 +37,39 @@ 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. For example, we may find that a team is very interested in an intro meeting, speaking over email, and/over DM. When asked to describe their problem, commit -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 +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. -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). +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). -After receiving a one-pager, We meet internally to rate the one-pager on -three metrics; business value, technical value, and team fit. +After receiving a one-pager, We meet internally to rate the one-pager on three +metrics; business value, technical value, and team fit. ## Checking Project Fit After some introductions and receiving a project brief via a one-pager, we -collect our team and make decisions on if we should proceed. To avoid bias -for or against a particular engagement, we will judge based on three tenets +collect our team and make decisions on if we should proceed. To avoid bias for +or against a particular engagement, we will judge based on three tenets important to the success of any project: Business Value, Technical Value, and Team Fit. It's best to run this meeting with as much numbers as possible to measure -sentiment. One example would be "Roman Voting" with a 0 for thumbs down, 1 -for thumb sideways, and 2 for thumb up in each category listed below. -It's often that multiple engagements must be considered next to one -another, and having a numerical score can reduce bias and choose the best -engagement for our team. +sentiment. One example would be "Roman Voting" with a 0 for thumbs down, 1 for +thumb sideways, and 2 for thumb up in each category listed below. It's often +that multiple engagements must be considered next to one another, and having a +numerical score can reduce bias and choose the best engagement for our team. ### Business Value We are careful to look for projects that we feel will have a measurable impact -on Wayfair's performance. We often look for projects that can associate a -dollar amount with getting their minimum viable product into production. -The value of an engagement creating a service that indirectly saves dollars, -or otherwise assisting a team that creatives multiplicative value is also -worth considering. +on Wayfair's performance. We often look for projects that can associate a dollar +amount with getting their minimum viable product into production. The value of +an engagement creating a service that indirectly saves dollars, or otherwise +assisting a team that creatives multiplicative value is also worth considering. A major refactor of a legacy system is an example of a project that we would consider to have low business value. It might solve a lot of problems for @@ -85,8 +84,8 @@ that has never been done at Wayfair before. We also look for projects that will have a major effect on a large team of engineers. Projects that further technical goals for leadership or for known populations (and/or with measurable gaps in their technical needs) are great -candidates for high technical value projects. We also consider helping a -large team move to a more modern paradigm to have high technical value. +candidates for high technical value projects. We also consider helping a large +team move to a more modern paradigm to have high technical value. ### Team Fit @@ -97,15 +96,15 @@ 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 +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. 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. +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. diff --git a/src/docs/running/wrapping-up.md b/src/docs/running/wrapping-up.md index 9f8ef7e9..66f289ab 100644 --- a/src/docs/running/wrapping-up.md +++ b/src/docs/running/wrapping-up.md @@ -4,8 +4,8 @@ featured: ../images/featured/running.png --- Aux Engagement completed! At this stage, engineers and advisors have spent -plenty of time with a host team, and vice versa. Retros, post engagement surveys, -and other clerical work is settled. What now? +plenty of time with a host team, and vice versa. Retros, post engagement +surveys, and other clerical work is settled. What now? ## Keep Work Separate @@ -16,14 +16,14 @@ 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 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 team, and the work for another team should be the same. +ends, something has gone wrong. Remember that the work for your team is on your +team, and the work for another team should be the same. Don't lose hope! Setting boundaries for work your team will do after an -engagement (none) and where they can go for help as your team is available -will often solve this problem. Escalate to management and within your own -organization as necessary, keeping in mind a simple conversation will -almost always alleviate any confusion. +engagement (none) and where they can go for help as your team is available will +often solve this problem. Escalate to management and within your own +organization as necessary, keeping in mind a simple conversation will almost +always alleviate any confusion. ## Three Month Check-in @@ -41,42 +41,42 @@ how they are fairing, and if they feel comfortable maintaining what we built together. We use this sentiment within the team to gauge success of our products' -maintenance, instead of initial setup and usage. The report that an engaged -team can and would provide is usually more candid; compared to what we -expect from teams that do not have a similar connection. +maintenance, instead of initial setup and usage. The report that an engaged team +can and would provide is usually more candid; compared to what we expect from +teams that do not have a similar connection. ## Following Up -We find connections throughout Wayfair when we practice AuxEng. Sometimes -those connections make little sense to keep tight relationships with after -an engagement ends. +We find connections throughout Wayfair when we practice AuxEng. Sometimes those +connections make little sense to keep tight relationships with after an +engagement ends. -Other times, it makes sense to keep a post-engagement set of colleagues -together in 1-1 conversations, or regular monthly sync ups. Tech leads can -give great feedback about the team's progress culturally, individual -contributors will have the most direct input on how well practices and tools -are proliferating through their team, and managers will give a bigger picture -of the impact engagements have had over time. +Other times, it makes sense to keep a post-engagement set of colleagues together +in 1-1 conversations, or regular monthly sync ups. Tech leads can give great +feedback about the team's progress culturally, individual contributors will have +the most direct input on how well practices and tools are proliferating through +their team, and managers will give a bigger picture of the impact engagements +have had over time. -Building connections that endure through shared success and mistakes will -create empathy and understanding between teams. Make the best use of that -empathy to drive team success and better decisions for product and strategic -direction. +Building connections that endure through shared success and mistakes will create +empathy and understanding between teams. Make the best use of that empathy to +drive team success and better decisions for product and strategic direction. ## What's Next? In short: Do it again! -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 team. - -It should be mentioned that this process can take a toll on [engineers and advisors](../roles). -Your Milage Will Vary, but we generally don't expect engineers to want to do -more than 2 engagements back to back. Anything more will leave folks feeling -disconnected from the team running Aux engagements. +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 +team. + +It should be mentioned that this process can take a toll on [engineers and +advisors](../roles). Your Milage Will Vary, but we generally don't expect +engineers to want to do more than 2 engagements back to back. Anything more will +leave folks feeling disconnected from the team running Aux engagements. When you're ready with another good idea, fresh engineers, and a strong fit, [roll it back](../)! diff --git a/src/docs/theory.md b/src/docs/theory.md index 5358ff09..7bbb3287 100644 --- a/src/docs/theory.md +++ b/src/docs/theory.md @@ -3,8 +3,16 @@ title: "Theory" featured: ./images/featured/theory.png --- -Auxiliary Engineering is an internal consulting model developed at Wayfair by Jonathan Biddle, Alex Truslow, and Development Platforms. +Auxiliary Engineering is an internal consulting model developed at Wayfair by +Jonathan Biddle, Alex Truslow, and Development Platforms. -Its primary goals are to [diffuse best practices](goals/diffusion.md) across the organization, and [drive platform improvements](goals/platforms.md). There are other secondary benefits such as: enabling [mobility of engineering talent](goals/mobility.md) and providing an attractive [role archetype](goals/careers.md) for experienced software engineers. +Its primary goals are to [diffuse best practices](goals/diffusion.md) across the +organization, and [drive platform improvements](goals/platforms.md). There are +other secondary benefits such as: enabling [mobility of engineering +talent](goals/mobility.md) and providing an attractive [role +archetype](goals/careers.md) for experienced software engineers. -We have run dozens of these engagements across several engineering languages and disciplines disciplines with overwhelming success. We are making this playbook available so other organizations can adopt what we believe is a powerful collaboration and skill sharing model for large organizations. +We have run dozens of these engagements across several engineering languages and +disciplines disciplines with overwhelming success. We are making this playbook +available so other organizations can adopt what we believe is a powerful +collaboration and skill sharing model for large organizations. diff --git a/src/docs/theory/concepts.md b/src/docs/theory/concepts.md index 465bc424..b5633408 100644 --- a/src/docs/theory/concepts.md +++ b/src/docs/theory/concepts.md @@ -5,7 +5,12 @@ featured: ../images/featured/theory.png # Auxiliary Engineering Concepts -AuxEng 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 large organization, and driving innovation at the platform level. Here are a few key concepts which are key to executing on this model. +AuxEng 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 +large organization, and driving innovation at the platform level. Here are a few +key concepts which are key to executing on this model. ## Limited Duration of Engagements @@ -17,24 +22,47 @@ AuxEng projects should last no more than a quarter. This has multiple benefits: ## Self-directed days -Auxiliary Engineers have 1 day per week to completely unplug from their current engagement, and spend their time on self-direct projects. We do this consistently for everyone on Friday to achieve the following benefits: +Auxiliary Engineers have 1 day per week to completely unplug from their current +engagement, and spend their time on self-direct projects. We do this +consistently for everyone on Friday to achieve the following benefits: - Keeps the engineer involved with the platform team even during engagements -- Provides mental space for experimental divergent thinking during the time of an intense engagement. -- Provides the chance to improve the platform or contribute to open source projects. +- Provides mental space for experimental divergent thinking during the time of + an intense engagement. +- Provides the chance to improve the platform or contribute to open source + projects. ## A strong focus on self-sufficiency -There is a very real risk and temptation for a host team to push on AuxEng 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 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. +There is a very real risk and temptation for a host team to push on AuxEng 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 +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. ## Technical goals are expressed as business value -Auxiliary Engineers leverage best practices such as testing, linting, CI, and code quality to move very quickly towards an MVP goal. Not only does this help build awareness about how best practices translate to business value, it can also helps the host team think develop an increased awareness about short and long term economic impact of their technical decisions. +Auxiliary Engineers leverage best practices such as testing, linting, CI, and +code quality to move very quickly towards an MVP goal. Not only does this help +build awareness about how best practices translate to business value, it can +also helps the host team think develop an increased awareness about short and +long term economic impact of their technical decisions. ## Humble experts eager to learn -While there is an expectation of an Auxiliary Engineer is that they're educating the host team in various ways, and that they're an expert in their craft, there's also an expectation that these engineers are learning from each engagement as well, and passing that knowledge on to the platform teams as well as other software teams. For these engagements to be successful, it's very important that both the Auxiliary Engineer and host team minimize ego and build a lasting / healthy relationship. +While there is an expectation of an Auxiliary Engineer is that they're educating +the host team in various ways, and that they're an expert in their craft, +there's also an expectation that these engineers are learning from each +engagement as well, and passing that knowledge on to the platform teams as well +as other software teams. For these engagements to be successful, it's very +important that both the Auxiliary Engineer and host team minimize ego and build +a lasting / healthy relationship. ## Engagement buffers -It's important to give Auxiliary Engineers several weeks of downtime between engagements. This time is spent focusing on platform initiatives and potentially implementing improvements or addressing issues which emerged during their engagement. This also creates a buffer between engagements that allows for a emotional / cognitive reset. +It's important to give Auxiliary Engineers several weeks of downtime between +engagements. This time is spent focusing on platform initiatives and potentially +implementing improvements or addressing issues which emerged during their +engagement. This also creates a buffer between engagements that allows for a +emotional / cognitive reset. diff --git a/src/docs/theory/elements.md b/src/docs/theory/elements.md index 0d0d353f..8c3a9e24 100644 --- a/src/docs/theory/elements.md +++ b/src/docs/theory/elements.md @@ -5,88 +5,110 @@ featured: ../images/featured/theory.png # How do I implement my own AuxEng team? -If you are interested in implementing your own AuxEng team, please reach out to `atruslow@wayfair.com`. +If you are interested in implementing your own AuxEng 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 AuxEng. You'll need to implement +them to start your AuxEng team. -Please also review the [AuxEng project structure](../running_engagements/overview.md) and the [AuxEng roles.](../running_engagements/roles.md) +Please also review the [AuxEng project +structure](../running_engagements/overview.md) and the [AuxEng +roles.](../running_engagements/roles.md) ## Elements of AuxEng ### Free Fridays -Your auxiliary engineer should work with their host team from Monday to Thursday. -On Fridays they should be working on self directed projects relating to their time with the host team. +Your auxiliary engineer should work with their host team from Monday to +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 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. +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 +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. ### 10 Week Project Duration -AuxEng 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. +AuxEng 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. -Beyond that, it takes about 8 weeks to pick up a new habit, so a 10 week engagement gives enough time for new coding habits to settle in. +Beyond that, it takes about 8 weeks to pick up a new habit, so a 10 week +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 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 future. +We hold weekly 30 minute retros specific to the AuxEng 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 +future. -We hold the weekly retro at the same time every week, and end the retro early when we run out of things to talk about. -We stress that we value negative feedback, and we try to address the feedback as soon as possible to build trust. +We hold the weekly retro at the same time every week, and end the retro early +when we run out of things to talk about. We stress that we value negative +feedback, and we try to address the feedback as soon as possible to build trust. ### Measurable Goals -We build out measurable OKR-like goals with the host team **before starting a project.** -We revisit the goals every week in the retro and discuss the measured progress. +We build out measurable OKR-like goals with the host team **before starting a +project.** We revisit the goals every week in the retro and discuss the measured +progress. -This clarity on the project goals is very important; it normally eliminates weeks of wasted work. -[Here is an example](https://docs.google.com/document/d/1B7V_cuV_37koAvSh0GjdFEK7CJFje-jcwidKRzKJoMc/edit) of goals we've worked out for a project we completed with Virtual Media. +This clarity on the project goals is very important; it normally eliminates +weeks of wasted work. [Here is an +example](https://docs.google.com/document/d/1B7V_cuV_37koAvSh0GjdFEK7CJFje-jcwidKRzKJoMc/edit) +of goals we've worked out for a project we completed with Virtual Media. ### Deliver Value in Production -We focus on delivering value in production as soon as possible after starting an engagement. -We generally get a high quality MVP in production within the first two weeks. -Features that aren't in production are not finished! +We focus on delivering value in production as soon as possible after starting an +engagement. We generally get a high quality MVP in production within the first +two weeks. Features that aren't in production are not finished! ### High Quality Software -We measure test coverage, and we only deliver software with 80% test coverage or greater. -We limit rework by writing tests and focusing on quality. -Great tests allow us to move quickly and refactor fearlessly. +We measure test coverage, and we only deliver software with 80% test coverage or +greater. We limit rework by writing tests and focusing on quality. Great tests +allow us to move quickly and refactor fearlessly. ### Advisor and Engineer roles We have an explicit project advisor and project engineer, as two distinct roles. -The engineer does the leg work on the project, leads the retros, pairs with the host team, etc. -The advisor supports the engineer and gives them feedback and direction. -The advisor also can support the engineer by escalating issues with the host team's management. +The engineer does the leg work on the project, leads the retros, pairs with the +host team, etc. The advisor supports the engineer and gives them feedback and +direction. The advisor also can support the engineer by escalating issues with +the host team's management. ### Net Promoter Score -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). +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 ### Superiority -We are not toxic experts (we hope). -When we work with a team they work along side us and they deserve the credit for their projects. -We are guests on their team, and we are here to help them be successful. +We are not toxic experts (we hope). When we work with a team they work along +side us and they deserve the credit for their projects. We are guests on their +team, and we are here to help them be successful. ### "Embedding" -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. +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. ### 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. +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 -We work with teams who are excited to work with us. -We never force any team to engage with us. +We work with teams who are excited to work with us. We never force any team to +engage with us. diff --git a/src/docs/theory/failure_modes.md b/src/docs/theory/failure_modes.md index d789a1a8..62478ee1 100644 --- a/src/docs/theory/failure_modes.md +++ b/src/docs/theory/failure_modes.md @@ -9,19 +9,20 @@ 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. + 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. + 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 @@ -39,14 +40,16 @@ be especially potent in this context given the short timeline of an engagement. 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. + 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. + 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. diff --git a/src/docs/theory/marketing.md b/src/docs/theory/marketing.md index 5dbeb596..e5e20b9e 100644 --- a/src/docs/theory/marketing.md +++ b/src/docs/theory/marketing.md @@ -6,7 +6,8 @@ featured: ../images/featured/theory.png ## WORK IN PROGRESS NOTES - Marketing applies internally just like a business - - Real revenue comes from leadership sponsorship in the form of a budget of some kind + - Real revenue comes from leadership sponsorship in the form of a budget of + some kind - If this is a high point of leverage, it needs to be known / communicated - Take a "show don't tell" approach - Recognition @@ -14,7 +15,8 @@ featured: ../images/featured/theory.png - Co-brand project communication - Protecting the Brand - If a team does auxeng, make sure they're actually following the model - - Typical embedded engineering is actually a stated failure mode of auxeng because it builds dependency + - Typical embedded engineering is actually a stated failure mode of auxeng + because it builds dependency Disruption / Habit setting