Engineering culture @ Awell
Storytelling
Storytelling is deeply ingrained in our nature as human beings. It’s how we pass our culture to one another. Therefore, storytelling is necessary in order for us to keep Awell’s culture alive. Storytelling can come in a number of formats:
Retrospectives https://awellhealth.atlassian.net/wiki/spaces/AWELL/pages/3208347713
Continuous learning (https://awellhealth.atlassian.net/wiki/spaces/AWELL/pages/3490185310)
Product pitches https://awellhealth.atlassian.net/wiki/spaces/AWELL/pages/1627029524
Persona definitions https://awellhealth.atlassian.net/wiki/spaces/AH/pages/3500540204
Operating principles
Fail fast (stay lean)
Innovation > predictability
Opinion-driven decisions are okay, but not without a plan for data
Keep a lean board by working “from right to left”
Communicate early and often
Succeed and fail as a team
Value Streams
We believe in empowering our individuals by organizing them into small, usually cross-functional teams (we call them “value streams”) of 3-8 people and giving them ownership over a particular slice of the business. Here are some guiding principles to our value streams (“VS”):
VS should be both highly aligned AND highly autonomous
VS should be open-sourced to the rest of the company
VS should expect to be self-service
VS are created with a mission in mind, and are individually responsible for defining their culture and their methods of execution
Highly aligned, highly autonomous
(plz forgive the ageist, sexist Dilbert-style boss)
We expect high autonomy within our value stream, but also high alignment with the long-term strategy of the organization and high alignment toward the VS mission.
Open-sourced
While VS might be responsible for a particular section of the product, other VS may depend on that piece of the product for a specific circumstance. In those cases, if the responsible VS is unable to help, then the dependent VS working on the feature is more than welcome to make changes to the code and submit to the owning VS for review.
VS should never be “waiting” on another VS for work to be done. They are encourage to take the work into their own hands and rely on the owning VS for review. Velocity other fiefdoms.
Self-service
VS should be completely self-service, meaning they should not rely on other VS in order to get work done. Related to “Open-sourced” above, VS are encouraged to do everything they need to do in order to meet their goals.
Mission, culture and execution
While a VS given mission is defined in the creation of the VS itself (and driven by the company and product strategy), the VS culture and the way the VS chooses to get things done are the responsibility of the VS members.
Each VS should have a page that contains the following information:
Mission (defined with the support of product leadership)
Culture (what kinds of people reside in the VS?)
Execution (how does the VS like to work?)
Incidentally, the culture and execution can together form an “API definition” for those outside the VS who are looking to collaborate with people inside of the VS.
Credits
Much of these thoughts are not my own. They are graciously stolen from other companies that have failed their way toward a successful culture. So, we learn from their mistakes and thus will make our own unique set of mistakes (although hopefully starting from a higher elevation).