Aug 1, 2020
In 2017, as Expa was growing in both projects and developers, gaining insight to help manage a growing count was becoming increasingly difficult, and increasingly important. We wanted to learn more about how developers were spending their time, where they were getting stuck, and how we could help them improve. We had plenty of qualitative data from meetings, interactions, task management tools, 1-1 meetings, and our own thoughts and feelings (we are human, after all). But, we were missing quantitative data to pair with the qualitative, and we seeked an existing solution. There were a few products out there trying to tackle this, but we quickly discovered that they were focused on individual contributors, or stack-ranked developers in ways that weren’t constructive.
Shortly after this, I decided to do some internal tooling to see if we could close the gap between vanity metrics and the burning questions we had on how we could help our developers succeed. I wasn’t interested in who was writing more lines of code, but was instead fascinated with the question of what we could gain from the trove of data that sits within a git repo. And, maybe it was even possible to use that to solve bigger challenges — helping developers be more effective, recognizing non-communicated roadblocks, and learning more about what impacts them.
We had some good internal traction and positive reactions from both managers and developers in the Expa community (more on developer buy-in later), and decided to push to productize and share our solution with our broader network.
One of our earliest learnings was that for this product to work, it needed to have buy-in across the organization. Developers can’t be upset when they see their data, but also shouldn’t live in fear that their managers will use it as a sole indicator of success. After all, this isn’t sales — there’s no single (or multitude) of numbers that make a developer better or worse than the next. So, we prioritized creating a powerful enough interface that gave developers data about themselves and their impact that they would want to know. We also wanted to enable managers to get better insights into their teams patterns and flows, to effectively plan for the future, and resolve negative team patterns and roadblocks. This wasn’t an easy task, but we tried, and called it Gitalytics.
We released Gitalytics for a short time into the wild, as we continued to build an effective solution for developers and managers. Gitalytics transformed the huge amounts of data in git repos into meaningful, actionable insights. It was used by both small and large teams to improve their process. Gitalytics has become a valuable tool to help engineers improve their workflow, and help leaders make data-driven decisions on how to best enable their teams. This was a vision, shared by those with much greater influence, that can help usher in an era of positive qualitative metrics.
I’m excited to share that the team and the Gitalytics original platform turned into GitHub Insights — a new GitHub product that provides development metrics that matter. Moving forward, the team will be working to evolve GitHub Insights to best serve developers and teams, creating a platform that promotes collaboration and research-backed best practices.