Measuring Developers Isn’t Tyranny
Informing someone that you want to “measure” them is not a great way to start a conversation. Software developers, like all people, tend to look unfavorably upon having their performance closely measured. But measuring developers is one of the hottest trends for companies around the globe. So is it tyranny to measure people?
People are quick to note that numbers don’t tell the whole story and can become defensive at the notion their productivity should be quantified somehow. This resistance can become even more entrenched when teams become stacked against each other.
Many leaders — like Netflix’s Kathryn Koehler — believe we should absolutely avoid stack ranking of individuals and teams. After all, the human elements of teams — communication, coordination, leadership — can all affect the speed or perceived productivity of a team or process, so how can you quantify that?
Thankfully, plenty of tools exist to enable a data-driven approach to the development process. With the right approach, these tools can be used to enhance any individual’s or team’s performance. Beyond performance, when applied correctly, these tools can bring about more harmonious alignment between leadership and employees.
But first, why do we measure?
Why measure at all?
It’s important to remember that measuring is just a tool — it can be used for both good and for evil. An effective leadership team understands this basic fact. The cool thing about metrics is that they provide insight that might otherwise be difficult to obtain. Employees should note that good leadership will use metrics merely to inform their decisions, not solely drive them.
As a basic rule, it is difficult to improve something that is not measured.
"I started with the really basic observation that I believe you cannot be sure that you’re improving something if you don’t measure it, right? I mean, think of trying to lose weight without weighing yourself." -Luca Rossi, from the Dev Interrupted Podcast at 4:31
Measuring creates a foundation — a benchmark — which can be built upon. Once this foundation is established, organizations can begin to set goals. If you can set goals, you can rally a team; and if you can rally a team, you can achieve your product goals. This all becomes easier when you adopt a quantitative approach to your process. Success flows from the foundational element that measuring provides.
Lastly, there exists a psychological benefit to measuring: namely, that people implicitly understand that metrics which are measured are important. After all, no one measures something they don’t care about. That which leadership identifies as measurable naturally informs employees what metrics leadership thinks are important. The very act of deciding to measure something telegraphs your intentions. Inversely, the opposite is also true: people tend to believe what is not measured is not important.
All of this means leadership should be careful to identify what metrics are important because they define your organization and its behavior.
What should be measured?
First, an organization must decide what metrics are worthy and whether or not they are actionable. A lean approach is best here. Decide what does and does not matter to you, and then move confidently in that direction.
So what metrics are worthy to an engineering team?
There are many valid metrics which include things like Velocity, Branch Coverage, and Cycle Time, but one of the most interesting metrics we care about at LinearB is the Pull Request. In fact, it’s kind of our thing.
A pull request has two major goals: the first is to improve the quality of code before you release it, while the second is to share knowledge between the team about the code base.
Pull Requests are great because they let your team have control over what goes into git; they let people comment about what and why things were done a certain way; and they can serve as permanent documentation about a chunk of code that can be useful down the road.
If we at LinearB were to recommend one metric to start measuring, it would be Pull Request Size. Measuring PR Size — and using that measurement to encourage smaller Pull Requests — will help drastically lower Cycle Time. It will encourage all kinds of good behavior around code reviews, and it will prove that metrics can have a positive impact on business outcomes.
Once you have identified the best metrics to track for your success, you will need to go about making sure they last. Here it is best to maintain a lean approach, avoiding large upfront investments of time or money.
How to make metrics stick
"And you should, as a leader, as a manager, you should make people feel that you care. There is no substitute for that." — Luca Rossi, from the Dev Interrupted Podcast at 21:10
We have all worked at a company where a change was decided, people were excited to see the change and then, after a couple of months, everyone has forgotten about it. Metrics are no different. Once a company makes the decision to align itself with a metric it must make the effort for it to last.
It’s often best to start small. In the beginning, it is best to maintain a lean approach, avoiding large upfront investments of time or money. With small actionable change in mind, there are two ways to approach metrics adoption:
In a top-down approach you ‘ll want to speak with your senior developers early on. Give them strategic input to help them figure out the best way to implement metrics into your dev team. An engineering leader can then explain how the metrics fit into the company’s strategic direction and convey that message clearly to employees. It is important to get buy-in from your employees because they are the ones building value, and further discovering what can and should be measured. When done correctly, the top-down approach will have managers saying, “Wow, I’ve always wanted to measure this. Now I can.”
In a bottom-up approach, it’s all about making your team understand what you want to achieve. Provide them with the initiative to build value so they understand why and how they are being measured. For instance, most developers can relate to a bad pull request experience — one that takes way too long or one that has a poor review and causes issues during production. People understand that a good code review should be both fast and accurate. So by starting small with a metric that is already understood, you will gain buy-in from your team. When done correctly, the bottom-up approach will have employees saying, “Wow, we didn’t think we could measure this, and it’s actually valuable.”
How you approach adjusting for change in the long-term is up to you. In an ideal world, both the top-down and bottom-up approaches would be utilized simultaneously.
Most importantly, your people should know that you care and that you value their feedback.
Bottom Line
To achieve future goals a development team should know where it started. Metrics provide that benchmark. They are a foundation on which future success and business alignment can be built.
Furthermore, in engineering, just as in life, tiny improvements are staggering when tracked continuously over a period of months and years. These gains boost team confidence and collaboration.
Because with continual improvement, people feel as if they are working within a team and working as a team. When things go right, and everyone improves together, bonds are formed.
And of course, if you want to learn more about LinearB’s metrics or find out what our customers already know, you can book a free demo of LinearB .
I included a few quotes from Luca Rossi above. He has a great blog for those who are passionate about engineering. You can check it out here: https://refactoring.fm/
If you haven't already heard, Dev Interrupted is hosting INTERACT: An interactive, community-driven, digital conference on September 30th - by engineering leaders, for engineering leaders. 1 day, 10 speakers, 100s of engineers and engineering leaders, all free.
Top comments (3)
Hmm well I suppose the logic on weighing yourself makes sense. I mean, I don't "wing it" on most things I'm attempting to improve over time. But there's got to be some kind of balance with leadership.
I like the "bottom up" approach! Give us the agency to see the change on our end, allowing us to implement as part of an ongoing process. This way any changes feel more implicit and less draconian.
Measuring pull requests is great if your job is manufacturing pull requests.