[shagie]

While the "I'm sitting down and writing things that are going to be productive" is likely in the 10-20h/week range, there is still a lot of

  * Meetings
  * Mentoring
  * Answering random questions
  * Continuing education (Hey, Spring 6.0 was just released, what's in that?)
  * Support (and being available for support)

Those can easily fill in a lot of the 'void'.

I can point to 5h/week that are standing 'meetings' where it is often 'me helping out someone with a git or jira or GitHub issue' and it is that time that is designated each day (to try to avoid having the 'answering random questions' become too disruptive).

I am certainly not '40h/w, butt in seat, head down coding' and even though I may be only "productive" 10-20h/week, I'm certainly busy with work stuff to fill up the rest of my day. It's never "do an hour or two of work in the morning and day dream for the remaining six hours."

[PragmaticPulp]

Most of these conversations seem to come down to weird definitions of "productive time".

Most of us managers would consider meetings, mentoring, work-related Slack conversations to be productive time. Yet I read a lot of the comments here where people don't consider anything to be productive time unless they're actively writing code, which ignores the realities of working in a team environment.

A better metric might be tracking the amount of non-work time: Time spent on HN, social media, reading news articles, running errands. Again, us managers are realistic that everyone can (and should!) take small breaks throughout the day. However, if those breaks expand to fill 20-30 hours of the supposed 40-hour workweek, something has gone very wrong. That's certainly not normal at any well managed company.

[LightG]

But those weird definitions of productive almost never get spoken of or considered when it comes to timelining a project or KPI, etc

So while it may be important, it's just wasted time for many.

Says more about the organisation than the definitions, but still.

[coyotespike]

I completely agree.

In fact, even just for specifically code-related work, think about code review. Really closely reviewing a big PR can take hours.

Here's a fun thought experiment. How many engineers in a team do you need before one of them could be employed full-time just reviewing others' code?

I don't know the answer, but it could be as few as 10 other team members, depending on the size and complexity of the PRs.

And reviewing code is extraordinarily productive - looking for correctness, code style and patterns, tool selection and usage, app structure, etc., etc. One of the best ways to mentor team members and help keep the codebase clean.

[version_five]

There is a framework that we used to use for tim classification in manufacturing that was based around adding value to the product - in software that would be coding, testing, etc. Then there is necessary non-value add, like meetings and slack, that are needed (so are work as you say) but don't in themselves make the product directly, so you want to minimize time spent on them while still accomplishing whatever is needed (obviously easier said then done). Same goes for admin stuff. And then there is non-value add, like HN or whatever.

Personally, I think the non-value add category doesn't translate from a factory to coding. If your job is putting boxes on a pallet, when you're browsing HN instead you probably don't do it faster later. When coding, at least for me, I take breaks to think or clear my mind, and I'm not swapping productive coding for online time wasting, browsing HN (or taking a walk or coffee) is a necessary part of the work that improves productivity.

All that to say, meetings and other management stuff can and should be streamlined as much as possible, small breaks, not necessarily. If someone is actually typing code (or an equivalent activity) 25% of their time sitting at the computer, I'd consider that e extremely productive.

[brookst]

The value-add model is interesting. How would you characterize:

1. An hour-long meeting where architecture is decided

2. Doing investigation/documentation of RCA for an incident

3. Spec reviews with stakeholders who will have to use the product

[version_five]

Right, examples like yours are where it gets interesting. What I think can work is minimizing who needs to be involved in these kind of activities (not to say as few as possible, but only those its relevant too), and looking at how important they are to the desired outcomes, basically understanding how much time they take up vs what the return on the time is. All easier said than done of course.

[brookst]

I do like the idea. Maybe there’s a distinction between direct productivity and indirect, overhead-like contribution? Sort of the difference between gross margin and net income?

But it’s tough. As a product manager, I think that the right spec can greatly increase engineering efficiency. If that’s true, and bear with me, spending an extra 20 hours on a spec might save 1000 hours of dev time. Isn’t that the same as making those devs more productive? So do we count that work as 20 hours, or 1000 hours?

I like it in principle but I’m not sure it scales across disciplines.

[adave]

I would consider anytime you are thinking about a work issue as productive time. So yes that includes time i am mindlessly browsing HN while my brain is processing information for me to come up with a neat solution to a problem.

But yes managers dont get this when i say i get all my work done during lunch hour.

[mbrodersen]

I work for a company where meetings are extremely rare. We only do formal meetings when everything else fails. It is one of the most efficient/productive companies I have ever worked for.

The least efficient/productive company I have ever worked for had formal meetings all the time. What takes a week where I work now would take 6 months there.

So no I don’t agree that meetings are automatically productive/useful in general. I am pretty sure you can measure how productive a software company is by the following formula:

Time spent working on projects divided by Time spent in meetings.

[phphphphp]

You’re describing what I’d understand as productive time: if someone says they’re not being productive, I interpret it to mean there’s zero value to be derived for their employer from their activities. For example, being asleep or browsing Reddit or watching YouTube videos…

When I say I’ve only been productive for 20 hours in a week, I don’t mean I spent 20 hours programming and 20 hours in meetings, I mean I spent 10 hours programming and 10 hours in meetings. I’d be surprised if most people only count programming time as productive time! If you’re doing 40 hours a week of programming + meetings + support + any other needle-moving things, you’re more productive than I’ve ever been in a job.

[vsareto]

Being available is still useful to your employer on some level. Even if you are watching videos, you can close it the minute you get a ping that needs your attention.

The only completely unproductive state is if you're doing nothing for your job and also refuse to respond to communications.

[babypuncher]

This is my experience. I spend 10-20 hours a week doing work that fits my job description. The rest is learning, mentoring, and organizing with other parts of the business to better enable me in those 10-20 hours of "real" work.

That said, I feel you could cut my time on the clock from 40 hours a week to 32 with minimal-to-no impact on my total productivity.

[nickstinemates]

What is the definition of Productive here?

Is it lines of code or reasoning about lines which lines of code to write/adjust and everything else is not?

My definition would encompass all of the stuff you mentioned as ancillary. In some cases, it's even more Productive than the actual code writing.