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?
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.
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.
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, 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:
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.
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.
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/
Who says developers can't be the life of the party? Come see for yourself why the Dev Interrupted Discord has emerged as the go-to community for developers. Growing from 0-1400+ engineering leaders in just the past 8 months, our community is attracting the attention of CTOs and VPs of companies like Netflix, GitHub and Google. Join the community.