The Productivity Trap
Measuring productivity is a tricky business.
Back in the early days of our journalism career, we worked for a consumer magazine, where a 100+ page book of articles had to be shipped to the printer each month. It was a high-productivity and arguably an inherently stressful environment.
The Editor-in-Chief, for instance, seemed very stressed. He took pride, for instance, in working at his desk late into the evenings. Oblivious to the impending printer deadline — a very expensive one to miss — he would toil on his computer to shape good stories into great ones. The rest of us would feel bad for leaving at 6 pm, with the editor alone sacrificing his personal time to the greater good of the magazine. His late-night labors, which he always humble-bragged about in the meetings, were a clearly an indication that this magazine was a place where you’d expect to work long hours.
But here’s the thing: This same Editor-in-Chief also took long leisurely lunches with writers and advertisers. He’d immerse himself in lengthy bull sessions with the editorial staff, even take in an afternoon baseball game at the downtown stadium a few blocks away — as a break from all his hard work!
Compare him to the Managing Editor of the very same magazine, who made it a point to never work more than 40 hours a week. She’d come first thing in the morning, stay focused and knock out everything on her considerable To-Do list and hit the elevators by 5:30 pm. None of those ballyhooed late nights for her, yet she was clearly the most productive employee there. She didn’t seem all that stressed either.
Who was the most productive? Depends on how you measure productivity, I guess.
The question of how to measure the productivity of developers has become a hot topic again, we noticed. Microsoft Research partner Dr. Nicole Forsgren wrote, in a paper for ACM Queue that “Unfortunately, after decades of research and practical development experience, knowing how to measure productivity or even define developer productivity has remained elusive, while myths about the topic are common.”
What makes for a productive programmer? Lines of code? Hours worked? Successful branch mergers?
In her paper, she decries the use of simple metrics. As Charles Goodhart pointed out, when a measure becomes a target, it ceases to measure anything of value. Instead, she created a more holistic framework for measuring developer productivity, called SMART, which takes in expected factors such as flow and satisfaction, but also some surprising ones, such as developer well-being and satisfaction.
In the weeks to come, we’ll be taking a closer look at developer productivity — what works and what doesn’t. Let us know what works for you: editors@thenewstack.io.
|