Code Freeze - The Collective Groan

One of my favorite moments at Code Freeze 2010 was when a presenter noted that everyone pictured on a particular slide worked six different projects. At that pronouncement, a general groan arose from the audience.

Where I work, I currently keep a load of around half a dozen projects, although if you slice and dice them, or consider my space to overlap with that of the other manager who does the same work, the portfolio is considerably larger. Fortunately, I have smart leads, and they really handle the bulk of the lifting, allowing me to focus on wider issues. But to stress how many projects you can expect working in my area, one of the question sets on my lead hiring interview form is "Have you worked in a matrixed environment? On how many projects simultaneously? How do you handle the context switching and constant flow of information? Where do you put your focus when there are competing priorities?" I've dinged more than one interviewee for never having worked on multiple, large projects simultaneously. Despite the groan from the Code Freeze audience, the interview process turns up a significant number of developers who are allowed to maintain their focus.

In my last role, I think I maxed out at thirteen simultaneous projects, not including my generalized day-to-day role. One project, overseas, consumed about 50% of that time, and the others cycled up and down over days and weeks from zero to twenty hours. But all were partially active, somewhat different, and not predictably cyclical. It wasn't abnormal to have twenty hours of concrete work flow in over the course of a day. The goal was then to push it down as fast as possible because you couldn't be sure the downswing was coming immediately. Additionally, when you were on call, you might be fielding questions, requests, functionality assessments, architecture explanations (and changes), training, coding (yes, coding - I still touch code, even now), and more, for upwards of twenty simultaneous teams/projects (we called them "partners"). Handling half a dozen projects in my current role has been somewhat relaxing by comparison.

But I should append that it was my old manager who once took a look at my forty hour per week schedule and dumped an extra twenty hour per week partner on me, overloading me. She was the first person who ever concretely pointed out to me that I work more effectively when I've got a little too much to do. That sort of load compels me to find ways to streamline until I'm back down to forty, and the processes and code I put in place generally benefit everyone. It was a good call on her part, and I've always felt it's evidence she was really paying attention to me in her managerial role.

I guess I'm trying to say I wasn't one of the attendees who groaned - which is a bit suspicious, because as a developer I seem to thrive in a matrixed environment (I'll post a bit about big company hiring premiums later) - but knowing that each employee is different, I can empathize with those that did, particularly as agile recommends avoiding context switching, and find some humor in the general despair that it's often expected of those who thrive in a more focused environment.