Comment by ChanningAllen | Hacker News Reader

Comment by ChanningAllen | Hacker News Reader

> A natural fear is that by reducing the amount of work each employee tackles at any given time, it might reduce the total amount of work an organization is able to complete, making it less competitive. This fear is unfounded. As argued, when an individual’s work volume increases, so does the accompanying overhead and stress, reducing both the time remaining to actually execute the tasks and the quality of the results.

This is a central pillar of Newport's argument, and it doesn't hold water.

Anyone who has actually built and managed knowledge work teams knows that a "heavy burden" of work from the perspective of one employee might be "child's play" to another employee. Perhaps this is less true with blue-collar jobs, but it's emphatically true with knowledge work. Hell, it's even true with the same employee across time. (Coding work that would have overwhelmed me as a junior developer would bore me to tears today.)

If we're strictly talking about optimizing for market competitiveness, the onus is on Newport to explain how lowering the work burden for employees who can't sustainably do N units of work per week is a better idea than simply replacing those employees with others who can do N units/week.

They are proposing that the amount of work on a worker's plate at any one point in time should be reduced so they aren't always stressing about their backlog. They are not proposing that workers have less to do overall (otherwise, their claim of "increased productivity" is incoherent). The action from management would then be to organize the queuing and distribution of tasks and projects to shield workers from the administrative burden of recording an prioritizing it as it's launched at them via email or Slack. This is pretty basic work that I expect a manager to do.

Managers are generally pretty terrible at doing that without significant input from their reports, though. So you end up with small teams that managers can effectively do that work for... but then you end up with armies of lower-level managers who must then be managed by legions of mid-level managers, and so on. Controlling the flow of work to "producers" has a high organizational cost in bureaucracy.]

IMO the problem isn't "a lot of responsibilities", it's "a lot of things to worry about without the autonomy/authority necessary to resolve those worries". Big orgs tend to have more to worry about while also reducing autonomy and concentrating authority.

That's easy. And works well on an individual level or when you can pick and choose your workers (or they formed the company around those workers knowing each other in the first place).

When I had way more work piling up for my team than I had time to work on a lot of my time was spent in meetings or slack conversations in handling competing priorities and dealing with fallout from unhappy people. Be it on the worker or other side (product people, customer service people etc.). This is true both for the team members and myself as well.

Queue holiday time where we deliberately planned not to plan for so much. Also coincided with the newer team members having learned more of the ropes. Suddenly I don't spend 80% of my time on those ultimately unproductive things and I can concentrate on prepping work item properly for my team members, which enables them to do better work and I also have time to pull in extra items from the backlog.

This assumes that you have workers that will naturally do what I described above. The term I have heard thrown around for this before is to be 'value driven' vs being 'deadline driven'. Unfortunately it seems that most people are deadline driven. So if you can only use one blanket approach or you are deadline driven yourself you will use that approach. It sucks for us value driven people.

If you give me an unrealistic deadline for example you have a problem on your hands. We won't be friends and you will know it. If you don't and just work with me on getting whatever you need done done as quickly and efficiently as I can then we will do just that. And if I run out of work I find new work and start on it.

Example: our product owner told one of the stakeholders that we probably wouldn't be able to roll out a certain feature on time because of bugs we discovered that they wanted fixed before rollout (nevermind that they were minor edge cases that could have been fixed a week after release). I love our PO. Awesome guy. Turns out some big meetings were canceled a bit later. Picked up the bugs aand fixed all of them. We can release on time.

Now you will say this isn't your example. I say: to an observer would I not have seemed liked someone that wasn't able to do N units of work/week? And was this not simply a result the overall system I was stuck in? And isn't it true that many of us are stuck in metrics driven development teams where nothing but the N units of work per week metric count?

To quote the article, this was me:

    When you’re tackling too many such projects concurrently, however, the combined impact of all of the corresponding meetings and messages can take over most of your schedule, creating an overhead spiral of sorts in which you spend significantly more time talking about work than actually getting it done

Reply on news.ycombinator.com