When technical managers and executives consider using commit data to make decisions, they often wonder how the decision will be treated by their developers. In three years of demos for our developer analytics product, about half of the executives we've chatted with have asked us what kind of reception to expect from their developers. It's a very top-of-mind question, and for good reason. If developer measurement draws the ire of those it is meant to help, that will offset any potential gains that measurement would otherwise deliver.
With those stakes, it's important not to sugar coat the truth. Developers will start suspicious.
Any developer productivity tool that tells you otherwise is giving you a sales pitch.
link"It's like big brother"
Managers already have an intuition that some of their developers might consider measurement akin to "big brother." Their intuition comes from being attuned to the disposition of the average developer. The best software writers are hyper-vigilant to think about edge cases -- particularly edge cases that could result in unintended consequences. So, the first reservation your developers will likely express is that measurement is bound to be imperfect. Relying on it could lead a manager toward misguided conclusions.
Why is it such a big deal if measurement is imperfect? Developers spend their career downstream from a diversity of managers, some of which are bound to be dumb misguided. That's why smart managers correctly intuit that developers will be suspicious of how any new measurement could later be used against them.
Not every developer will feel this way! Several will be eager to start measuring themselves, in hopes that they can use the new signal to learn the circumstances that correlate with their peak output. Many more will be indifferent toward the prospect.
It's when a team has 10+ developers that they are likely to find at least a couple with strong reservations about any newly introduced developer analytics.
linkDo concerned developers matter?
Managers sometimes point out to us that they don't mind if developer measurement dismays those who are already struggling. In this line of reasoning, it is considered "a feature" that measurement is often first embraced by those who excel at the thing being measured.
The existence of a growing ecosystem of tools like Code Climate Velocity, Pluralsight Flow, and BlueOptima prove that there is a robust appetite for tools that measure productivity or claim to predict coding performance, as BlueOptima's Predictive Assessment page promises:
BlueOptima's Predictive Assessment is a microcosm of what developers fear: an opaque measurement of "productivity," coupled with limited or no access granted to the developers themselves
BlueOptima's sales pitch depicts a happy couplet of manager and thriving developer. The productivity score is trending up, and the system's prediction is that great things are to come. The feedback scores are 📈📈📈. Even the hair is impeccable.
But when an edge case-minded developer sees this, they experience a foreboding premonition. They imagine the myriad ways that bad managers or outsiders could intentionally or unintentionally misuse an opaque "productivity score." They speculate that they may never be granted access to see their own productivity score, let alone scrutinize its validity. They might further speculate that whatever this "productivity" number is tracking will plummet the moment they lend a hand to a new teammate, participate in interviews, etc.
linkYou can't just hide it forever. They will know
When a developer gets wind that a new tool is being used to judge them, but that they will not be given access to it, the manager loses a few "benefit of the doubt" points. But it's not a huge deal -- the skeptical employee isn't likely to press for details. Instead, they'll take to Google to draw their own conclusions about how they're being judged, and whether it's fair.
When they find screenshots that show a developer being reduced to an opaque productivity score, the reflexive "but what if this isn't fair?" kicks in. The goodwill that the manager spent years building with their developers will be put to the test. Each manager and executive has a varying appetite for developer tumult, so maybe losing their developer's trust doesn't matter to them.
But if layoffs (or non-contract renewals) should follow the adoption of the tool, and the developers still can't access it, it's not a great look. BlueOptima's own Glassdoor page reflects the morale outcome. The HR department will bear the consequences of the dynamics created by opaque metrics creating morale fallout.
link
linkWhy GitClear built the first Developer-Friendly Analytics™️ platform
Why not give your developers a seat at the table when it comes to enhancing the throughput of your engineering efforts? Chances are they are familiar with the hurdles to their productivity and they have ideas of where to start improving things.
GitClear brands itself as the first Developer-Friendly Analytics™️ tool, because, at some point, the tech executive or manager will need to reveal they are using a developer analytics tool. The longer it's hidden, the more mistrust bursts open when the truth finds its way out.
When that conversation does happen, it can go one of two ways.
If the executive announces that stat access will be restricted to managers, it creates friction between the developers and managers in a company. Developers begin having Slack conversations to speculate about what the tool is measuring, and what they might do to game it.
The other option is for the executive to email their dev team upfront to announce they're be piloting a developer analytics tool. When developers hear that the tool is branded as "the first Developer-Friendly Analytics™️...they will still be skeptical at first (still not sugar coating this 😉). As they listen, you can explain that, in a world of opaque, manager-only tools, you picked the one developer analytics tool whose brand is to treat developers as partners in the effort to improve.
This difference is manifest by GitClear providing only metrics that are fair, transparent, and backed by research. You don't have to worry that you're going to have a "productivity score" or a "future productivity prediction" applied to you based on a machine learning algorithm branded as "AI." Instead, you get a platform where the primary metric is transparent down to the commit level and backed by empirical research.
linkBuilt for developers
Unlike the traditional Developer Analytic tools -- built for and by managers -- GitClear was built for developers, managers, and executives to use side-by-side.
This means we've released many features aimed at helping developers self-optimize. The greatest velocity gains occur when the individual developers across an entire team are excited to leverage GitClear's feature set to save time & inspire action. We save developers time by offering tools like a diff viewer that groups commits to reduce code review time by ~40%, and tools that can let a dev make a data-backed case that a service or module needs to be refactored before proceeding with new feature.
Those with a proactive streak will thrive when they see their Line Impact shoot up on days where they can delete a legacy, debt-ridden class. While customizable, the default mode for Line Impact is to disproportionately reward 1) removing legacy code 2) deleting code in general 3) writing and maintaining tests 4) writing and maintaining documentation. These are best practices that most developers strive to follow. Having a tool that makes it easier for them to track their own progress lets devs optimize for their long-term happiness.
Powerful visualizations that don't stop at 6 or 12 months back allow you to zoom out to assess how the team is improving from year-to-year
The reason GitClear puts powerful tools in the hands of every team member is to create an engineering culture that is both developer-friendly and incredibly productive. They don't have to be mutually exclusive. Transparency, shared understanding, and a mutual recognition of the limitations of metrics are the keys to consistently improving on past performance. More importantly, they are the keys to earning the trust of your developers so they will join your cause.
linkDon't compromise when it comes to transparency
If you're hoping to build a technology product that stands the test of time, use GitClear. Building for the long-term requires transparency across the entire team, not just a chosen few managers who wield opaque data against their suspicious coworkers. Long-term-minded executives realize that, to scale, the developers must be inspired to participate in improving engineering outcomes through data. Not just a select few managers.
By choosing the first Developer-Friendly Analytics Platform, you're committing to taking a shared responsibility to author great code at speed. When transparent measurement becomes a tenet of company culture, leaders are rewarded with velocity that improves via self-directed efforts. Managers lose the impetus to nag their direct reports when there is team-wide, real-time transparency. The collective transparency makes it obvious when a problem is underway.
When developers do struggle, you need trust and benefit of the doubt for a positive resolution. Data transparency facilitates high bandwidth conversations that simply aren't possible when the managers and developers are working from different signals of progress. With more than 20 reports that instrument every aspect of a team's performance -- from the rate of meaningful changes, to DORA stats, Cycle Time, deploy frequency, customer-observed bugs, tech debt, and more -- GitClear is ready to help you debug your team's biggest challenges, together.