Influence without authority

Driving accessibility through the Microsoft enterprise internal applications has given me a lot of lessons in influencing the direction of large and chaotic teams and individuals without any authority over them.
Some key factors that helped me include:

1. Clear data
2. Lots of communication
3. Clear policies and processes that scale
4. Forming trusted partnerships

When I joined the accessibility team in Microsoft IT, accessibility was treated as an avoidable compliance exercise and most engineering teams did not understand why they even needed to look at accessibility.
We had the task of improving the abismal state of application accessibility across the enterprise, reducing the cost of compliance, and embedding accessibility into the culture and DNA of enterprise development across engineering teams.
One of the first things I did was to set up a data platform to collect information about our application inventory, assessment and compliance status, and bug status.
This allowed us to communicate with various stakeholders the clear state of our portfolio, identify areas that required most attention, plan and track progress and manage bottlenecks as they arose.
We developed clear communication on our overall strategy for various parts of the problems, such as measuring accessibility, third party applications, and the training needs of the org. This clear communication helped demystify accessibility for most of the organization and presented a clear path forward that everyone understood.
We got alignment with engineering leaders on targets for compliance by showing them the clear data and progress. At the same time, we developed trainings on accessibility fundamentals, deep dive technical topics, and accessibility during design for the engineering teams.
Through this top down and bottom-up approach of making accessibility an important measurable goal for engineering leaders and enabling engineering teams to design and implement accessibility, we were able to build a momentum for more accessibility than ever before. We achieved 100% accessibility compliance in all priority 1 and 2 applications developed completely by our engineering teams in 2020 for the first time in history.
We also identified bottlenecks to scale in the form of ambiguous policies and procedures that made achieving accessibility hard for engineering teams and worked to streamline and document these. This allowed us to scale across the large enterprise while also giving us a baseline from which to incrementally improve.
Finally, what helped us a lot was forming trust with engineering teams where they viewed the accessibility team as apartner in their success rather than a hurdle to compliance. We did this by:

• helping them with customized and targetted trainings for their specific needs
• helping with design reviews and moving accessibility left in their design and build processes and reducing cost of compliance
• advocating with leadership for dedicated resources for these teams for accessibility
• and recognizing the good work done by these teams in larger forums making it valuable for teams to focus on this work

This last part has been the key to turning around the culture and embedding accessibility in the DNA of development.
Although we still have a long way to go and the work has just started, the above 4 things of basing actions on data, lots of clear communication, removing ambiguity, and forming trusted partnerships has helped our small accessibility team to have a large influence on the org with any real authority.