goals / platforms

src/docs/goals/platforms.md

@@ -3,18 +3,44 @@ title: "Platform"
 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
-  - 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
-  - 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
-    - You feel like you're helping someone
-    - That person validates and expresses gratitude. Feels rewarding
+In Auxiliary Engineering, we move out to consumer teams from a product team to solve problems and learn more about our products. The tools and products that an engineering support team puts out are that team's _platform_. Our goal in doing this is to enrich the platform, and the experience of those using it.
+
+A Python Platform team would provide tools that make Python simple to use and operate. A team focused on testing may maintain a continuous integration pipeline infrastructure, or testing frameworks. A Kubernetes-centric team may provide templates and automation to make interacting with Kubernetes simple for critical team operations and application development.
+
+Our goals through AuxEng provide benefits to any team developing or maintaining a platform.
+
+## Product, Platform, AuxEng
+
+In [lean software development](http://theleanstartup.com/principles), a software team builds code that might solve a problem. The team then measures the result through usage analytics or data on the affect their code may have on their users. The team _learns_ from those measurements and synthesizes ideas on what to build next.
+
+We believe in this methodology. A goal of any engagement in AuxEng is to provide measurement and learning during engagements, then fresh ideas and methodology for building off-engagement.
+
+### During Engagements
+
+When an engineer works with another team, they are pair programming with the intended users of a platform. Part of that experience includes seeing where their products fall short or don't solve a problem effectively. If it takes 20 minutes to learn how to use a tool that saves 20 minutes, people will likely not use that tool. An Aux Engineer can learn this during an engagement; then learn the ways that their users _expect_ software or platforms to work (this is a less-data-driven approach to _measuring_ the success of any built changes). The Aux Engineer can relay feedback and proposed changes during or after the engagement (sharing _learning_) to appropriately serve real users engaging with a platform.
+
+The contributions an Aux Engineer can glean are hugely valuable. Keep in mind: they're doing this not only to serve a platform team's product and roadmap. Aux Eng actively moves the needs of the business forward, faster, by connecting experts in a domain/platform with others that need help engaging in that space. In our experience, that exposure from our team into our user teams is as valuable as building a critical change into our platform.
+
+### Off-Engagements
+
+As we've served our goals effectively on-engagement, it's important to highlight the goals off-engagement. The perspective that an Aux Engineer brings back to a team during an engagement is important. The perspective they can bring when they're not pairing 4 days a week with another team is just as vital to team success and productivity.
+
+It's a goal of Aux Eng programs to bring perspective and understanding of the software landscape and engineering culture back to a platform team. After working with teams in one or many spaces separate from the platform team, an engineer will promote difficulty that real teams have using products and processes back to a platform team. Our goal is to ultimately influence a product roadmap or design choices in a system toward the needs of actual users.
+
+## Platform Team Influence
+
+Another goal of AuxEng is to build stronger relationships across an organization or ecosystem. By engaging with users directly, and putting time in to understand their problems; a team practicing AuxEng reaps benefits of empathy and respect.
+
+### Adoption and Understanding
+
+It's a fact of software engineering life that we use software we didn't write ourselves. This might come from adoption of open source, a vendor's offering, or that of a platform team in the organization. In any case, it's common for engineers to have a hard time navigating docs or learning about a tool or framework to solve their problem.
+
+It's a goal of AuxEng to provide clarity for engineers in these moments of adoption and potential frustration. By engaging with engineers directly, solving problems alongside them and providing reasoning and understanding for why tools and platforms work the way they do -- we remove much of the learning curve and frustration for our products. We also provide a deeper understanding for the choices and tradeoffs made in adoption of a platform.
+
+We do this not only to benefit the teams with knowledge of the software we write and recommend. We provide this service so we, as subject matter experts, never become fully complacent in how we expect our users to think and feel about the product offering our platform teams provide.
+
+### Building Relationships
+
+Maintaining relationships as a team serving other teams is crucial. Without users to get feedback from, or use software at all, a platform team is not fully serving their purpose. When we engage with a team, we spend time pair programming and navigating the problems they deal with on a regular basis. The understanding of those problems and shared experience will build empathy and foundations for a long-standing mutually beneficial relationship.
+
+It's a goal of every Aux Engagement to find "champions" -- enthusiastic users or adopters of our systems -- to come back to regularly as a team for feedback and input on how the platform feels and is doing in the engineering culture around our users. Learning about how changes affect users, how adoption rate is growing, and gauging general sentiment from several of these advocates will help us make better directional and strategic decisions on how to operate and maintain our platform.