Since starting GitClear, we've often been witness to how the prospect of measurement stirs reflexive concern among developers and some managers. Hackles are raised, quotes by Goodhart are brandished, and any opportunity to realize the benefits of measurement are lost.
The problem with a blanket dismissal of metrics is the opportunity cost. For companies that live or die by whether they can improve their product faster than competitors, it's not ok to rely on gut feeling to decide if the current circumstances are optimal. Having too many meetings, too much process, or too slow of a cycle time will strangle the company. Companies like this need a consistent, reliable guide. "Expert intuition" doesn't cut it.
That's why measurement should be a no-brainer at most any startup. If startups aren't seizing every opportunity to improve, they fail. What "measurement" represents to these teams is a piece of signal to help experiment against, if they want to try working 4 days per week or to create deep-work only days.
But not every company is a startup. How can we make metrics feel less dangerous for developers at mid-size and enterprise companies? Answering that question led us to our latest major GitClear release, which we're aliasing as the "Programmer's Paradise" release because it inverts the traditional power dynamic, putting developers above managers when it comes to report access. Specifically, filtering a report on an individual developer is now restricted to the developer themselves.
linkDesigning abuse-proof measurement
When developers hear measurement is coming to their team, their mind gets to work imagining what their company's version of "Ben" will do with it
At mid-sized and enterprise companies, getting the full upside from measurement requires getting the dev team to appreciate its benefits. That can only happen when developers trust that managers like Ben won't be able to take measurement and someday use it against them. Even if developers trust their current manager would use metrics fairly, they know that managers change. The only type of measurement that will do is one that remains safe & useful, even with a bad manager at the helm.
Between the Commit Activity Browser, File Browser, Collaboration Stats, and past GitClear releases have invested heavily in creating unique & valuable tools for developers. But all of that effort is for naught when the specter of "metric misuse" is in question. So we crafted a new policy document that pinpoints what GitClear reports exist, and what safeguards are in place to prevent abuse of those reports.
Read GitClear's policy on being the most developer-friendly data analytics tool. Page title notwithstanding, this isn't PR fluff. It is our published commitment to be transparent in our goal to actively engage with our community to design the most abuse-proof Developer Analytics tool on the market.
linkFive new features in v5
Let's start by recapping our two coolest features launched since v4 and then round out the top 5 with some newly launched features.
linkChart Glimpse
Publish the Commit Activity Browser and other GitClear charts to any web page or email with Chart Glimpses
This was our best feature launch of the past year. If you haven't tried Chart Glimpses yet, you're missing out on the opportunity to create a direct line of communication from your dev team to your customers, see example one and example two.
linkRestful API
Our fully documented restful API is now available to any customer -- no application process necessary. You email us what you want to access from the API, and we'll build it. 🤓
linkNew Team Switcher
Private browsing one's own commit stats
As described in our policy to avoid metric misuse, the only context in which GitClear shall aggregate Line Impact by developer is when a developer is viewing their own stats. It's the developers' business to choose how and if to change their habits. This new team menu replaces the "Developer Selector" from previous GitClear versions that would have allowed the stats of individual developers to be viewed (and potentially misinterpreted) by managers.
You can still request individual developer access as necessary to manage new hires.
linkInstant product feedback
Every page allows product feedback
Any time you reach out to us, we're dogfooding our API by creating a new Critical Defect ticket and tracking how long it takes us to respond. 🙂
linkChat about GitClear with its creators
Want to chat with GitClear's creators about improvements that would make GitClear better for your team? Join us on the Amplenote Discord server, where we have created a #gitclear channel to discuss the latest and greatest improvements.
linkWhat next?
We're eager to hear what use cases managers miss without a developer selector. We're eager to explore how to maintain those benefits in a way that's compatible with our newly ensconced policy to focus on improving the team, instead of picking out individuals. Drop us a line at support@gitclear.com, or visit the Discord mentioned above with your ideas on how to continue evolving GitClear into the best Developer Analytics tool for developers and managers alike.