Hi all. I share management of a team of about 25 software engineers, and the topic of context switching has come up. I struggled with how to offer great ideas and a plan for my direct.
We work in software development on remote teams spread between the United States and Brazil, agile methodologies. Its a large solution, so its very common for engineers, especially developers, to be expected to discuss and execute work on different parts of the solution on an ongoing basis. For instance....meetings on one bit of upcoming work in the morning, analysis on an upcoming defect fix a bit later, executing/coding on your previously committed work in the afternoon. Repeat.
So the upside....this is the general approach for a reason. We want people to get exposure to how more senior team members solve problems across our large domain. We dont EXPECT them to be fast and efficient at these tasks in new areas, but we dont shy away from involving them for awareness and learning. Usually, this means things are a bit chaotic for the first year (or even two), then things become more second nature, and the stress from bouncing around disappears as knowledge of the whole solution is gained.
So what sort of advice or change in process can I offer a direct who is experiencing an uncomfortable amount of stress due to this type of context switching on a remote team? I think there may be some field agnostic aspects to a good answer for him, but also any thoughts on managing context switching in software engineering would very welcome. Its a field thats consistently shown to have a higher context switch cost (i.e. it takes longer to get into a 'flow' state relative to other disciplines, like management :))