Forced Context Switching

Sometimes, despite your best efforts you get forced to stretch a developer across more than one project. Johanna Rothman posted on this recently arguing that many managers just don’t get the difficulties of asking their people to multi-task. Sometime, I don’t really get a choice.

I’m very familiar with the pains of context switching since as a manager it’s often a part of my world. My day continuously involves getting pulled in to help review a prototype for a developer or talk a system admin giving us read access to log files. Since my job is to make my people more effective I can’t complain too much when I get interrupted.

Still things come up. Business owners request certain resources they emotionally feel are the only safe choice for a high profile project. As a development manager part of your responsibility is to work with your customers. If they are so attached to this opinion that you are unable to sway them, you’re forced to give them the resource they ask for even if it’s just to appear at meetings and help a bit with the coding.

Long term the customer should be convinced that the other developer who’s doing the bulk of the coding is perfectly capable of handling their high profile projects. Still in the short term you’re forced to split one of your developers across contexts and damage their own productivity. I haven’t found a better way to handle it, and in many ways I doubt I ever will.

5 responses to “Forced Context Switching”

  1. Jason Yip says:

    What would happen if somehow, magically, it was impossible for a developer to work on more than one project at a time. What would you do?

  2. Ed Gibbs says:

    In a world of absolutes, I suppose I’d just leave a developer on one project. Unfortunately given my current context where I’m rebuilding faith in the development organization with the business side, that’s a risky proposition. The other problem is the developer I’m context switching is helping lead another project. If I just switch him to the higher profile project completely, I pretty much stop his other project in its tracks and idle yet another developer.

    Sometimes resource allocation stinks.

  3. Julio Santos says:

    Perhaps what makes it a little worse, is to ask the top developers to spend their days in meetings, or on the phone, or writing stuff for others, “to leverage your knowledge”.

    It’s as if: “The better you are at doing something, the more you’ll have to talk about it, and by consequent, the less you’ll be able to do that something”

    I understand that real world though, and appreciate that good managers such as yourself try to minimize those context switches. But good managers, seem to be exception.

    Most won’t rest until everyone is running around the hallways with their hair on fire. I think Jonathan is talking about those and not so much about stuff that happens (I’m not sure though, just imagining it).

    BTW, if you haven’t read it already, here’s Joel on the subject. Pretty good read.

  4. There’s no world of absolutes, I guess. We have to do what we have to do.

    I’ve read that any person is most productive when juggling two tasks. Add a third, and productivity plummets. Typically, we’re juggling (a) a project or some other work assignment, and (b) the administrative stuff that goes along with having a job. So when we’re assigned to two or more projects concurrently, we can’t be highly productive.

    I wonder if Ed is seeing this phenomenon: When a developer is assigned to multiple projects, each project manager tends to treat him/her as a de facto 100% resource. In a traditional organization, the result is that the squeaky wheel gets the oil. In a mixed organization, the effect can be that the non-agile projects pull people away from the agile projects (some people call this “stolen time”). Since traditional projects track tasks and agile projects track velocity, it’s the agile projects that suffer for this. You need to get a time commitment from each developer per iteration, and then keep an eye on the other project managers to defend that time.

    Another effect is that a developer might end up working excessive overtime in an attempt to satisfy all his/her commitments. That “breaks” the agile principle of sustainable pace, and can affect productivity.

  5. Ed Gibbs says:


    “In a mixed organization, the effect can be that the non-agile projects pull people away from the agile projects (some people call this “stolen time”).”

    This rings really true, and it happens all the time. Since some of the development managers aren’t all that sold on the Agile concept, they constantly pull their resources to work on maintenance things for other projects, code walk-thrus, etc. The developers aren’t that excited about it and we hear about it in standup meetings, but it continues to happen.

    There are some signs of change though. A product owner went to bat for two mainframe developers that we’re getting pulled of an Agile pilot project for a whole Sprint. Suddenly we have one of the mainframe developers back full time.