1. Improve
1.1. Give to teams the time to select the best tools for their work
1.2. Setup review / assessment of the current stack / periodically
1.3. Proactively investigate new tools for new projects
1.4. POC the selected new tools
1.5. Share feedback from the new tool POCs accorss the community
2. Understand
2.1. No one knows better than practitioners what they need to be effective.
2.2. Meaning
2.2.1. Practitioner tool choice helps to drive better outcomes.
3. Pitfalls
3.1. Give zero choice
3.1.1. Pros
3.1.1.1. Improve standardization
3.1.2. Cons
3.1.2.1. On solution may not fit all usages
3.1.2.2. No room for experimentation
3.1.2.3. Miss emerging tech and the related benefits
3.2. Give too much choice
3.2.1. To much technical debt
3.2.2. Run cost too hiigh
4. Implement
4.1. Balance
4.1.1. up
4.1.1.1. freedom to chosse tools
4.1.1.2. Get benefits from emerging tech
4.1.2. down
4.1.2.1. cost to acquire and run
4.1.2.2. complexity of communicating between teams using different tools
4.2. How
4.2.1. Establish a cross-team baseline
4.2.1.1. Tool users form diverse teams
4.2.1.1.1. Product owners, Product Managers
4.2.1.1.2. Developers, Software Engineers
4.2.1.1.3. DevOps, Operators
4.2.1.1.4. ...
4.2.1.2. Baseline of approved tools
4.2.1.2.1. Large
4.2.1.2.2. Diverse
4.2.2. Establish cycle to update the baseline
4.2.2.1. incl in spint retro
4.2.3. Define a process for expections
4.2.3.1. E.g. Lead horses process
5. @ google
5.1. Prefered stack is supported by default
5.2. If a team feels strongly need something else
5.2.1. then free to chosse it
5.2.2. And do the work to support it