How do you deal with mental switching between projects/clients/areas?
17 comments
As an Army Reservist who has deployed 5 times I have had to make the mental switch, though this is more like extreme switching on/off your entire life. Here is my limited coping strategy as it relates only to minor task delegation:
* Keep good notes. Be better prepared to jump back into a different task by knowing exactly where you left off, problem state, and what the next step is.
* Anticipate the switch and plan your day/time to accommodate change. The switch to a different task is the easy part. It is building the necessary focus a given task requires that is hard. Know that and plan accordingly so that stress and interference are lower.
* when it comes to automating this stress away embrace the stress state directly and make notes about it. Use those notes to identify repeated problems and delays. Solve not for the stress but for the repetition.
* I cannot provide guidance for dealing with the emotion or mental stress directly as my situation is a bit more extreme.
* Keep good notes. Be better prepared to jump back into a different task by knowing exactly where you left off, problem state, and what the next step is.
* Anticipate the switch and plan your day/time to accommodate change. The switch to a different task is the easy part. It is building the necessary focus a given task requires that is hard. Know that and plan accordingly so that stress and interference are lower.
* when it comes to automating this stress away embrace the stress state directly and make notes about it. Use those notes to identify repeated problems and delays. Solve not for the stress but for the repetition.
* I cannot provide guidance for dealing with the emotion or mental stress directly as my situation is a bit more extreme.
> Keep good notes. Be better prepared to jump back into a different task by knowing exactly where you left off, problem state, and what the next step is.
To expand on this (and point 3), there's some non-obvious (to many) types of notes that can help you switch:
* Sql snippets to display/manipulate the data.
* Log snippets with relevant stack traces.
* Debugger breakpoints and core dumps (if applicable), can be scripted on the command line or imported/exported from the IDE. Don't forget debuggers are scriptable too, most devs use a fraction of a debuggers power.
* Custom scripts, like something that can grep logs for the specific issue you're working on, toggle config settings, setup data in a specific way, etc.
These can help you immediately jump back to the problem rather than jumping to the project and then working your way back to the problem. They don't always help, but more often you'll be able to switch in 5 minutes rather than 4 hours. They will also help with notes to QA and support along with documentation.
To expand on this (and point 3), there's some non-obvious (to many) types of notes that can help you switch:
* Sql snippets to display/manipulate the data.
* Log snippets with relevant stack traces.
* Debugger breakpoints and core dumps (if applicable), can be scripted on the command line or imported/exported from the IDE. Don't forget debuggers are scriptable too, most devs use a fraction of a debuggers power.
* Custom scripts, like something that can grep logs for the specific issue you're working on, toggle config settings, setup data in a specific way, etc.
These can help you immediately jump back to the problem rather than jumping to the project and then working your way back to the problem. They don't always help, but more often you'll be able to switch in 5 minutes rather than 4 hours. They will also help with notes to QA and support along with documentation.
> As an Army Reservist who has deployed 5 times I have had to make the mental switch, though this is more like extreme switching on/off your entire life.
This must be very tough, thanks for sharing.
> * Keep good notes. Be better prepared to jump back into a different task by knowing exactly where you left off, problem state, and what the next step is.
A special, limited case of this is ending your workday. While you're in the zone, and wrapping up your day set yourself up for success by preplanning your next action. If you're coding something and just committed your day's last checkin, write a quick sentence indicating what you're going to be working on tomorrow. When I am able to do this, regaining context next day is much simpler and easier for me.
This must be very tough, thanks for sharing.
> * Keep good notes. Be better prepared to jump back into a different task by knowing exactly where you left off, problem state, and what the next step is.
A special, limited case of this is ending your workday. While you're in the zone, and wrapping up your day set yourself up for success by preplanning your next action. If you're coding something and just committed your day's last checkin, write a quick sentence indicating what you're going to be working on tomorrow. When I am able to do this, regaining context next day is much simpler and easier for me.
>As an Army Reservist who has deployed 5 times I have had to make the mental switch, though this is more like extreme switching on/off your entire life. Here is my limited coping strategy as it relates only to minor task delegation
Thanks for sharing, I hope they didn't take a tool on you.
> It is building the necessary focus a given task requires that is hard.
Would love if you could explain further this.
> I cannot provide guidance for dealing with the emotion or mental stress directly as my situation is a bit more extreme
Shit man, I imagine it must not be easy.
Thanks for sharing, I hope they didn't take a tool on you.
> It is building the necessary focus a given task requires that is hard.
Would love if you could explain further this.
> I cannot provide guidance for dealing with the emotion or mental stress directly as my situation is a bit more extreme
Shit man, I imagine it must not be easy.
Context switching is an overhead that seems easier to live with than fight. Try less context switches in a day, rather than optimising the time between switching.
Taking on too many concurrent projects inevitably leads to burn out...
Taking on too many concurrent projects inevitably leads to burn out...
Context switching is a beast that demands respect for sure but sometimes you can't plan fewer switches.
>Taking on too many concurrent projects inevitably leads to burn out...
100%
Ps. It seems that the penalty increases as we grow older.
>Taking on too many concurrent projects inevitably leads to burn out...
100%
Ps. It seems that the penalty increases as we grow older.
What's the outcome of this all?
I'll talk about doing that in the context of a crisis and change the underlying problems of being on too many projects without a rewarding outcome.
Analyse everything. Figure out patterns. Remove friction. Track everything. Document everything. Disseminate information to everyone. Do post mortems. Fix underlying problems upstream. Don't mop the floor, fix the leak in the pipe.
We're a boutique machine learning consultancy. At one point, we had about ten projects. This has caused the CTO and co-founder to quit. A colleague and I stepped in to take over because we had meetings lined up. We had to go over everything for the projects. Emails, bottlenecks, blocking points, contracts, payments, invoices, legal. We were only on the technical side.
We scrambled to ensure continuity. I had to learn a lot of things and I documented everything. By everything, I mean how to write a cheque to pay taxes, where to write the amount, a picture of the cheque, where to take the form (GPS coordinates, picture of the building, floor, description to get to the right clerk). The first thing I did was to write an "Operator's Manual", so anyone can operate the business if I were to disappear. I took the most I could take of this process to enable my colleague to focus on the machine learning side because that made sense from a comparative advantage standpoint.
We examined all the things that were working and were not working and figured out why. For example, we did post mortems on all the people who quit or whom we let go and classified them into categories of "went well", "went poorly". We found that one of the issues was information asymmetry, and did everything to reduce that asymmetry to the minimum. I took notes for every meeting we took for every project, came up with a Markdown template (see below), and made sure everyone knew what was going on in meetings they didn't attend. We set out to maximize information dissemination so people can get the full picture. We found out we were going over the same thing with new hires, and we wrote onboarding documentation to make it as smooth as possible, preparing their access rights, their machines, and making them successful on week one.
We systematically examined every aspect of everything we were doing, and we set to remove friction to getting things done.
I had a Markdown file with every project, who was on it, what its status was, what were the next actions, what was blocking, etc. Every day, we went through it sequentially. Talking with everyone on the team. Then had an alias for my todos, showed it to my colleague to track things which he adopted, then he found TaskWarrior and showed it to me, which I adopted. Tags, projects, due dates, etc. I push the files to a repo and have a script to export to Markdown to push pending tasks to a repository accessible by everyone.
That formed the basis of our knowledge base.
We shut down zombie projects. I didn't hesitate to pull the plug on a project I was the main contributor on for almost two years that was going nowhere.
We examined every relation with every prospect and every client, and figured out patterns of projects that went well and projects that didn't go well. We made decisions based on that not to pursue relations with certain prospects that didn't fit a certain profile and changed the way we do business to detect red flags early on. For example, many of the prospects we talked with had a point of contact who had no decision power. We stopped doing that. Many prospects did not want to give us access to domain experts and only wanted their executives to be involved. We stopped doing that. Many prospects wanted us to do machine learning but did not provide with people who handled data, or did not want to talk about their problems with data. We stopped doing that. We mitigated that upstream by putting that on the table early on: get people with decision power to the table, get domain experts to the table, get the end users to the table, get the stakeholders to the table. We started explaining why it was necessary to do that, and we had a much, much, higher survival rate and conversion.
Then we looked at all the machine learning projects we have been doing, figured out the patterns and the problems that made them so slow and expensive, and we set out to build our machine learning platform to solve these problems.[0]
So, we're talking with fewer clients and working on fewer projects, delivering value with fewer people, and the outcome is much, much better. Higher survival rate.
- [1]: https://news.ycombinator.com/item?id=25244246
I'll talk about doing that in the context of a crisis and change the underlying problems of being on too many projects without a rewarding outcome.
Analyse everything. Figure out patterns. Remove friction. Track everything. Document everything. Disseminate information to everyone. Do post mortems. Fix underlying problems upstream. Don't mop the floor, fix the leak in the pipe.
We're a boutique machine learning consultancy. At one point, we had about ten projects. This has caused the CTO and co-founder to quit. A colleague and I stepped in to take over because we had meetings lined up. We had to go over everything for the projects. Emails, bottlenecks, blocking points, contracts, payments, invoices, legal. We were only on the technical side.
We scrambled to ensure continuity. I had to learn a lot of things and I documented everything. By everything, I mean how to write a cheque to pay taxes, where to write the amount, a picture of the cheque, where to take the form (GPS coordinates, picture of the building, floor, description to get to the right clerk). The first thing I did was to write an "Operator's Manual", so anyone can operate the business if I were to disappear. I took the most I could take of this process to enable my colleague to focus on the machine learning side because that made sense from a comparative advantage standpoint.
We examined all the things that were working and were not working and figured out why. For example, we did post mortems on all the people who quit or whom we let go and classified them into categories of "went well", "went poorly". We found that one of the issues was information asymmetry, and did everything to reduce that asymmetry to the minimum. I took notes for every meeting we took for every project, came up with a Markdown template (see below), and made sure everyone knew what was going on in meetings they didn't attend. We set out to maximize information dissemination so people can get the full picture. We found out we were going over the same thing with new hires, and we wrote onboarding documentation to make it as smooth as possible, preparing their access rights, their machines, and making them successful on week one.
We systematically examined every aspect of everything we were doing, and we set to remove friction to getting things done.
I had a Markdown file with every project, who was on it, what its status was, what were the next actions, what was blocking, etc. Every day, we went through it sequentially. Talking with everyone on the team. Then had an alias for my todos, showed it to my colleague to track things which he adopted, then he found TaskWarrior and showed it to me, which I adopted. Tags, projects, due dates, etc. I push the files to a repo and have a script to export to Markdown to push pending tasks to a repository accessible by everyone.
That formed the basis of our knowledge base.
We shut down zombie projects. I didn't hesitate to pull the plug on a project I was the main contributor on for almost two years that was going nowhere.
We examined every relation with every prospect and every client, and figured out patterns of projects that went well and projects that didn't go well. We made decisions based on that not to pursue relations with certain prospects that didn't fit a certain profile and changed the way we do business to detect red flags early on. For example, many of the prospects we talked with had a point of contact who had no decision power. We stopped doing that. Many prospects did not want to give us access to domain experts and only wanted their executives to be involved. We stopped doing that. Many prospects wanted us to do machine learning but did not provide with people who handled data, or did not want to talk about their problems with data. We stopped doing that. We mitigated that upstream by putting that on the table early on: get people with decision power to the table, get domain experts to the table, get the end users to the table, get the stakeholders to the table. We started explaining why it was necessary to do that, and we had a much, much, higher survival rate and conversion.
Then we looked at all the machine learning projects we have been doing, figured out the patterns and the problems that made them so slow and expensive, and we set out to build our machine learning platform to solve these problems.[0]
So, we're talking with fewer clients and working on fewer projects, delivering value with fewer people, and the outcome is much, much better. Higher survival rate.
# Minutes of Meeting
--------------------
## Date: 2019-03-25
## Place: BIGCorp HQ. City, State.
## Participants:
### BIGCorp:
- John Doe (jd)
- MeMyself I (mmi)
### OtherCorp:
- Dilbert ([email protected])
- Dogbert ([email protected])
## Topics:
- Scheduled information sending
- Information flow
- Architecture for Project X
## Details:
OtherCorp has raised some issues for the timeline of Project X...
Blah blah blah.
## Actions:
### BIGCorp:
- [ ] @bc: Send project X estimates by 2019-03-28
- [x] @bc: Send invoice and cheque for offices remodeling
- [ ] @mmi: Add different schemes for user authentication
- [ ] @mmi: Finalize migrations so we take into account user's timezone
### OtherCorp:
- [ ] @oc: Expose API end points for user's identity verification
- [ ] @oc: Cache the results of the most common queries
- [1]: https://news.ycombinator.com/item?id=25244246
First of all: Thank you for your reply - very thoughtful, I double down on removing as much friction as possible - optimizing and making processes crystal clear.
Read also your other threads and all had great value.
To answer your inital question: The outcome is a context switch mitigator How? 1. connect triggers - Audio and/or Visual (see research papers bellow) to a context - leveraging the natural event segmentation where our brain uses environmental triggers to automatically prepare information that we might need - common real life example the "doorway effect" 2. Connect that trigger to a workspace (reduce the amount of distractions from trigger to effective work) that tracks your productivity ( no exact formula yet - was thinking about app category, apm, usage time and focus switches)
I hope that will help me and maybe others 1. load memories about the context they are starting and dump info about old context as in the doorway effect. 2. provide less distractions and enough data to reflect on the process.
Currently have a very rough MacOS demo - hoping to get it to a shareable version in 4months.
Read also your other threads and all had great value.
To answer your inital question: The outcome is a context switch mitigator How? 1. connect triggers - Audio and/or Visual (see research papers bellow) to a context - leveraging the natural event segmentation where our brain uses environmental triggers to automatically prepare information that we might need - common real life example the "doorway effect" 2. Connect that trigger to a workspace (reduce the amount of distractions from trigger to effective work) that tracks your productivity ( no exact formula yet - was thinking about app category, apm, usage time and focus switches)
I hope that will help me and maybe others 1. load memories about the context they are starting and dump info about old context as in the doorway effect. 2. provide less distractions and enough data to reflect on the process.
Currently have a very rough MacOS demo - hoping to get it to a shareable version in 4months.
I find that meditating works fine, or a (short 10-15 mins) goof off with a "mindless" game (my favorite is Race the Sun)
Forgot to mention, reading interesting stuff online or watching youtube only makes starting again harder for me..
Definitely! Especially what you are reading- watching is not directly related to the context / task.
Meditation seems to work for me as well as it "cleans the slate" - does a good job at removing the redundant information.
It does not however help that much with Starting the second context/task. That feels all on me.
It does not however help that much with Starting the second context/task. That feels all on me.
I second the meditation suggestion. It’s a brain software problem.
I found this exercise[1] useful at communicating the problem but not so much of a help on how to deal with it.
[1] https://www.learningscientists.org/blog/2017/7/28-1
"Task 1 (counting from 1 to 26) took 5-48 seconds
Task 2 (reciting the alphabet) took 3-22 seconds
Task 3 (switching back and forth) took 27-110 seconds.
Importantly, every single student took longer to complete the combined Task 3 than the sum of the time it took them to complete both of the other tasks (Task 1 + Task 2). So, every student in my sample experienced task switching costs."
"Task 1 (counting from 1 to 26) took 5-48 seconds
Task 2 (reciting the alphabet) took 3-22 seconds
Task 3 (switching back and forth) took 27-110 seconds.
Importantly, every single student took longer to complete the combined Task 3 than the sum of the time it took them to complete both of the other tasks (Task 1 + Task 2). So, every student in my sample experienced task switching costs."
It is costly to switch context. I try to avoid it unless my boss directly asks me to. Even then, I try to wait until next day to do so.
For me, it takes sometimes 5 minutes and sometimes 4 hours or more to be able to focus 100% on the new context.
How do you deal with this Context Switch - Shift of focus? Do you recommend any tools?
(I am currently trying to build a tool to reduce the switch penalty as I haven't found a solution)