They didn't measure when work got done. They measured when people chose to update their project management software. That doesn't necessarily correlate in any way with when the work is actually getting done. So all of their conclusions are based on flawed assumptions and a bad data set.
Anecdotally, I am an active user of multiple project management platforms and do my best to keep them actively up to date. When I am in a state of flow and being productive I almost never break it to update the project management platform.
I'm honestly not sure there's much of a pattern to when it gets updated. Sometimes it's when I'm trying to get into a work mindset and remember what I did the day before. Sometimes it's when I'm winding down at the end of the day and making note of what I did. Sometimes it's in between tasks.
A better measure might be when git commits were made to repositories, but even that is a pretty imperfect measure. I often don't made small commits as a I work, but large ones once a cohesive portion of the task is complete (or several small ones as the same time using git add -p).
Thank you for pointing this out. I know that for myself, Jira updates and high productivity work are anticorrelated. I'm not going to update a ticket while I'm focused on code, and large blocks of flow-requiring work often don't even justify ticket updates until they're done.
Fundamentally, this data just looks like "people update tickets before lunch and before the end of the day", which is hardly interesting.
In fact, I think any quantitative measure of tangible results would be flawed, at least when it comes to open-ended and creative work (research, exploratory data analysis, software design, ...). In my work as a PhD student I often have a full day, damn, even a full week without any tangible result. But when the results eventually do arrive I usually realize that those seemingly unproductive hours actually were valuable, perhaps even necessary.
This is a really good analysis. I wonder if the best measure of productivity might be the number of times someone saves a file in their text editor?
Or if you took git commits, but also measured their size, and came up with an average size of commit per hour of work. That way you could use the size of the commit to roll the clock back and determine when most of that work was done?
This data was collected by a project management software tools company.
As such, I suspect most of it is bullshit generated whenever the people who do the actual work decide to key in the minimum amount of info in order to keep the "project management professionals" off their backs.
Monday mornings are a great time to get "boilerplate" work done to satisfy PM's.
When the _actual_ work gets done depends on the individuals, their teams, and the projects.
Even aside from, er, "defensive management", I doubt the quality of this data. My team has triage meetings Monday at 11 AM. The number of tickets 'created' or 'completed' during that one hour stretch is probably 30% of the total for the whole week, but that's a function of coordination and scheduling that says nothing about actual work completion.
The time or day I complete a task is unlikely the same time or day I spent working on it.
If I complete a task at 11 a.m. I've probably worked on it the day before and just wrapped up final testing before 11 a.m. Same with Monday being the "most productive".
For that matter, the time you're in the office updating tickets isn't necessarily linked to your work hours.
Lots of people operate on schedules like "think of a good answer to the problem at 8 PM, crank out two hours of work, roll in at 11 AM to test the fix and update the ticket". As far as this study knows, that work pattern equals "high productivity at 11 AM", even though all of the actual work happened during the "low productivity" timeframe.
They gathered data of office robots that start to work between 8 and 9. Also it's only data of robots forced to use a particular tracking tool. Yes, a work cycle is 2-3-4 hours after having started fresh. Start at 11 and mark something as done at 14.
That sponsored article should be categorized using their book titles advertised at the bottom: "The Content Marketing Handbook", "Hipster Business Models" and "Everything is Bullshit".
"office robots" is a generalization you're making, and weakening your point with an insult.
That said, without actually describing in more detail how they measure it, yes, it's very, very circumspect. I'd wager even more so than just asking people "hey, when do you feel most productive?" Because the time I mark something done in JIRA, say, is barely correlated to when I spent the most time and focus on it (and even that correlation is not being picked up here. That is, I'd say "The time I spent the most effort on a problem is within 4 working hours of the time I marked it done, unless I completed it first thing in the morning, as I might wait until the end of the day to mark it done, and also barring a whole flurry of initial effort, it not getting me anywhere, I take a break, realized I was thinking about it wrong, go back and get it done in minutes").
Some of the bar plots seem misleading because of the scaling. The monthly one, for example, almost made me believe that January is half as productive as October. The "zero" level is not stated anywhere, but the lowest value is still halfway to the top.
This feels like intentional exaggeration to me. If the lowest value started at the base line, like they do e.g. in currency exchange plots, there would be no doubt about offset. This way, the initial impulse is to compare areas of the bars.
The article doesn't make it clear what their data source for this is - but I'd have thought that would have a big impact.
If you measure the time I commit code, you'll find the most happens just before I go home every evening; if you measure the time I mark tasks as complete in a task-tracking system it's at a scheduled daily stand-up meeting. So different data sources would show different results.
With a little digging - it's when tickets are 'created' or 'completed' in one type of project management software. (The article is basically an informal ad for Redbooth, where the blog post first appeared.)
Commit times would have been a decent metric, though devs obviously vary a lot in how they structure and time their commits. But this study used ticket-completion, and finds lots of work gets done at 10-11 AM and 4 PM. Which looks suspiciously like a whole day's work has been logged during morning standup and before-leaving ticket checks.
Me too, perhaps its because I'm a procrastinator and put off everything to the end of the day when I try to get everything done. Friday evenings are most productive!
I have the exact opposite. I'm a productivity monster from the moment I wake up to roughly 1pm, then after that my productivity slowly declines and after 6pm I'm utterly useless.
Seems like every time I figure out something, it's first thing the very next day. Toiling away all day on a problem, only to solve it the next morning. So the first couple hours of work, probably my most productive.
I've found that sleeping on a problem is usually the best way to solve it if you're stuck. Sometimes you get too stuck into one way of thinking, can't see the forest for the trees, so to say.
The work week in my organization is M-Su. I'm not particularly awake on Monday mornings, so I fill out and submit my time sheet for the previous week, which may include support hours over the weekend. Due to my brain core dumping over the weekend anything I did the previous week, I have to piece together what I did from my calendar and Sent folder.
Usually my periods of high productivity are 10am-12pm, 3-5pm, and 7-9pm. (I'm not usually in the office after 5pm so my employer doesn't benefit from the last burst. But they would if I did.)
Friday is my day to get backlog stuff done. Depending on how you define productivity, I'm either highly productive at solving old bugs, doing documentation updates, etc. or not productive at all on Fridays.
I have to echo others' sentiments: the analysis is severely flawed.
[EDIT: Added paragraph starting with "Friday is...".]
(<speculation>)Maybe because offices are calmer, so it's easier to concentrate?(</speculation>) It tends to work for me so I would be curious to know why it is so.
So our work ramps up as people get to the office, and drops when we leave for lunch. Likewise, we ramp up as the year progresses, until we slow down at the holidays.
Am I missing something, or is this data so aggregated that it has become useless?
I'd stick my head out and guess they promote at year end. That's why people complete most tasks in Sep-Nov, just in time for promotion/salary increase. From January, no one cares about performance for another 6 months so performance is low.
January being the worst, and October being the best months for productivity matches my own perception. Not so sure about summer though.. when it’s really hot, motivation tends to go down along with blood pressure :)
This is not consistent with what I'm seeing. Monday before 2 pm nothing happens. Between Monday 2 pm and 5 pm suddenly everybody wants to get 2 days of work done and fails. And tuesday normal, regular, productive work starts, and continues until Friday. Usually the tough thing is on oneself to really stop between 5 pm and 6 pm because then the productivity drops severly.
My guess would be from these observations, that the most success happen Thursday around 3 pm. But maybe software development is special since there are few tasks that could be done in 1.5 hours anyways.
I think the problem is that they looked at completed projects. So if you were productive Tue-Fri, maybe you still need to write some comments or docs to complete the task which is perfect for a Monday morning.
Looking at hourly data, number of completed tasks should be a measure for low productivity.
Everyone works 7:30 - 3:30 in my metro area in an attempt to beat rush hour. 11am (listed as the most productive hour in this article) is when folks start eating lunch.
I can see that this must be an aggregation of different work patterns. I'm not a statistics person so is there some way to estimate the source 'curves' from this. I.e. I know that I'm most productive from around 7.30 am until about midday.
It took two whole companies to produce a couple of extremely basic histograms? And given the flimsiness of the data (self-reported, no clear definition of "tasks"), neither company felt it was necessary to include a margin of error calculation, or other disclaimer? This is utter garbage, just filler to take up space on a blog (two blogs, actually) and patting themselves on the back for producing absolutely nothing.
Anecdotally, I am an active user of multiple project management platforms and do my best to keep them actively up to date. When I am in a state of flow and being productive I almost never break it to update the project management platform.
I'm honestly not sure there's much of a pattern to when it gets updated. Sometimes it's when I'm trying to get into a work mindset and remember what I did the day before. Sometimes it's when I'm winding down at the end of the day and making note of what I did. Sometimes it's in between tasks.
A better measure might be when git commits were made to repositories, but even that is a pretty imperfect measure. I often don't made small commits as a I work, but large ones once a cohesive portion of the task is complete (or several small ones as the same time using git add -p).