Documentation should come from a place of empathy - easing someone else’s journey can enable them to do even more innovation. Documentation requires feedback and requires humility. I used to be one of those women who said “but I’m not technical.” Even after I had created technical marketing materials and guides and lead the third largest user group for AWS in North America. Done well, documentation lowers the barriers for others, foster open collaboration, and create adaptive guides for everything from process to product. Building docs always made sense to me. If I can learn it, write down steps, and then lead others through a process it’s less work for the next person. Building the docs I wanted to see helped me lay the groundwork for my own journey from a non-technical marketing specialist to a Solutions Engineer with an AWS Certified Solutions Architect Associate and enthusiastic community member. What finally made me realize that I could be technical and could confidently do technical work was documentation.

1. What is a “fake” architect? I’m surrounded by mechanical engineers and “real” architects .

   • Starting off with a non-technical outsider perspective can help, but people like the details
   • Being asked “gotcha” technical questions at trade show booth and the assumption that women aren’t the most technical were the challenges I needed to prove myself.
   • “Soft skills” are really just My notes were for myself but were more useful than our internal documentation.

2. “Why use a picture when a thousand words will do?” - Actual product documentation shouldn’t be PDFs of slides without any visuals

   • We needed new/better/useful docs and our CEO finally realized it.
   • I learned markdown and gitbooks, which also meant learning git, terminal, versioning, GitHub
   • NC was the mentor I needed, having time and being self-managed gave me the opportunity
   • I joined DevOpsDays Chicago as a co-organizer and saw “real devops” in practice (not all source code on a black box and 1 big update a year.
   • Outcome: online, searchable, easily updated docs and the confidence I needed to start side projects, learn, and start looking for technical roles.

3. “I can do more than order the pizzas”- Running the Chicago AWS user group

   • I helped merge 3 groups around AWS before Amazon step foot in IL back in 2015, but organizing events could be exhausting. I needed to share the knowledge. * As we had more topics on certifications and talks from other beginners, it challenged me to get AWS certified.
   • My 2 side projects were to create static websites on S3, one for the user group and one for myself.
   • User group website (http://chicagoaws.com) has FAQs and our COC to be more transparent and welcoming. Plus, a Slack inviter integration allows members to self-join our Slack workspace.
   • I put DevOps concepts in action for the user group: more transparency, collaboration on topics and talks, knowledge sharing, asking for feedback in member surveys and doing a yearly retro.
   • Outcome: I’m an AWS Certified Solutions Architect Assoc. ; the user group has over 4,000 members and is an active, interactive group on Slack

4. Knock down silos with good docs * Empower teams to remove barriers and reduce wasteful handoffs by writing the docs ourselves

   • Docs are guidelines not standards. Focus on enabling lateral sharing through free flow of information.
   • Define your customers as anyone who may benefit from your docs - teammates, end users, business users, customers
   • Doc enable folks to broaden their skills in any direction - learn more technical skills, lead teams, interact more with management levels