A few months ago, I read an article about WordPress uber-company Automattic that, despite being well written and transparent, really rubbed me the wrong way. The article was largely about Automattic’s highly unorthodox view on productivity.
“In a company, what matters is output,” [Automattic CEO Matt] Mullenweg told attendees. “We think someone’s working if they show up in the morning and they’re not drunk, they don’t sleep at their desk, and they leave at the right time and they’re dressed nicely … but that has so little to do with what you create. We all know people who create a lot without maybe fitting into those norms,” Mullenweg said. Perhaps someone could do the work it takes the rest of the team eight to 10 hours to do in one hour, and good for them, Mullenweg noted.[ref]Automattic’s Unorthodox View on Productivity Tracks Output, Not Appearance[/ref]
On the one hand, I agree with the sentiment reflected by these statements. On the other hand, it’s a highly dangerous slope on which to tread.
Productivity and Metrics
All of my software-related jobs have been salaried.[ref]Having a salaried position and not consistently working > 40 hours per week is another issue I want to discuss, but that will come later.[/ref] Most of them have also required me to track my working hours. Some because our managers didn’t trust that people were actually working the hours they said they were working. Others because our compensation was partially based on profit sharing and the management team needed to know how to properly divvy up bonuses.
In all of these cases, the argument for paying a fixed salary was that we were paid to do a specific job. Whether that job took us 8 hours, 6 hours, or 10 hours, we were paid for and expected to complete the job. The conflict here arises in the nuanced nature of skills.
Sometimes I could complete a task in an hour that would take my coworker 8 hours. Did that mean I could go home since I’d already completed 8 hours of work? No. Even though I’d finished significantly ahead of schedule, and completed the job for which I was paid to do, I was still expected to log 8 hours of work each day.
See the dilemma?
Our value was measured in output – the output of number of hours recorded to a timesheet. No bonuses were awarded for consistently coming through ahead of schedule. If anything, finishing early was penalized – coworkers despised you for making a difficult job look easy, and despite actually working to produce significant output in minimal time, you were still assigned extra projects to fill time.
The problem with this scenario is that there is no real way to judge productivity based on the hours spent at a desk. Likewise, there is no way to objectively gauge productivity based on output since each individual’s output is not equal.
Lines Of Code
To use another example, one company I worked at actively tracked the number of lines of code we wrote each day. Our productivity was measured using some algorithms that compared the raw number of lines produced, the number of commits we made to the team repository per day, and our tenure with the company. Longstanding employees were expected to produce less since they were (allegedly) mentoring and reviewing more frequently. New hires were expected to produce a remarkable amount of code in contrast.
It was unsustainable, and we ended up rejecting the entire measurement system after a (somewhat awkward) team standup meeting.
Everyone was reporting the lines of code they’d written. Some were in the 4-500 range. Others a bit higher, some a bit lower. When it was my turn, I proudly explained how I’d deleted 600 lines of code the previous day.
The project manager was confused how I’d deleted code while still shipping new features. My boss thought it was hilarious. We gave up trying to measure something as ambiguous as productivity since, honestly, my 600-line deletion had been more productive than many 400-line additions.
Some Forms of Productivity Can’t be Measured
Every day I diligently log my hours into our team time tracking system since billable hours is how we keep the lights on.[ref]Another point I’d like to debate at a future time. Also, ironically, one I’ve already started a bit of an argument about.[/ref] But billing hours is frequently an art form I’m just not good at.
When am I more productive – when I’m crunching out code like a monkey on speed? When I’m taking time to brainstorm a project before writing any code at all?
Thinking is something I do at my desk before I ever turn on my computer or even begin a project. It takes a lot of time, and there’s not much output I can put in front of a client to show “this is what I’ve done and what you’re paying for.” Still, when I take time to think things through, my code is cleaner, my projects more complete, and clients are ultimately happier.
When I don’t take time to think things through, it often results in a week-before-launch pivot in project requirements or a massive redesign of a clunky administrative interface or the need to call in a second engineer to help debug an issue that we could’ve caught day one.
I’m the most productive when I have time each day to stare at a wall and think. Unfortunately, logging or billing time for “staring into space” is seen as bad form. There’s no output; no deliverable. Though the finished product is worth the added investment, it’s a tough sell to any crowd.
This is why reading about how Automattic pays for “output” worries me. On the one hand, Matt is very clear in the distinction between how that output might take 8-10 hours for a team but be finished in an hour by a talented individual – and how this is a good thing. On the other hand, it’s very easy to slide backwards on that slope and ask, what did she do for the other 7 hours of her work day? How much time did she spend thinking about her implementation before writing code for an hour – are we paying for the time she spent staring into space?
I ask these questions not as hyperbole, but because I’ve worked in environments where they’ve come up. Sitting at your desk to think was penalized – don’t log that time you weren’t doing anything and I pay you to write code not daydream. Working hard on a project about which you’re passionate – and finishing early – was frowned upon. It made the team look bad and turned an enjoyable workplace into a toxic atmosphere.
If you pay for output – for productivity – how do you measure it? In finished deliverables? What of the projects that are sidelined before they’re ever shipped? If you pay for raw hours worked, how do you measure them? In hours spent writing code for client projects? What of the time spent switching gears between changing priorities or just clearing out head space to visualize a new project? What of the time spent not planning but brainstorming before even coming to a team meeting or writing down an idea?
Productivity is a metric that can’t be adequately measured. At the same time, I strongly agree it should be the only metric we care about (and the one upon which compensation should be based). With that said, how would you measure productivity?
