IMO: If your development organization reaches the point where this kind of advice from McKinsey & Co. might be able to improve things, you've already lost.
You don't need to measure software developer productivity. The article (or ad) admits as much:
> Further, attracting and retaining top software development talent depends in large part on providing a workplace and tools that allow engineers to do their best work and encourages their creativity.
So do that!
Happy people are productive, and talented, creative people move your business forward.
One issue with that logic is when you have people that don't care about being happy at the workplace and just act like they are working. Even if you intervene and try to honestly understand what is making them work the way they do, some of them will feed you with BS.
An option to deal with those people is to just fire them, simple. But that means you are giving up on them. Another option is to have an hybrid approach: those that work great with having happiness as a motivation, we can just continue to foster a happy workplace; for those that don't care about happiness, find another approach, one example would be to introduce KPIs for those specific people and formulate a performance recovery plan if needed, if all else fails, fire them.
Having mentored a dozen of developers over the years, I've arrived at a strong bias toward hiring intrinsically motivated individuals. It's much easier to grow skills given someone is motivated than vice versa. KPIs (or "SMART" objectives) are mostly managerial toys that seldom improve work ethos.
Happiness in the workplace is more often than not related to other aspects than the primary process of developing software. If the subject matter itself (as in: "I earn a living while hating the building websites in PHP") is the root cause of unhappiness, no recovery plan, KPI or reward can fix this. Best find another job.
SMART goals and KPIs are meant to improve work focus, not work ethos. Those two are not in opposition to each other. IME engineers who don't want to do measurably good work are inexperienced, disgruntled or unmotivated.
Forcing goals onto a disgruntled/unmotivated engineer will end badly.
Giving no goals to motivated engineers will also end badly.
Giving bad, unrelated or unachievable goals to motivated engineers will end in disgruntled or unmotivated engineers.
I have never met a productive software developer that didn't fundamentally enjoy his or her work ("happiness"). What do you do with an unhappy person? At some point, if everyone else is happy, it's just time for them to move on I think, and you probably have to "help them out".
McKinsey starts with the premise that the objective and mechanics underlying software development is known and well understood. In their line of reasoning, the only problem is that we're not measuring, and therefore that gathering more data and assembling it in a dashboard inherently will improve the process.
But as you allude, while it may be true that you "lose" 2 hours per day 3 days a week in some sense of productivity, that loss may simultaneously be the essence of some other sense of productivity. By suggesting it's "just data" and more of that is always good, McKinsey is (intentionally) glossing over / ignoring / hiding the fact that they will be doing the framing. (And that their framing is historically short sighted, superficial and often very wrong. See also: https://www.amazon.com/Big-Consulting-Businesses-Infantilize...)
Is this an appeal to authority? I don't see any insightful commentary in that link. So while I agree, I can't figure out what this adds to the discussion on HN.
