From f288fa27d736e484f52b0617f9c445de382b1a61 Mon Sep 17 00:00:00 2001 From: Gary White Jr Date: Tue, 22 Nov 2022 11:15:23 -0500 Subject: [PATCH 1/6] goals / platforms --- src/docs/goals/platforms.md | 56 +++++++++++++++++++++++++++---------- 1 file changed, 41 insertions(+), 15 deletions(-) diff --git a/src/docs/goals/platforms.md b/src/docs/goals/platforms.md index aba86027..020ec79c 100644 --- a/src/docs/goals/platforms.md +++ b/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 Auxilliary 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 valueable. 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 valueable 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. \ No newline at end of file From dfc9afa749dc671ba852b9cd8f5a7bdcb345eb91 Mon Sep 17 00:00:00 2001 From: Gary White Jr Date: Tue, 22 Nov 2022 11:19:15 -0500 Subject: [PATCH 2/6] splling --- src/docs/goals/platforms.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/docs/goals/platforms.md b/src/docs/goals/platforms.md index 020ec79c..99bb269f 100644 --- a/src/docs/goals/platforms.md +++ b/src/docs/goals/platforms.md @@ -3,7 +3,7 @@ title: "Platform" featured: ../images/featured/goals.png --- -In Auxilliary 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. +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. @@ -19,7 +19,7 @@ We believe in this methodology. A goal of any engagement in AuxEng is to provide 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 valueable. 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 valueable as building a critical change into our 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 From 3419eeed74107ae0a6166d1a4008caa903eba2af Mon Sep 17 00:00:00 2001 From: Gary White Jr Date: Tue, 22 Nov 2022 11:20:35 -0500 Subject: [PATCH 3/6] newline --- src/docs/goals/platforms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/goals/platforms.md b/src/docs/goals/platforms.md index 99bb269f..f33c8903 100644 --- a/src/docs/goals/platforms.md +++ b/src/docs/goals/platforms.md @@ -43,4 +43,4 @@ We do this not only to benefit the teams with knowledge of the software we write 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. \ No newline at end of file +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. From f731f1f46bb471d06e8f168e22455613a7e04296 Mon Sep 17 00:00:00 2001 From: Gary White Jr <7660110+GaryPWhite@users.noreply.github.com> Date: Thu, 5 Jan 2023 07:58:01 -0500 Subject: [PATCH 4/6] Apply suggestions from code review Co-authored-by: lelia --- src/docs/goals/platforms.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/docs/goals/platforms.md b/src/docs/goals/platforms.md index f33c8903..3cc93387 100644 --- a/src/docs/goals/platforms.md +++ b/src/docs/goals/platforms.md @@ -7,17 +7,17 @@ In Auxiliary Engineering, we move out to consumer teams from a product team to s 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. +Our goals through Aux Eng provide benefits to any team developing or maintaining a platform. -## Product, Platform, AuxEng +## Product, Platform, Aux Eng -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. +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 effect 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. +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. @@ -29,13 +29,13 @@ It's a goal of Aux Eng programs to bring perspective and understanding of the so ## 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. +Another goal of Aux Eng 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 Aux Eng 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. +It's a goal of Aux Eng 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. @@ -43,4 +43,4 @@ We do this not only to benefit the teams with knowledge of the software we write 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. +It's a goal of every Aux Engagement to find "champions" — enthusiastic users or adopters of our systems — who regularly provide input and offer feedback on how the platform is working for our engineering population. Learning about how changes affect users, how adoption is growing, and gauging general sentiment from these advocates helps us make better directional and strategic decisions on how to operate and maintain our platform. From 64e780906cb87a5c5dcadb4dab6ed6266ad29cbe Mon Sep 17 00:00:00 2001 From: Gary White Jr Date: Tue, 10 Jan 2023 08:08:20 -0500 Subject: [PATCH 5/6] line length linting --- src/docs/goals/platforms.md | 96 ++++++++++++++++++++++++++++++------- 1 file changed, 79 insertions(+), 17 deletions(-) diff --git a/src/docs/goals/platforms.md b/src/docs/goals/platforms.md index 0e542a6b..273ac985 100644 --- a/src/docs/goals/platforms.md +++ b/src/docs/goals/platforms.md @@ -3,44 +3,106 @@ title: "Platform" featured: ../images/featured/goals.png --- -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. +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. +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 Aux Eng provide benefits to any team developing or maintaining a platform. +Our goals through Aux Eng provide benefits to any team developing or maintaining +a platform. ## Product, Platform, Aux Eng -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 effect their code may have on their users. The team _learns_ from those measurements, and synthesizes ideas on what to build next. +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 effect 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. +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. +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. +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. +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 Aux Eng 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 Aux Eng reaps benefits of empathy and respect. +Another goal of Aux Eng 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 Aux Eng 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 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 Aux Eng 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. +It's a goal of Aux Eng 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. +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 — who regularly provide input and offer feedback on how the platform is working for our engineering population. Learning about how changes affect users, how adoption is growing, and gauging general sentiment from these advocates helps us make better directional and strategic decisions on how to operate and maintain our platform. \ No newline at end of file +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 — who regularly provide input and offer feedback on how +the platform is working for our engineering population. Learning about how +changes affect users, how adoption is growing, and gauging general sentiment +from these advocates helps us make better directional and strategic decisions +on how to operate and maintain our platform. From a85037745828a867082f0722411539c1b2e3aa95 Mon Sep 17 00:00:00 2001 From: Gary White Jr Date: Tue, 10 Jan 2023 11:55:40 -0500 Subject: [PATCH 6/6] convery --- src/docs/goals/platforms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/goals/platforms.md b/src/docs/goals/platforms.md index 273ac985..84a9d47b 100644 --- a/src/docs/goals/platforms.md +++ b/src/docs/goals/platforms.md @@ -60,7 +60,7 @@ 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 +an engineer will convey 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.