Discussion Forum > Focus, Flow, and Batch Size
I've been pondering this conflict... I'm beginning to think the root cause of this problem is not so much a direct conflict between focus and flow, but more of a problem with batch sizes.
Let me illustrate the problem using email as an example. When I am triaging my new unread emails, some of them are very quick -- delete, archive, or send a fast response. Done. Others require some more time. I usually flag these and then take care of them after I've finished triaging all the unread ones. And then there are always some emails left over that I am not sure what to do with. Does it need a response, or not? Should I take the time to read through this whole thing, or not?
This seems to break things down into three batches. The first is "triage" - very quickly run through all incoming items and decide what to do, and just take care of items very quickly if you can. The second is "get it done" - handle the slightly larger emails that need a few minutes attention each. The third is the "hmm..." - they get stuck for some reason. They are too large, or at least they seem too large, to get processed right away. Or there is some uncertainty about them. A lot of these are longer things that I'd really like to read -- a colleague's presentation on a topic of interest, or an industry news article, etc. -- but I certainly don't have time for all of them.
In a retail or factory operation, you'd handle these different kinds of work with different kinds of queues. For example, grocery stores have "express lanes" for small orders, and "ordinary lanes" for large orders.
But I am only one person and have only one processing station -- my own hands and eyes and mind. I can't stand ready to work at several different queues all at the same time. So maybe the obvious answer would be to designate different times for each of these different kinds of queues. And that's basically what I do, following the Current Initiative idea from Do It Tomorrow.
1-- Start the day on the most important Large Batch item. Try to spend an hour or two here.
2-- Switch over to processing all the one-off and recurring tasks that must be handled every day.
2a-- If anything in (2) gets stuck, ask myself if maybe it's getting stuck because it's a Large Batch item. If yes, move it into that queue.
2b-- If anything gets stuck because it's a "nice to do" but not a "must do", then I move it to my Friday queue, and allocate a couple hours on Friday just for this kind of stuff.
3-- Finish everything in (2) as quickly as possible. Then I am free -- either go back to tackling my Large Batch items, or just do whatever I want.
There's nothing really new in any of this, but it has been helpful for me to think through it and get a clearer understanding of the dynamics involved. Things really do flow a lot better when things of similar size are queued up together.
I think this addresses some of the issues with systems like AF1, which for many of us tended to devolve into processing lots of trivia. In the end, I think it was a batch-size problem. As soon as I started getting into a fast flow with the smaller items, there would be a tendency to want to keep the fast flow going. As a result, the things that would "stand out" would tend to be the smaller items that fit into the flow better, and the larger items would be neglected.
Maybe an effective way to solve this would simply be to start the day by looking for the large, significant things that must be done -- instruct your mind that those are the things you want to "stand out". Then you'd probably get something like the steps I described above, just arising naturally in the course of the day.
Let me illustrate the problem using email as an example. When I am triaging my new unread emails, some of them are very quick -- delete, archive, or send a fast response. Done. Others require some more time. I usually flag these and then take care of them after I've finished triaging all the unread ones. And then there are always some emails left over that I am not sure what to do with. Does it need a response, or not? Should I take the time to read through this whole thing, or not?
This seems to break things down into three batches. The first is "triage" - very quickly run through all incoming items and decide what to do, and just take care of items very quickly if you can. The second is "get it done" - handle the slightly larger emails that need a few minutes attention each. The third is the "hmm..." - they get stuck for some reason. They are too large, or at least they seem too large, to get processed right away. Or there is some uncertainty about them. A lot of these are longer things that I'd really like to read -- a colleague's presentation on a topic of interest, or an industry news article, etc. -- but I certainly don't have time for all of them.
In a retail or factory operation, you'd handle these different kinds of work with different kinds of queues. For example, grocery stores have "express lanes" for small orders, and "ordinary lanes" for large orders.
But I am only one person and have only one processing station -- my own hands and eyes and mind. I can't stand ready to work at several different queues all at the same time. So maybe the obvious answer would be to designate different times for each of these different kinds of queues. And that's basically what I do, following the Current Initiative idea from Do It Tomorrow.
1-- Start the day on the most important Large Batch item. Try to spend an hour or two here.
2-- Switch over to processing all the one-off and recurring tasks that must be handled every day.
2a-- If anything in (2) gets stuck, ask myself if maybe it's getting stuck because it's a Large Batch item. If yes, move it into that queue.
2b-- If anything gets stuck because it's a "nice to do" but not a "must do", then I move it to my Friday queue, and allocate a couple hours on Friday just for this kind of stuff.
3-- Finish everything in (2) as quickly as possible. Then I am free -- either go back to tackling my Large Batch items, or just do whatever I want.
There's nothing really new in any of this, but it has been helpful for me to think through it and get a clearer understanding of the dynamics involved. Things really do flow a lot better when things of similar size are queued up together.
I think this addresses some of the issues with systems like AF1, which for many of us tended to devolve into processing lots of trivia. In the end, I think it was a batch-size problem. As soon as I started getting into a fast flow with the smaller items, there would be a tendency to want to keep the fast flow going. As a result, the things that would "stand out" would tend to be the smaller items that fit into the flow better, and the larger items would be neglected.
Maybe an effective way to solve this would simply be to start the day by looking for the large, significant things that must be done -- instruct your mind that those are the things you want to "stand out". Then you'd probably get something like the steps I described above, just arising naturally in the course of the day.
May 7, 2020 at 17:18 |
Seraphim
Seraphim
The concurrent "Music Practising" thread is relevant here.
So is my answer: Use FVP with the question "What am I resisting more than x?"
So is my answer: Use FVP with the question "What am I resisting more than x?"
May 7, 2020 at 19:06 |
Mark Forster
Mark Forster
Seraphim:
What do you mean by "batch size?" It seems to me you are referring to the duration it takes to work on a given task? So you have one heap of tasks where you want to work on for longer time per task engagement?
What do you mean by "batch size?" It seems to me you are referring to the duration it takes to work on a given task? So you have one heap of tasks where you want to work on for longer time per task engagement?
May 8, 2020 at 8:44 |
Christopher
Christopher
That's my understanding. I see it the same way. Spend an hour working on one thing, then 10 minutes doing something else, then another hour doing the main thing. But maybe then spend an hour doing lots of somethings elses.
May 8, 2020 at 12:36 |
Alan Baljeu
Alan Baljeu
Seraphim:
<< I think this addresses some of the issues with systems like AF1, which for many of us tended to devolve into processing lots of trivia. In the end, I think it was a batch-size problem. As soon as I started getting into a fast flow with the smaller items, there would be a tendency to want to keep the fast flow going. As a result, the things that would "stand out" would tend to be the smaller items that fit into the flow better, and the larger items would be neglected. >>
In fact this is how AF1 is intended to work. On any individual page, the smaller easier items disappear first. So they are filtered out leaving the larger items to be dealt with on subsequent visits. Once the initial resistance on larger items has been overcome in this way, they can be dealt with "little and often" as part of the flow of smaller items.
<< I think this addresses some of the issues with systems like AF1, which for many of us tended to devolve into processing lots of trivia. In the end, I think it was a batch-size problem. As soon as I started getting into a fast flow with the smaller items, there would be a tendency to want to keep the fast flow going. As a result, the things that would "stand out" would tend to be the smaller items that fit into the flow better, and the larger items would be neglected. >>
In fact this is how AF1 is intended to work. On any individual page, the smaller easier items disappear first. So they are filtered out leaving the larger items to be dealt with on subsequent visits. Once the initial resistance on larger items has been overcome in this way, they can be dealt with "little and often" as part of the flow of smaller items.
May 8, 2020 at 14:44 |
Mark Forster
Mark Forster
Mark Forster -
<< Use FVP with the question "What am I resisting more than x?" >>
I've tried that many times. It can work really well when there are a lot of larger tasks and projects that are stuck for some reason -- it's good to break a logjam like that. But I haven't found it to be sustainable for a general method.
<< Use FVP with the question "What am I resisting more than x?" >>
I've tried that many times. It can work really well when there are a lot of larger tasks and projects that are stuck for some reason -- it's good to break a logjam like that. But I haven't found it to be sustainable for a general method.
May 11, 2020 at 2:20 |
Seraphim
Seraphim
Christopher:
<< What do you mean by "batch size?" >>
Sorry if I wasn't clear. It's a concept I am borrowing from manufacturing. When work flows through a factory, it usually flows in batches, such as a bin of 100 parts. At each workstation, the batch gets worked on till it's completed, before any new work is started.
Sometimes in factories, it can take a lot of setup to get ready to work a batch. This results in a tendency to increase the batch size, so you can make the most efficient use of that setup time, spreading it across a larger number of pieces of work.
But the problem with large batch sizes is that it tends to disrupt flow. A large batch is like a large animal being swallowed by a snake. It takes a long time to digest and work its way through the system.
Reducing batch sizes generally increases the throughput of the whole factory, but this is counter-intuitive because it appears to be less efficient.
<< It seems to me you are referring to the duration it takes to work on a given task? >>
So yes, my use of the term "batch size" is referring to the size of the individual items flowing through my workflow. Larger items tend to stop up the works. Smaller items move through more quickly.
<< So you have one heap of tasks where you want to work on for longer time per task engagement? >>
No, that is not my approach. I prioritize faster flow over more efficient processing. So I would tend to prefer smaller batch sizes.
The problems arise when the items flowing through the system are of greatly varying size. If I am in a good working rhythm, banging through several medium-ish work items, taking 30-60 minutes to complete each one, this can be very productive. While in this state of flow, I would tend to ignore the smaller emails and one-off tasks that are coming in, and save them for later -- these little nit-picky things interrupt the flow. I would also tend to resist any larger things that I need to deal with -- they just take too much attention and force me to switch gears from execution mode to tackle-the-big-initiative mode, which is just a different mindset and doesn't mesh well with cranking out the work. I don't mean I am making conscious decisions to ignore the smaller things and resist the larger things -- I am just describing what seems to typically happen for me.
When I am processing lots of little things -- clearing emails and administrivia, for example -- it's can be difficult to stop and deal with a medium-size task that comes along. It just doesn't mesh with the flow of the little things.
Anyway, I hope that clarifies what I meant.
<< What do you mean by "batch size?" >>
Sorry if I wasn't clear. It's a concept I am borrowing from manufacturing. When work flows through a factory, it usually flows in batches, such as a bin of 100 parts. At each workstation, the batch gets worked on till it's completed, before any new work is started.
Sometimes in factories, it can take a lot of setup to get ready to work a batch. This results in a tendency to increase the batch size, so you can make the most efficient use of that setup time, spreading it across a larger number of pieces of work.
But the problem with large batch sizes is that it tends to disrupt flow. A large batch is like a large animal being swallowed by a snake. It takes a long time to digest and work its way through the system.
Reducing batch sizes generally increases the throughput of the whole factory, but this is counter-intuitive because it appears to be less efficient.
<< It seems to me you are referring to the duration it takes to work on a given task? >>
So yes, my use of the term "batch size" is referring to the size of the individual items flowing through my workflow. Larger items tend to stop up the works. Smaller items move through more quickly.
<< So you have one heap of tasks where you want to work on for longer time per task engagement? >>
No, that is not my approach. I prioritize faster flow over more efficient processing. So I would tend to prefer smaller batch sizes.
The problems arise when the items flowing through the system are of greatly varying size. If I am in a good working rhythm, banging through several medium-ish work items, taking 30-60 minutes to complete each one, this can be very productive. While in this state of flow, I would tend to ignore the smaller emails and one-off tasks that are coming in, and save them for later -- these little nit-picky things interrupt the flow. I would also tend to resist any larger things that I need to deal with -- they just take too much attention and force me to switch gears from execution mode to tackle-the-big-initiative mode, which is just a different mindset and doesn't mesh well with cranking out the work. I don't mean I am making conscious decisions to ignore the smaller things and resist the larger things -- I am just describing what seems to typically happen for me.
When I am processing lots of little things -- clearing emails and administrivia, for example -- it's can be difficult to stop and deal with a medium-size task that comes along. It just doesn't mesh with the flow of the little things.
Anyway, I hope that clarifies what I meant.
May 11, 2020 at 2:24 |
Seraphim
Seraphim
Mark Forster wrote:
<< In fact this is how AF1 is intended to work. On any individual page, the smaller easier items disappear first. So they are filtered out leaving the larger items to be dealt with on subsequent visits. Once the initial resistance on larger items has been overcome in this way, they can be dealt with "little and often" as part of the flow of smaller items. >>
Yes, it does work that way for me sometimes. But when there is a larger number of incoming tasks, it's almost like there is an endless supply of smaller easier tasks. I found that I would tend to gravitate more and more to those tasks, especially as the day became more fractured by meetings and my attention and energy began to wane. So I would try to start the day by trying to find something more impactful to work on, before I lost my focus later in the day. But more and more, it would be harder to find these impactful items before something easier "stood out" and grabbed my attention.
So I think this goes back to the same problem I've had with the long-list systems generally, not being able to cycle through them enough to deal with all existing and incoming items on one undifferentiated list.
<< In fact this is how AF1 is intended to work. On any individual page, the smaller easier items disappear first. So they are filtered out leaving the larger items to be dealt with on subsequent visits. Once the initial resistance on larger items has been overcome in this way, they can be dealt with "little and often" as part of the flow of smaller items. >>
Yes, it does work that way for me sometimes. But when there is a larger number of incoming tasks, it's almost like there is an endless supply of smaller easier tasks. I found that I would tend to gravitate more and more to those tasks, especially as the day became more fractured by meetings and my attention and energy began to wane. So I would try to start the day by trying to find something more impactful to work on, before I lost my focus later in the day. But more and more, it would be harder to find these impactful items before something easier "stood out" and grabbed my attention.
So I think this goes back to the same problem I've had with the long-list systems generally, not being able to cycle through them enough to deal with all existing and incoming items on one undifferentiated list.
May 11, 2020 at 2:31 |
Seraphim
Seraphim
Seraphim:
<< So I think this goes back to the same problem I've had with the long-list systems generally, not being able to cycle through them enough to deal with all existing and incoming items on one undifferentiated list.>>
We've exchanged thoughts often enough about this in the past.
Personally I think the real problem is "No time management system is going to enable someone to get more work done than they have time available to do it."
No amount of juggling big items vs. small items is going to solve that problem for you. As you've discovered, if you concentrate on the big items then the small items get neglected. If you concentrate on the small items then the big items get neglected. If you try to divide your attention equally between them, then half of both get neglected.
I think there a quite a few things you can do about this:
1) Make sure all the meetings you attend are essential. Remember that the purpose of meetings is to generate work. Less meetings, less work and more time to do it in. And that also gives you time to evaluate your work to make sure it is all in fact essential.
2) Take steps to reduce the amount of work you are doing. It's much better to do a few things well than a lot of things badly.
3) Little and often is key. It has the effect of reducing resistance to the large stuff, which reduces the need to have lots of small stuff to avoid the large stuff.
<< So I think this goes back to the same problem I've had with the long-list systems generally, not being able to cycle through them enough to deal with all existing and incoming items on one undifferentiated list.>>
We've exchanged thoughts often enough about this in the past.
Personally I think the real problem is "No time management system is going to enable someone to get more work done than they have time available to do it."
No amount of juggling big items vs. small items is going to solve that problem for you. As you've discovered, if you concentrate on the big items then the small items get neglected. If you concentrate on the small items then the big items get neglected. If you try to divide your attention equally between them, then half of both get neglected.
I think there a quite a few things you can do about this:
1) Make sure all the meetings you attend are essential. Remember that the purpose of meetings is to generate work. Less meetings, less work and more time to do it in. And that also gives you time to evaluate your work to make sure it is all in fact essential.
2) Take steps to reduce the amount of work you are doing. It's much better to do a few things well than a lot of things badly.
3) Little and often is key. It has the effect of reducing resistance to the large stuff, which reduces the need to have lots of small stuff to avoid the large stuff.
May 11, 2020 at 16:46 |
Mark Forster
Mark Forster
Seraphim:
Did you ever think about having a personal Wiki of some sort? I mean a "polished" one, where you can point people to a specific sub page?
One way to work through something and process it internally is to clean up one's notes about it and show it to others. It is not necessary to implement a good idea to show the world what would have been, if said idea was brought to it's full potential.
Do you have a blog? Can you point me to your blog?
Did you ever think about having a personal Wiki of some sort? I mean a "polished" one, where you can point people to a specific sub page?
One way to work through something and process it internally is to clean up one's notes about it and show it to others. It is not necessary to implement a good idea to show the world what would have been, if said idea was brought to it's full potential.
Do you have a blog? Can you point me to your blog?
May 12, 2020 at 6:34 |
Christopher
Christopher
Seraphim, a purely personal note to you!
After being out of software development for over a decade, I have gone back in and am now leading a team of developers, analysts, and testers using a Kanban process (Jira). The other teams all use Scrum, but I pushed for Kanban when our team started, and it is now catching on for other new teams. This has given me an opportunity to explore in practice many of the WIP/TOC/flow ideas we have discussed here. It has been a lot of fun, and it threatens to become more enjoyable than writing code! (which I enjoy a LOT)
I don't have anything topical for this thread at the moment, but I just wanted to bond over that, because if I remember correctly, you also manage some sort of Agile team.
After being out of software development for over a decade, I have gone back in and am now leading a team of developers, analysts, and testers using a Kanban process (Jira). The other teams all use Scrum, but I pushed for Kanban when our team started, and it is now catching on for other new teams. This has given me an opportunity to explore in practice many of the WIP/TOC/flow ideas we have discussed here. It has been a lot of fun, and it threatens to become more enjoyable than writing code! (which I enjoy a LOT)
I don't have anything topical for this thread at the moment, but I just wanted to bond over that, because if I remember correctly, you also manage some sort of Agile team.
May 25, 2020 at 4:03 |
Bernie
Bernie
Seraphim,
To your description,
"For example, sometimes I've focused exclusively on one large task for hours or days at a time -- leaving everything else aside. Sometimes this is necessary because of an emergency or a deadline, but sometimes I find myself making great progress on some important task, and I just want to keep it going as long as I've got the momentum. The problem with such exclusive focus is that everything else stops flowing and creates backlogs -- sometimes generating new emergencies and deadline pressures!"
I am in one of these maelstroms right now in my personal projects!
Not at work, thankfully, where projects are much more related and enough coworkers do not hyperfocus like me.
To your description,
"For example, sometimes I've focused exclusively on one large task for hours or days at a time -- leaving everything else aside. Sometimes this is necessary because of an emergency or a deadline, but sometimes I find myself making great progress on some important task, and I just want to keep it going as long as I've got the momentum. The problem with such exclusive focus is that everything else stops flowing and creates backlogs -- sometimes generating new emergencies and deadline pressures!"
I am in one of these maelstroms right now in my personal projects!
Not at work, thankfully, where projects are much more related and enough coworkers do not hyperfocus like me.
May 25, 2020 at 4:12 |
Bernie
Bernie
Bernie -
Great to hear from you!
<< This has given me an opportunity to explore in practice many of the WIP/TOC/flow ideas we have discussed here. It has been a lot of fun, and it threatens to become more enjoyable than writing code! (which I enjoy a LOT) >>
Yeah I love this stuff. I've always found it makes a huge difference to address the issues around the working model -- probably more of a difference than actual technical things like tech debt, devops best practices, etc. Most tech debt comes from problematic technical practices, but the problematic technical practices are usually an outcome of problematic working models.
Have you ever looked at HyperFlow? It's a combination of variant of Scrum -- more like Kanban actually -- that applies Theory of Contraints to maximize throughput. It is described here - https://www.amazon.com/dp/B00MHYS0T0 One of the best little IT books I've ever read.
Also, have you read any of Clarke Ching's books? Rolling Rocks Downhill is great. https://www.amazon.com/Rolling-Rocks-Downhill-Business-mentions-ebook/dp/B00PJ8HBW8
He's also written the best short summary of TOC and bottleneck management - https://www.amazon.com/gp/product/B07DCFR7B4
<< if I remember correctly, you also manage some sort of Agile team. >>
Yeah, I was a product owner for a long time, and now transitioning into a Release Train Engineer role, which is a SAFe role kind of like an uber scrum master helping to facilitate many teams through a scaled agile process. I am finding I am a better "facilitator" than "owner".
Good to hear from you! :) If you (or anyone else, for that matter) want to connect on LinkedIn, here is my profile. http://www.linkedin.com/in/seraphimlarsen/
Great to hear from you!
<< This has given me an opportunity to explore in practice many of the WIP/TOC/flow ideas we have discussed here. It has been a lot of fun, and it threatens to become more enjoyable than writing code! (which I enjoy a LOT) >>
Yeah I love this stuff. I've always found it makes a huge difference to address the issues around the working model -- probably more of a difference than actual technical things like tech debt, devops best practices, etc. Most tech debt comes from problematic technical practices, but the problematic technical practices are usually an outcome of problematic working models.
Have you ever looked at HyperFlow? It's a combination of variant of Scrum -- more like Kanban actually -- that applies Theory of Contraints to maximize throughput. It is described here - https://www.amazon.com/dp/B00MHYS0T0 One of the best little IT books I've ever read.
Also, have you read any of Clarke Ching's books? Rolling Rocks Downhill is great. https://www.amazon.com/Rolling-Rocks-Downhill-Business-mentions-ebook/dp/B00PJ8HBW8
He's also written the best short summary of TOC and bottleneck management - https://www.amazon.com/gp/product/B07DCFR7B4
<< if I remember correctly, you also manage some sort of Agile team. >>
Yeah, I was a product owner for a long time, and now transitioning into a Release Train Engineer role, which is a SAFe role kind of like an uber scrum master helping to facilitate many teams through a scaled agile process. I am finding I am a better "facilitator" than "owner".
Good to hear from you! :) If you (or anyone else, for that matter) want to connect on LinkedIn, here is my profile. http://www.linkedin.com/in/seraphimlarsen/
June 7, 2020 at 0:44 |
Seraphim
Seraphim
Bernie -
<< I am in one of these maelstroms right now in my personal projects! >>
I recently spent 2-3 months giving Personal Kanban another go -- trying to visualize work and all that. I find the overhead of the stickies and everything to be a bit much (whether paper stickies on whiteboard, or electronic versions like Trello). But it is great as a temporary method to help get a better sense where things have been flowing well, and where they are getting stuck, and just to get a better sense of the overall dynamics of my day.
It helped me to realize that this basic 1-2-3 pattern works really well for me:
(1) Start the day with 1-2 hours of focus work on the most important thing of the day (one of those bigger projects that can suck me in). This is similar to Mark's Current Initiative idea from DIT.
(2) Eventually I either take a break, or a break is forced upon me in the form of meetings or interruptions. Once this happens, I move into task mode. Deal with the meetings and interruptions, and also deal with all the recurring and one-off tasks of the day. I always aim to get this stuff cleared and done in a finite amount of time.
(3) If I am successful in clearing out enough of the items in (2) to feel like I am on top of things, then I consider myself "free" for the rest of the day. Sometimes that means I just go catch up on my reading or something. But usually it means I go back to my big focus task and stay there as long as I want.
This method works really well for me. Once I started falling into this pattern, I realized I didn't need the kanban to visualize the work anymore. It was a lot easier to go back to a paper notebook. I've just been managing all the tasks with a notebook and Simple Scanning. With the 1-2-3 framework described above, creating the overall framework for the day, Simple Scanning has been really effective for me. The 1-2-3 framework helps me clarify the kinds of things I want to "stand out" - it guides me what to scan for.
During the startup phase, first I might write down 1-2 things that might be on my mind, the main things I want to get done, unless I already know where they are on the list. Then I scan for other "big impact" items that are worthy of "Current Initiative" status. After a scan through the list, I usually have confirmed my focus for the day, and get started on that. This first scan also serves to remind me of anything really urgent that must be done that day.
During the interruptions and one-offs phase, I just go through the list as usual, working on whatever stands out. Usually it's the small stuff. That's fine -- that's all I can do during this part of my day when the time is fractured into little pieces.
Once the meetings are all gone (which sometimes doesn't happen, and I never have my "free time"), and the main recurring and one-off items are done for the day, I either pick up again with my focus area, or I will scan the list again, looking for fun or interesting or big things I want to tackle and focus on. Or I just go off-list and don't worry about it. It has been helpful to consider myself "free" during this time -- free to do whatever I want. Usually the thing I want to do is get back on the big focus items.
Anyway, this seems to work great for me. I follow the same pattern whether it's for personal stuff or work. For personal, I just had to make sure I could structure my day so I have a block of time that allows focus work. This has caused me to start the day very early, and it has worked pretty well.
<< I am in one of these maelstroms right now in my personal projects! >>
I recently spent 2-3 months giving Personal Kanban another go -- trying to visualize work and all that. I find the overhead of the stickies and everything to be a bit much (whether paper stickies on whiteboard, or electronic versions like Trello). But it is great as a temporary method to help get a better sense where things have been flowing well, and where they are getting stuck, and just to get a better sense of the overall dynamics of my day.
It helped me to realize that this basic 1-2-3 pattern works really well for me:
(1) Start the day with 1-2 hours of focus work on the most important thing of the day (one of those bigger projects that can suck me in). This is similar to Mark's Current Initiative idea from DIT.
(2) Eventually I either take a break, or a break is forced upon me in the form of meetings or interruptions. Once this happens, I move into task mode. Deal with the meetings and interruptions, and also deal with all the recurring and one-off tasks of the day. I always aim to get this stuff cleared and done in a finite amount of time.
(3) If I am successful in clearing out enough of the items in (2) to feel like I am on top of things, then I consider myself "free" for the rest of the day. Sometimes that means I just go catch up on my reading or something. But usually it means I go back to my big focus task and stay there as long as I want.
This method works really well for me. Once I started falling into this pattern, I realized I didn't need the kanban to visualize the work anymore. It was a lot easier to go back to a paper notebook. I've just been managing all the tasks with a notebook and Simple Scanning. With the 1-2-3 framework described above, creating the overall framework for the day, Simple Scanning has been really effective for me. The 1-2-3 framework helps me clarify the kinds of things I want to "stand out" - it guides me what to scan for.
During the startup phase, first I might write down 1-2 things that might be on my mind, the main things I want to get done, unless I already know where they are on the list. Then I scan for other "big impact" items that are worthy of "Current Initiative" status. After a scan through the list, I usually have confirmed my focus for the day, and get started on that. This first scan also serves to remind me of anything really urgent that must be done that day.
During the interruptions and one-offs phase, I just go through the list as usual, working on whatever stands out. Usually it's the small stuff. That's fine -- that's all I can do during this part of my day when the time is fractured into little pieces.
Once the meetings are all gone (which sometimes doesn't happen, and I never have my "free time"), and the main recurring and one-off items are done for the day, I either pick up again with my focus area, or I will scan the list again, looking for fun or interesting or big things I want to tackle and focus on. Or I just go off-list and don't worry about it. It has been helpful to consider myself "free" during this time -- free to do whatever I want. Usually the thing I want to do is get back on the big focus items.
Anyway, this seems to work great for me. I follow the same pattern whether it's for personal stuff or work. For personal, I just had to make sure I could structure my day so I have a block of time that allows focus work. This has caused me to start the day very early, and it has worked pretty well.
June 7, 2020 at 0:59 |
Seraphim
Seraphim
Christopher -
<< Do you have a blog? Can you point me to your blog? >>
No, but I've sometimes thought of starting something. I've also started putting together an outline for a book. But every time I've done something like that, my own methods and ideas have changed before I could get them down into a blog or book form. LOL
Thanks for asking, though. It makes me feel that my ideas are useful to other people, besides myself, and it's gratifying to hear that. :-)
<< Do you have a blog? Can you point me to your blog? >>
No, but I've sometimes thought of starting something. I've also started putting together an outline for a book. But every time I've done something like that, my own methods and ideas have changed before I could get them down into a blog or book form. LOL
Thanks for asking, though. It makes me feel that my ideas are useful to other people, besides myself, and it's gratifying to hear that. :-)
June 7, 2020 at 1:05 |
Seraphim
Seraphim
Mark,
Thanks as always for your insightful comments!
<< Personally I think the real problem is "No time management system is going to enable someone to get more work done than they have time available to do it." >>
Yes I agree, but the issue I've always had with this statement is the realization that, for me at least, I am never quite sure which of my work really has to be done, and which can be dropped with little or no impact. It's not just a flow of incoming tasks that must be completed. It's more like a lot of opportunities. And the opportunities follow a power law, like the Pareto Principle: 20% of the opportunities represent 80% of the value. Or sometimes it's even more extreme, something like 1% of the opportunities represent 99% of the value. So for me, the question is always about focus. Where is that 1% ?? That's the big question.
And for all the stuff that's **not** in that 1%, the question becomes, which of it can be dropped, and which will cause a problem if I drop it. That stuff also follows a power law. What 20% of the obligatory tasks constitute 80% of the substance of the obligation. These obligatory tasks fall into the category you are describing -- if you don't have enough time to stay on top of these, they will eventually demand all your attention and turn your life into chaos.
<< No amount of juggling big items vs. small items is going to solve that problem for you. >>
Yes of course. But I guess it's more of a question of "high value opportunity work" vs "obligatory work to avoid falling into chaos".
The method I described above, in my post to Bernie, seems to be on a good solution.
<< I think there a quite a few things you can do about this >>
Your advice here is very sensible, but I've always chafed a bit at it, because it just didn't seem to address my situation. The recommendations to reduce meetings and reduce work just seem tangential to my real concerns and obstacles, which is how to get enough focus on the things that will have big impact, vs how to ensure my overall operations are running smoothly and don't fall into chaos. The old conflict between freedom and security, about which I have written extensively elsewhere, such as http://markforster.squarespace.com/forum/post/2745088
Just in case there is any question about it, I am all in favor of reducing meetings -- it's actually a special focus for me at work right now, trying to address this problem for our local teams of developers, since they are also buried in meetings. It generally doesn't work to try to address the meetings head-on, by simply trying to reduce the meetings. The meetings are just a symptom of a need to get alignment or some similar need. There are root causes that generate the meetings. Eliminating or mitigating those root causes is really the only way to reduce the meetings. Otherwise, you can cancel the meetings, but they will pop up in other forms, such as email, IMs, backchannel discussions, etc., which ultimately must be dealt with in meetings again.
The solution seems to be making sure we have alignment of focus and priorities, and enough slack in the system to deal with whatever we aren't able to explicitly align ahead of time.
Thanks as always for your insightful comments!
<< Personally I think the real problem is "No time management system is going to enable someone to get more work done than they have time available to do it." >>
Yes I agree, but the issue I've always had with this statement is the realization that, for me at least, I am never quite sure which of my work really has to be done, and which can be dropped with little or no impact. It's not just a flow of incoming tasks that must be completed. It's more like a lot of opportunities. And the opportunities follow a power law, like the Pareto Principle: 20% of the opportunities represent 80% of the value. Or sometimes it's even more extreme, something like 1% of the opportunities represent 99% of the value. So for me, the question is always about focus. Where is that 1% ?? That's the big question.
And for all the stuff that's **not** in that 1%, the question becomes, which of it can be dropped, and which will cause a problem if I drop it. That stuff also follows a power law. What 20% of the obligatory tasks constitute 80% of the substance of the obligation. These obligatory tasks fall into the category you are describing -- if you don't have enough time to stay on top of these, they will eventually demand all your attention and turn your life into chaos.
<< No amount of juggling big items vs. small items is going to solve that problem for you. >>
Yes of course. But I guess it's more of a question of "high value opportunity work" vs "obligatory work to avoid falling into chaos".
The method I described above, in my post to Bernie, seems to be on a good solution.
<< I think there a quite a few things you can do about this >>
Your advice here is very sensible, but I've always chafed a bit at it, because it just didn't seem to address my situation. The recommendations to reduce meetings and reduce work just seem tangential to my real concerns and obstacles, which is how to get enough focus on the things that will have big impact, vs how to ensure my overall operations are running smoothly and don't fall into chaos. The old conflict between freedom and security, about which I have written extensively elsewhere, such as http://markforster.squarespace.com/forum/post/2745088
Just in case there is any question about it, I am all in favor of reducing meetings -- it's actually a special focus for me at work right now, trying to address this problem for our local teams of developers, since they are also buried in meetings. It generally doesn't work to try to address the meetings head-on, by simply trying to reduce the meetings. The meetings are just a symptom of a need to get alignment or some similar need. There are root causes that generate the meetings. Eliminating or mitigating those root causes is really the only way to reduce the meetings. Otherwise, you can cancel the meetings, but they will pop up in other forms, such as email, IMs, backchannel discussions, etc., which ultimately must be dealt with in meetings again.
The solution seems to be making sure we have alignment of focus and priorities, and enough slack in the system to deal with whatever we aren't able to explicitly align ahead of time.
June 7, 2020 at 1:27 |
Seraphim
Seraphim
Seraphim:
I have trouble advising you in all this because I find it difficult to visualise your work. But if I try to relate it to my own experience, there was a time when I was running multiple teams each working on different projects with a lead time of about six months per project and each coming into effect about a week after the previous one.
I learnt very quickly to apply the following principles:
1) Aim to do the work as well as it could possibly be done. I don't know whether I succeeded in that to the the letter, but I certainly succeeded in doing it better than anyone else in England at the time.
2) Have a well-defined limit to the number of projects under way. This was actually a very high limit, but I kept to it religiously.
3) Routinize as much of the work as possible. That involved everything from standard working practices to making sure all meetings had a definite aim appropriate to the stage of the project. These meetings followed a defined progression.
4) Get everything scheduled as early as possible.
5) Constantly monitor progress, which basically meant keeping a close eye on the figures, and ensuring that the individual team leaders were on the ball. There was a definite finishing date with no slippage possible.
Basically all my work on the twenty plus projects going at any one time followed a clear schedule with set routines. That meant that I knew exactly what I needed to be doing at any particular stage, and I knew it was within my capabilities. Any project that failed to go forward was scrapped and the space was freed up for another candidate.
I have trouble advising you in all this because I find it difficult to visualise your work. But if I try to relate it to my own experience, there was a time when I was running multiple teams each working on different projects with a lead time of about six months per project and each coming into effect about a week after the previous one.
I learnt very quickly to apply the following principles:
1) Aim to do the work as well as it could possibly be done. I don't know whether I succeeded in that to the the letter, but I certainly succeeded in doing it better than anyone else in England at the time.
2) Have a well-defined limit to the number of projects under way. This was actually a very high limit, but I kept to it religiously.
3) Routinize as much of the work as possible. That involved everything from standard working practices to making sure all meetings had a definite aim appropriate to the stage of the project. These meetings followed a defined progression.
4) Get everything scheduled as early as possible.
5) Constantly monitor progress, which basically meant keeping a close eye on the figures, and ensuring that the individual team leaders were on the ball. There was a definite finishing date with no slippage possible.
Basically all my work on the twenty plus projects going at any one time followed a clear schedule with set routines. That meant that I knew exactly what I needed to be doing at any particular stage, and I knew it was within my capabilities. Any project that failed to go forward was scrapped and the space was freed up for another candidate.
June 7, 2020 at 18:17 |
Mark Forster
Mark Forster
Thanks Mark. I am always fascinated when you share more details like this of what your work was like during various periods of your career. If you would ever write an autobiography, I'd buy several copies. :)
I like the meeting practices you describe here. It is a learned skill. I can't believe how many meetings I am invited to, where there is no agenda, no stated purpose, no explanation of why I am invited, no context or background at all; etc. I decline as many of those meetings as I can get away with, but some of them must be attended. There can be a 5-minute discussion during that meeting in which it is important for me to participate. But I never know which 5 minutes, or whether it will happen in today's meeting, or next week. That kind of meeting is a huge drain on me, mentally. I push back on those as much as possible, but like I said, sometimes they can't be avoided.
For my own meetings that I organize, I always state the purpose clearly, what we need to get out of the meeting, what the proposed agenda is, who is needed in the meeting, who needs to make sure they are covered if they can't attend personally, who is optional/FYI only, etc. And then when we've finished covering the agenda items, end the meeting! And try to write all that up very briefly in the meeting invitation, so people can actually read it quickly and decide whether to attend, whether to send someone else, or whether they can just read the minutes.
Minutes! There must always be minutes, or at least the action items, decisions, and next steps must be captured clearly and distributed to everyone. When I am in a meeting where these things are not being done, I just drop. What's the point. Totally useless meeting. If it's important, and I can't drop, then I just start taking minutes myself and send it to the meeting organizer. The problem with that is that next time they ask if I will take the minutes. :( No good deed goes unpunished!
A clarifying question -- Were the projects you are describing "company-authorized" projects -- formally defined as projects by the organization at some level? Are was it a collection of work that you yourself identified as a "project"? Or a mixture of both? Just trying to get a better idea of how you are using the word.
Thanks!!
I like the meeting practices you describe here. It is a learned skill. I can't believe how many meetings I am invited to, where there is no agenda, no stated purpose, no explanation of why I am invited, no context or background at all; etc. I decline as many of those meetings as I can get away with, but some of them must be attended. There can be a 5-minute discussion during that meeting in which it is important for me to participate. But I never know which 5 minutes, or whether it will happen in today's meeting, or next week. That kind of meeting is a huge drain on me, mentally. I push back on those as much as possible, but like I said, sometimes they can't be avoided.
For my own meetings that I organize, I always state the purpose clearly, what we need to get out of the meeting, what the proposed agenda is, who is needed in the meeting, who needs to make sure they are covered if they can't attend personally, who is optional/FYI only, etc. And then when we've finished covering the agenda items, end the meeting! And try to write all that up very briefly in the meeting invitation, so people can actually read it quickly and decide whether to attend, whether to send someone else, or whether they can just read the minutes.
Minutes! There must always be minutes, or at least the action items, decisions, and next steps must be captured clearly and distributed to everyone. When I am in a meeting where these things are not being done, I just drop. What's the point. Totally useless meeting. If it's important, and I can't drop, then I just start taking minutes myself and send it to the meeting organizer. The problem with that is that next time they ask if I will take the minutes. :( No good deed goes unpunished!
A clarifying question -- Were the projects you are describing "company-authorized" projects -- formally defined as projects by the organization at some level? Are was it a collection of work that you yourself identified as a "project"? Or a mixture of both? Just trying to get a better idea of how you are using the word.
Thanks!!
June 7, 2020 at 19:24 |
Seraphim
Seraphim
Seraphim:
<< If you would ever write an autobiography, I'd buy several copies. :) >>
Not likely in the foreseeable future!
<< I can't believe how many meetings I am invited to, where there is no agenda, no stated purpose, no explanation of why I am invited, no context or background at all; etc. >>
Yes, I had meetings like that as well. The meetings I've described are the ones I was in control of. Fortunately there weren't too many of the others but they were still an annoying distraction from the real work.
I once, for reasons I can't remember, went on a course about doing business with the Japanese. It was actually quite interesting though the only thing I can remember about it was that the Japanese have stereotypes about national attitudes to business. Their stereotype for the British was that we spend all our time holding meetings and the only decision we ever come to is the date of the next meeting!
My solution for meetings without minutes was to send an email giving a summary of the decisions which affected me personally and asking them to agree that I'd got it right. Since it was usually very short, it didn't amount to an opening for taking the minutes next time,
Also for meetings generally, I found that saying I needed to leave early because of some other commitment meant that all the items which affected me got brought forward on the agenda. I also found it had the unintended result of making everyone think how busy and important I was!
<< Minutes! There must always be minutes, or at least the action items, decisions, and next steps must be captured clearly and distributed to everyone. >>
The shorter the minutes the more effective they are. Because if they are long:
a. they will get shunted to one side to look at later and we all know what happens then!
b. it will be easy to miss the essential action items amidst the general waffle.
Minutes should not be regarded as an historical record of what happened, but as an instruction, i.e. decisions, dates, actions, and follow-up requirements. If there's a legal requirement to write detailed minutes, then send out the action points separately and immediately and follow up with the record of discussion (which no one will read).
If you don't know why you are at a meeting, you shouldn't be at it.
<< Were the projects you are describing "company-authorized" projects -- formally defined as projects by the organization at some level? >>
Yes, though the scope and nature of each project was up to me, which is why I could run them more or less as an assembly line.
<< If you would ever write an autobiography, I'd buy several copies. :) >>
Not likely in the foreseeable future!
<< I can't believe how many meetings I am invited to, where there is no agenda, no stated purpose, no explanation of why I am invited, no context or background at all; etc. >>
Yes, I had meetings like that as well. The meetings I've described are the ones I was in control of. Fortunately there weren't too many of the others but they were still an annoying distraction from the real work.
I once, for reasons I can't remember, went on a course about doing business with the Japanese. It was actually quite interesting though the only thing I can remember about it was that the Japanese have stereotypes about national attitudes to business. Their stereotype for the British was that we spend all our time holding meetings and the only decision we ever come to is the date of the next meeting!
My solution for meetings without minutes was to send an email giving a summary of the decisions which affected me personally and asking them to agree that I'd got it right. Since it was usually very short, it didn't amount to an opening for taking the minutes next time,
Also for meetings generally, I found that saying I needed to leave early because of some other commitment meant that all the items which affected me got brought forward on the agenda. I also found it had the unintended result of making everyone think how busy and important I was!
<< Minutes! There must always be minutes, or at least the action items, decisions, and next steps must be captured clearly and distributed to everyone. >>
The shorter the minutes the more effective they are. Because if they are long:
a. they will get shunted to one side to look at later and we all know what happens then!
b. it will be easy to miss the essential action items amidst the general waffle.
Minutes should not be regarded as an historical record of what happened, but as an instruction, i.e. decisions, dates, actions, and follow-up requirements. If there's a legal requirement to write detailed minutes, then send out the action points separately and immediately and follow up with the record of discussion (which no one will read).
If you don't know why you are at a meeting, you shouldn't be at it.
<< Were the projects you are describing "company-authorized" projects -- formally defined as projects by the organization at some level? >>
Yes, though the scope and nature of each project was up to me, which is why I could run them more or less as an assembly line.
June 8, 2020 at 14:40 |
Mark Forster
Mark Forster
As someone who can't attend many of the meetings I want to, and have to deal with the grumbles of people who weren't at a meeting (with good reason) and don't think we thought something through adequately before deciding, minutes, (or meeting summary) have additional purposes.
They connect those of us who can't make it to our colleagues. Technically, someone's unsuccessful application for a grant, or recent life events, or the text of the invocation, don't need to be in the minutes, but they help me feel connected.
They reassure people who couldn't be at the meeting that all points were discussed. Do we want to have a table at the fall fair again? That would require 8 members to do a 4-Hour shift each. Last year, 3 members did triple shifts because, when it came down to it, everyone else was busy. Also, in the last 3 years we have not had any new members from seeing us there.
They also let us know what we need to think about. The discussion and ordering shirts was tabled due to lack of artistic ability. Decision must be made next meeting. That gives me a month to ask my artistic friends about their rates and availability.
There's a balance.
I'm usually the one who takes the minutes, and learned the hard way to always get names. One person would commit the group to tons of work, then disappear. I'm also the one who separates Support in principle from Support with time or money. Another time we agreed to support a member with a related project, but no one showed up. She would have made different plans if we had clarified.
They connect those of us who can't make it to our colleagues. Technically, someone's unsuccessful application for a grant, or recent life events, or the text of the invocation, don't need to be in the minutes, but they help me feel connected.
They reassure people who couldn't be at the meeting that all points were discussed. Do we want to have a table at the fall fair again? That would require 8 members to do a 4-Hour shift each. Last year, 3 members did triple shifts because, when it came down to it, everyone else was busy. Also, in the last 3 years we have not had any new members from seeing us there.
They also let us know what we need to think about. The discussion and ordering shirts was tabled due to lack of artistic ability. Decision must be made next meeting. That gives me a month to ask my artistic friends about their rates and availability.
There's a balance.
I'm usually the one who takes the minutes, and learned the hard way to always get names. One person would commit the group to tons of work, then disappear. I'm also the one who separates Support in principle from Support with time or money. Another time we agreed to support a member with a related project, but no one showed up. She would have made different plans if we had clarified.
August 26, 2020 at 18:16 |
Cricket
Cricket
Hi Mark,
In your June 7th post, you remarked that you "Routinize as much of the work as possible. That involved everything from standard working practices to making sure all meetings had a definite aim appropriate to the stage of the project. These meetings followed a defined progression."
I find that interesting...in my work meetings, I do not normally see pre-defined meetings following some progression as you laid out, but rather a "let's figure it out as we go" approach.
How far in advance of your meetings did you know what agenda would be discussed? Did you lay out the project schedule and the meetings with mostly pre-defined agendas right from the beginning of the project? ie How much of the project did you plan/figure out right from the outset?
In your June 7th post, you remarked that you "Routinize as much of the work as possible. That involved everything from standard working practices to making sure all meetings had a definite aim appropriate to the stage of the project. These meetings followed a defined progression."
I find that interesting...in my work meetings, I do not normally see pre-defined meetings following some progression as you laid out, but rather a "let's figure it out as we go" approach.
How far in advance of your meetings did you know what agenda would be discussed? Did you lay out the project schedule and the meetings with mostly pre-defined agendas right from the beginning of the project? ie How much of the project did you plan/figure out right from the outset?
September 2, 2020 at 14:18 |
Paul B from Canada
Paul B from Canada
Paul B:
In my case, I was dealing with fund raising projects. However unique each client regards its individual situation, the fact is that all fund raising projects follow (or should follow) a similar sequence.
This is true of many types of project, e.g. producing a monthly magazine, event organising, military operations, building a motorway, opening a new branch, running training courses, and so on.
"Figuring things out as you go" would be a disaster in any of these scenarios. Keeping to a pre-defined sequence means that you draw on previous experience, can adapt quickly to new factors, and can work with different teams or team members without having to start again from square one.
In my particular situation, I would book all the meetings in one go for each project with a clearly defined purpose for each meeting. The agendas would follow a standard format for each stage, and I would have a standard plan for all projects which would be adapted for individual circumstances.
Before applying what I'm saying to your work, you might as an exercise consider where your local response to the COVID-19 crisis falls on the "Making it up as you go along" / "Following a pre-defined sequence" continuum.
In my case, I was dealing with fund raising projects. However unique each client regards its individual situation, the fact is that all fund raising projects follow (or should follow) a similar sequence.
This is true of many types of project, e.g. producing a monthly magazine, event organising, military operations, building a motorway, opening a new branch, running training courses, and so on.
"Figuring things out as you go" would be a disaster in any of these scenarios. Keeping to a pre-defined sequence means that you draw on previous experience, can adapt quickly to new factors, and can work with different teams or team members without having to start again from square one.
In my particular situation, I would book all the meetings in one go for each project with a clearly defined purpose for each meeting. The agendas would follow a standard format for each stage, and I would have a standard plan for all projects which would be adapted for individual circumstances.
Before applying what I'm saying to your work, you might as an exercise consider where your local response to the COVID-19 crisis falls on the "Making it up as you go along" / "Following a pre-defined sequence" continuum.
September 2, 2020 at 16:44 |
Mark Forster
Mark Forster
Further to my last post, here is an example of a pre-defined sequence. "How to write a blog post every day". As you will realise, I don't still use this, but it used to work very effectively.
Each day do the following:
1. Add to your list of possible future subjects for posts
2. Select one subject off the list and write a first draft
3. Write a second draft of the post you wrote the first draft of yesterday
4. Write a final draft of the post you wrote the second draft of yesterday.
5. Publish the post you wrote the final draft of yesterday
Each day do the following:
1. Add to your list of possible future subjects for posts
2. Select one subject off the list and write a first draft
3. Write a second draft of the post you wrote the first draft of yesterday
4. Write a final draft of the post you wrote the second draft of yesterday.
5. Publish the post you wrote the final draft of yesterday
September 2, 2020 at 17:12 |
Mark Forster
Mark Forster
Cricket:
<< As someone who can't attend many of the meetings I want to, and have to deal with the grumbles of people who weren't at a meeting (with good reason) and don't think we thought something through adequately before deciding, minutes, (or meeting summary) have additional purposes. >>
Well, OK. But I suspect that what most people do when they receive the minutes is skim past the unsuccessful grant applications, life events, invocations, discussions, etc and zero in on the decisions, dates, actions, and follow-up requirements to see what is directly relevant to them.
Or perhaps it's just me who does that.
<< As someone who can't attend many of the meetings I want to, and have to deal with the grumbles of people who weren't at a meeting (with good reason) and don't think we thought something through adequately before deciding, minutes, (or meeting summary) have additional purposes. >>
Well, OK. But I suspect that what most people do when they receive the minutes is skim past the unsuccessful grant applications, life events, invocations, discussions, etc and zero in on the decisions, dates, actions, and follow-up requirements to see what is directly relevant to them.
Or perhaps it's just me who does that.
September 2, 2020 at 17:34 |
Mark Forster
Mark Forster
Thank you for your insightful reply, Mark. Planning is an area that I need to improve. I interpreted Little and Often as an approach that does not require or benefit greatly from planning and structure. Similarly, David Allen's GTD approach of focusing on the Next Step also led me to believe that Planning was over-rated. But, to my surprise, your note advocates a fairly structured approach....pre-define the steps and milestones as much as possible and as early as possible - and then schedule updates and follow up with people along the path to ensure the milestones are met.....this is a lot different than just focusing on Little and Often. So, I take from this that there is a strategic level in which Planning is vital...and this is far different than the more tactical level to work through a long list of projects/tasks. The tactical level does not preclude the strategic and methodical plan. I have a long way to improve in this, but perhaps this will take me to the next level and is the missing link to my personal effectiveness. Maybe this should have been obvious, but I am a slow learner in many respects and I did find success in the tactical approach....just not enough success. Thanks again for your reply. I greatly value your thoughts.
September 3, 2020 at 12:48 |
Paul B from Canada
Paul B from Canada
Flow - Just because we've decided where to focus doesn't mean the work gets done by itself. We need to organize the flow of work for fast throughput. Throughput is less about efficient use of resources, and more about fast flow of the work items from "undone" to "done". The question is, how do we improve the flow and increase the throughput?
Focus and flow seem complementary in some ways, and in conflict in other ways.
For example, focusing on a smaller number of simultaneous tasks increases flow. Too many simultaneous tasks creates task-switching traffic jams, interruptions, setup issues, etc. Maybe even more importantly, unfinished tasks don't deliver value, and holding multiple tasks in WIP means the value delivery for all of them is delayed. Focusing on a few tasks means we get them done sooner, and realize the value sooner.
Going the other direction, flow can also increase focus. If you have fast flow, and complete tasks quickly, this gives you valuable feedback that can help you decide where to focus next.
But sometimes focus and flow seem to be in conflict with each other. For example, sometimes I've focused exclusively on one large task for hours or days at a time -- leaving everything else aside. Sometimes this is necessary because of an emergency or a deadline, but sometimes I find myself making great progress on some important task, and I just want to keep it going as long as I've got the momentum. The problem with such exclusive focus is that everything else stops flowing and creates backlogs -- sometimes generating new emergencies and deadline pressures!