No, you shouldn’t measure software engineers — but you should help them adopt best practices

McKinsey recently published an article titled “<a href="https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity" rel="noopener ugc nofollow" target="_blank">Yes, you can measure software developer productivity</a>” to collective gasps of horror within the industry. My own reaction was also visceral. I’ve seen the endgame of this and it’s not pretty. However, the paper answers a very real set of needs in software engineering organisations. Namely: <ul> <li>The need to develop the team dynamics towards being able to build better software, faster. Building software is not just about building software. It’s about building teams and environments that become increasingly effective at building software. <a href="https://medium.com/p/d15814eb5cb2" rel="noopener">I’ve written about the importance of this before</a>.</li> <li>The need for teams to be able to demonstrate their progress and health. From a business perspective, senior executives cannot have an area of the business that is a black box. This is an area where teams and organisations often fall down. Namely, in failing to develop the ways in which they share context with the rest of the business. Nature abhors a vacuum and this paper is very much written to appeal to executives who want to feel confident their engineering organisations are operating well. If you don’t invest in sharing context with your executive team then they are going to feel obligated to come and collect it from you. It is always better to volunteer context on your terms than have someone with less understanding of your role impose it on you. Trust me when I say that working for the Eye of Sauron is unpleasant.</li> </ul> <a href="https://betterprogramming.pub/no-you-shouldnt-measure-software-engineers-but-you-should-help-them-adopt-best-practices-a5efa0ba446d">Website</a>