Context switching in the IT world can be very harmful to schedules
One of the biggest issues I see in a lot of IT / Software Development environments is the lack of understanding when it comes to context switching.
There are a lot of managers that don't understand how much work is lost when they expect their team to multitask. More disastrous is the interruption that could have been an email or voice mail. I rarely answer my phone and shut down email when I want to concentrate. Cubes have wrecked the ability to focus. My current cube is totally open and I am surrounded by a support team that have a line waiting to talk to them sometimes.
When I was in the electronic engineering field we had offices. When the door was closed that meant you were in a meeting or deep into your work. Unless it was an emergency, rarely was there a knock. You'd get a polite email asking for you to let them know when you were free.
It can take an hour to ramp up and get into full motion. Getting interrupted can sent you back an hour and a half easily. Your not ramping back up from a clean shutdown, your ramping back up some where in the middle of an abrupt interruption. Kind of like a train wreck.
At TechED 2011 Microsoft introduced a new Visual Studio-vNext feature to help with context switching. In essence it allows you to save the current state of your Visual Studio work environment so you can return to it exactly like you left it. Although this will help a little if you need to switch to another part of the solution you are working on, it won't help the overall issue.
If I am working on a major issue that involves the entire architecture of an enterprise wide application, I may have a dozen touch points I am working on at the same time. To be pulled away from them unexpectedly for an hour or two to put out a fire can trash a whole days work.
When I am in charge of a team of developers I expect the project manager to be running interference for us. Often that job falls on me when there is no project manager. I have often told my team in the past that if they are approached with a fire the only response I want them giving is the one that sends the person to me first. I don't want my team disturbed.
I have learned that in certain environments an estimation needs to be doubled at a minimum because you can expect to be pulled off a given task several times a day.
Managers that don't understand this find themselves way behind on the schedule before they even know what hit them.
There are a lot of managers that don't understand how much work is lost when they expect their team to multitask. More disastrous is the interruption that could have been an email or voice mail. I rarely answer my phone and shut down email when I want to concentrate. Cubes have wrecked the ability to focus. My current cube is totally open and I am surrounded by a support team that have a line waiting to talk to them sometimes.
When I was in the electronic engineering field we had offices. When the door was closed that meant you were in a meeting or deep into your work. Unless it was an emergency, rarely was there a knock. You'd get a polite email asking for you to let them know when you were free.
It can take an hour to ramp up and get into full motion. Getting interrupted can sent you back an hour and a half easily. Your not ramping back up from a clean shutdown, your ramping back up some where in the middle of an abrupt interruption. Kind of like a train wreck.
At TechED 2011 Microsoft introduced a new Visual Studio-vNext feature to help with context switching. In essence it allows you to save the current state of your Visual Studio work environment so you can return to it exactly like you left it. Although this will help a little if you need to switch to another part of the solution you are working on, it won't help the overall issue.
If I am working on a major issue that involves the entire architecture of an enterprise wide application, I may have a dozen touch points I am working on at the same time. To be pulled away from them unexpectedly for an hour or two to put out a fire can trash a whole days work.
When I am in charge of a team of developers I expect the project manager to be running interference for us. Often that job falls on me when there is no project manager. I have often told my team in the past that if they are approached with a fire the only response I want them giving is the one that sends the person to me first. I don't want my team disturbed.
I have learned that in certain environments an estimation needs to be doubled at a minimum because you can expect to be pulled off a given task several times a day.
Managers that don't understand this find themselves way behind on the schedule before they even know what hit them.
posted by tadanderson at 11:40 AM
0 Comments:
Post a Comment
<< Home