How Metrics Helped Me Find My Voice as a Female Software Engineer
Many software engineers approach productivity metrics with cynicism and distrust; they see them as a way for managers to spy on employees and turn people into numbers. As a soft-spoken female in the male dominated high-tech industry, I have a different story to tell about software metrics. To me, they are not a threat, but a powerful ally in the battle to have my voice heard as both an individual contributor and as an engineering manager.
”The quiet girl”
Growing up, I was painfully shy and socially awkward. My mother says that, had I been born a decade later, Asperger’s Syndrome would have been an easy diagnosis. I was always “the quiet girl” at school and quickly learned that the loud children received all of the attention. When I immigrated to the United States in the first grade, I refused to speak for a long time, afraid that other children would make fun of me not only for my shyness but also for my accent. Numbers were always a comfort to me because they were a source of truth; they were never judgmental or cruel like my classmates. In addition to tracking grades, I enjoyed making pie charts and bar graphs for various metrics—the percentage of long words in my essays, the number of friends vs. bullies in my class, the length of time it would take the teacher to notice me when I raised my hand.
The only female in the room
Choosing a career in software engineering was easy for me; it was a place where I could retreat into a world of data and code and not be mocked for being a little strange. “My technical skills will speak for me,” I thought. However, software metrics in the late 90’s and the start of the decade were primitive, and I knew instinctively that counting lines of code couldn’t prove the worth of my accomplishments. While my skills got me through the door, I was often the only female in the room, and the men with the loudest voices, the best connections, and the ability to self-promote were the ones getting the majority of the credit. They were the ones getting the promotions. I felt alone.
After 15 years in the industry, mostly as an independent contractor, I didn’t have a sense of loyalty to any company nor a sense of belonging within the tech community. I decided to leave my career behind and spend time homeschooling my young children and working on my own software projects (once a geek, always a geek).
Discovering software metrics as an individual contributor
After five years away from the tech industry, I decided to rejoin the workforce. My tech skills were old, so I did my best to skill up. I filled the gap on my resume with the independent projects I’d worked on. When I landed an interview with GitPrime, I spent hours pouring over their website and was amazed at how far software metrics had come from counting lines of code to an entire suite of measures that looked at code impact, efficiency, and best practices. I was overjoyed to receive an offer, but I also had a huge case of imposter syndrome since I’d never worked with their tech stack. Nevertheless, I was focused and ready to prove to everyone (including myself) that I could do it.
Two factors were instrumental in my successful return to the tech industry: having a supportive manager and using the GitPrime (now Flow) product. Every morning, I would check the Work Log report to make sure I was keeping up with my male counterparts in terms of commit frequency—we didn’t track other work types in those days. Then I’d go to the Developer Snapshot report to verify that my commits were impactful and efficient, and to see recommendations for improvement. I moved on to Code Fundamentals for more insight on key software metrics. Was I “gaming the system”? Of course! And what did I learn by doing so? I learned good engineering practices - to make smaller, more frequent commits, to improve the efficiency of my code in order to reduce churn, to increase the quality of our code base by refactoring legacy code, and to help others. I knew that my manager, Todd, would be looking at these metrics regularly. Since I met or exceeded all our measures, the metrics spoke on my behalf and let Todd know how committed I was to being the best software engineer I could be. This, in turn, gave me the confidence and freedom to focus on other topics in our 1:1 meetings, like technical implementation strategies or product enhancements based on customer feedback. Todd was an amazing leader who reminded me of how much I was appreciated not just for my code, but for the entire range of strengths I brought to the table.
Using software metrics to empower my team
As an individual contributor, software metrics provided me with an objective way of showcasing my contributions. They strengthened my voice by proving that I deserved to be here. I shifted from a defensive mindset to a growth mindset where I could help my team and the company become even better. Within the first year, I was promoted to a Technical Lead. The imposter syndrome returned. The other engineering managers in the company were all male. I admired their executive presence and their ability to make everyone in a meeting feel comfortable. I wondered if “the quiet girl” could be an effective leader.
Once again, I turned to software metrics to even the playing field. The metrics, along with everything I learned from Todd, allowed me to lead with both reason and compassion. I knew from personal experience how uncomfortable it was to ask a manager for help, so I used metrics to help navigate those difficult conversations. With the aid of the GitPrime tool, I could spot if a team member was stuck, or if they were over-worked and in danger of burning out. I could point to the metrics when advocating for my team and when asking for more resources. The metrics gave me a platform to show off my team’s dedication to excellence in software engineering practices—no “executive presence” required!
Software metrics can democratize tech work!
By the time GitPrime was acquired by Pluralsight and renamed Flow, our reports had expanded to visualize multiple work items in addition to commits, including pull requests and tickets, which acknowledged that there are many different ways for individuals to contribute to a team’s success. I led the development of the Review and Collaboration module, with reports that allow teams to make continuous improvement efforts around knowledge sharing and flow efficiency. As the Flow product grew, so did I. I learned that processes and tools are not a substitute for individuals and interactions (although I challenge the notion that they are not related). I learned that even though metrics may not have the same biases as people, they are not perfect. Finally, I learned that you need to be vulnerable to be courageous (thanks, Brené Brown). But even as I pulled out of my comfort zone and dared to “be seen”, it gave me confidence to know that I had software metrics in my back pocket.
Pluralsight’s mission of “democratizing tech skills” presents a powerful vision of a world where technical skills are available to all. However, as a female in a male dominated industry I know that having those technical skills is only the first step towards feeling included. It’s difficult being in a workplace where you are in the minority. It’s difficult getting your contributions noticed when you don’t feel comfortable speaking out about your accomplishments. Software metrics alone will not solve inclusion problems in our industry. They are not a substitute for supportive colleagues and leaders. What they can do is serve as a tool to ”democratize tech work”, so we can discuss technical contributions without bias. I’m so proud to work on the Flow product at Pluralsight because I’ve experienced first-hand how Flow amplifies the voices of those who speak quietly: It helps them be heard.
In loving memory of Todd Tidwell (1975 - 2019)