
Work Is a Queue of Queues - yarapavan
https://amontalenti.com/2019/11/04/work-is-a-queue-of-queues
======
layer8
I've been using the MYN system [1] for the last couple of years for work-
related todos. One aspect of it is what you could call a "priority stack".
That is, it behaves like a stack, except when you reprioritize items by
pulling them towards the top of the stack (upon daily/weekly/monthly review).
Items that turn out to be not important/urgent will tend to sink towards the
bottom of the stack, and the further down the stack, the less frequently you
review them. The algorithm is based on the insight that (a) you can't possibly
get everything done that you capture as a todo item, and (b) you don't know
beforehand which items are the ones that you can (or will have to) discard.
The staggered review process however automatically sorts them out.

Like GTD, MYN is a commercial product, however the book is affordable and the
main chapters are well worth reading, even if you don't use Outlook or
Toodledo (the two main tools used to present MYN).

[1]
[https://www.michaellinenberger.com/AboutMYN.html](https://www.michaellinenberger.com/AboutMYN.html)

------
reggieband
Transforming a team from stack to queue is one of the major improvements I aim
for on any team I join, although I hadn't really conceptualized this process
in those terms before this article.

The second is limiting who has access to enqueue work and the third is forcing
alignment on the set of people who prioritize the queue. Once that is done I
police any attempts to interrupt work-in-progress outside of established
processes (e.g. emergency/urgent response).

His descriptions of the activities of a CEO-level organization leader really
ring true to me. "1:1 meetings with staff, work anniversaries, performance
reviews, prospective sales conversations, partner checkpoints, hiring calls,
board meetings, investor update calls, and so on." It makes me wonder how well
I would do in the role of a CEO.

------
gwern
A more formal approach to the surprising implications of modeling work as a
queue: [https://blog.acolyer.org/2015/04/29/applying-the-
universal-s...](https://blog.acolyer.org/2015/04/29/applying-the-universal-
scalability-law-to-organisations/)

~~~
workthrowaway
> In theory there’s no difference between theory and practice, in practice
> there is.

love this :)

~~~
scott_s
I prefer: _The only difference between theory and practice is that in theory
there is no difference between theory and practice._

~~~
dkersten
I've always liked this version best: _" The difference between practice and
theory is greater in practice than it is in theory."_

~~~
larrik
My favorite version is "The difference between theory and practice is small in
theory and large in practice."

------
peter_d_sherman
Excerpt:

"Email is interesting, because most people wish email were a queue, and many
people try to turn email into a queue using a number of tools and practices,
but, in its standard implementation, email behaves much more like a stack.
(Some people joke that “email is your to-do list, but made by other people.”)"

Well said!

~~~
Forge36
A trick I learned which helped significantly was to sort "oldest" to the top.

~~~
dfee
A trick I learned was to not live out of email. It’s been an evolution, not
without its pain, but I’ve remained.

Now Slack I’m the other hand... there is somewhat of an expectation to be
regularly available.

------
Rerarom
"I remember learning the definition of a stack in college and being a little
surprised at “LIFO” behavior. [...] Practically speaking, this seems like a
“frenetic” or “unfair” way to do work [...] That’s when you tend to learn that
stacks aren’t usually used to track “work-in-progress”."

This tends to happen as a student learning abstractions - you judge them by
how they apply to a concrete situation that you cooked up in your head instead
of the ones they are actually applied to. One can, if they're not paying
attention, accumulate this way loads of weird feelings towards impersonal
abstractions.

------
adamwong246
I wish Jira would do something like this- collapse all dependencies between
tickets and turn my work into a queue, notifying me when it changes.

~~~
throwaway5752
As with most things in Jira it's possible to do this, and largely a question
of how it is configured. They have a Kanban template. You can usually define
all your item workflows, status, and write custom hooks in state transitions.
Nothing that couldn't be implemented with a little effort.

------
SubuSS
I would say work is a PQ of Queues - but overall sounds about right. As
someone with a 25hrs/week meeting load, lists and lists of lists are pretty
much my go to for keeping sanity!

------
zentiggr
One big thing I see with feelin g like email is a stack is GMail's insistence
on newest first and no sort option.

I have Thunderbird set up with IMAP'ed GMail accounts and it does allow oldest
first, turning the process back into the queue it's supposed to be.

Everything that comes in is either GTD-style two minute rule handled
immediately, or gets labeled "Next".

When I get to the Next label, they either get handled, or labeled Someday.

If I ever get to the Somedays, they get handled in further ways.

~~~
projektfu
You can view oldest first by choosing "Show more messages" from the hamburger
above the message list and then clicking the "1-50 of ..." and choosing
"Oldest". Unfortunately it's not apparently able to be made default.

"I thought these guys (google et al) were smarter than this." \-- Google user
Roxane McLean

~~~
zentiggr
True, but that gives a bottoms up workflow, and if you clear a page, it goes
back to the top and you have to navigate down again... at least it used to.
Annoyed me enough to go find a different client.

Being able to sort oldest first means being able to just work on message #1 in
the list until the list is gone. Way less cognitive dissonance.

~~~
projektfu
Yes, it’s dumb

------
antpls
Several thoughts after reading this :

\- it looks like a massive ad for the presented tools (look at all the
"?utm_source=amontalenti" in all the links)

\- if you receive 100s of mail/day, you are doing something wrong. Many of
them are spam or automated notifications. The first step is to unsubscribe to
some of them

\- having 50 rules and google app script is a maintenance hell, it can break
or be deprecated at anytime

\- if you use gmail, gmail's filters and native update/main/priority/spam
boxes does 80% of the job

\- by treating everything as a computer queue, you are trying to behave like a
computer, but you are not one

\- it seems the author spend more time at creating kanban cards and to-do
lists than actually doing the work

\- the point of todo list and kanban is to eventually delegate the work or
share it with coworkers. Any private form of organization of your work makes
it unobservable, unshareable and unreviewable to your teammates

\- if you are an executive/founder, your role is to lead and delegate work. if
you have a manager, you role is to simply listen to the priorities given by
the manager. If you are an independent worker, you will probably focus on one
client at a time

~~~
sixhobbits
This seems unreasonably harsh, especially accusing the Author of spending time
creating to do lists instead of doing work. If you read the rest of Andrew's
blog and look at his github profile, you'll hopefully get a different
impression of him.

To say anyone who gets 100s of emails a day is doing something wrong is
likewise misguided. This is very normal for anyone in an executive role.

~~~
antpls
> This is very normal for anyone in an executive role.

Do you have any study showing a correlation between the success of a company
and the number of emails in the inbox of its executives?

~~~
np_tedious
I'd hazard a guess that zero is very bad

