[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.