On Context And The Taylor Approach To Knowledge Work

Updated to tag this as Monotasking, which is, in a nutshell, what I’m on about.

Things are improving a bit, if only because I’ve been making a conscious effort not to drag a lot of work home - e-mail and a little review work at the most, and even then focusing on only a few things at a time to avoid spreading myself too thin.

Again, context is key to GTD. Having to constantly hop from one thing to the other is a major drain on time and patience, since I end up taking up to half an hour to get into the right mind set again (checking notes, going through previous discussions, recalling odd dependencies on issues, etc., etc.).

Doing less things at a time is, as usual, the best way to get more work done, but that seems to be lost on the modern organizational paradigm of “ad-hoc cross-competency teams” that assumes (wrongly) that:

1. you can slice your time across many different projects provided you are given clear bounds on your assignment.
2. you’re flexible enough to accommodate everyone’s whim.
3. you and the rest of your so-called “team” will have compatible schedules.

The first point is the sadistic bastard child of Taylorism and some obscure twist on knowledge work taken from a toilet-paper edition of “Management for Idiots”, given away at self-improvement and time management courses for people who can barely manage their own schedule, let alone their minions’.

I have lost track of the times when people have told me “You just have to go and do that”, usually followed by “by next Tuesday” (or worse) and occasionally followed by a “never mind what you were doing” or the utterly, utterly clueless and profoundly asinine “it should be no problem for you”.

That, of course, is usually a non-trivial undertaking (often hopelessly botched by the previous owner) that is neither compatible with my (by now sliding) schedule or my current work context, which means that I will have to get up to speed on that and expend precious time better spent on finishing what I was doing before taking on new things.

My main issue against that sort of assignment (if you’ll pardon the pun) is that the human mind (especially an overworked human mind) has inertia.

Yes, inertia, in the sense that when it starts moving in one direction, it requires considerable effort to shift focus.

And of course it gains momentum when work progresses (i.e., you accelerate) within the same context, which means that sticking that in its path is sure to cause some form of collision.

Whether it is an elastic or inelastic collision is left as an exercise to the reader, but by and large elasticity can be factored in as an inverse of the average amount of work a mind performs within a given reference frame - i.e., you’ll bounce back better when properly rested.

But the first point is also completely wrong not just due to the human mind’s need for context (and leveraging it in a continuous way rather than frenzied bursts), but also to the fact that it is impossible to establish clear bounds on knowledge work.

In my experience, that tends to be a completely different thing depending on viewpoint (and yes, this smacks of relativity, but I’ll spare you the Physics analogies) - the people who hand you the assignment think of it one way, the other people on the team think of it in another (more on that later), and, quite usually, the person who previously worked on it followed that‘s dependencies into some obscure nooks and crannies that you’d avoid if you had even half a chance.

Not to mention that whoever is waiting for that to get done will always ask you why you didn’t do it differently.

The thing about tackling that with other people is not just about different viewpoints: In a modern organization where everyone is supposed to collaborate on everything, the main issues tend to be ugly turf wars about poorly defined areas of responsibility - i.e., everyone trying to stick their fingers in what is essentially an infinite amount of pies.

So, in order to get anything done, you have two broad approaches:

• Kick ass (the Nac Mac Feegle way)
• Be constructive, supportive, and try to understand that everyone else on the “team” expects you to do that as quickly as possible and (this is the catch) in the way that best suits them.

The trouble with the first approach (despite the fact that it is quite likely to wield much better results in the short term) is that it is rowdy, noisy, and not something you can do without some authority - and remember, the “ad-hoc cross-functional team” has no fixed (or defined) hierarchy, which means that it’s essentially like a herd of cats in a gunny sack - and therefore a potentially explosive situation if one of the cats treads on another’s tail (I know it’s tough for cats to step on another’s tails in a sack, please bear with me on this one).

And you know it’s impossible to herd cats, right? But lacking the authority to follow the first approach, you usually try the second one.

Which is at least tantamount to herding said cats (if not worse) and usually means protracted discussion about some inane point that one of the “team” believes to be a fundamental dependency for them to be done with that, and that all of a sudden becomes your problem.

Which, of course, brings us back to the first point and the issue of establishing clear bounds on knowledge work.

The bottom line is that if you lack the authority to define those bounds yourself within the “team” you’ve just been forcefully injected into, everyone else there will try to push off a portion of their issues on to you (usually with the excuse that “the other guy (before you) thought it was important too”).

Isn’t this fun? But wait, there’s more.

I’ve coined this term a while back, and it’s still one of my main gripes regarding time management. I am still trying to formulate a Theorem of Wasted Time, but a tentative approach reads -

The time spent in meetings expands exponentially with the number of projects you’re in, to the exclusion of all working hours.

Which is sure to have a first corollary along the lines of -

Working hours will expand invisibly beyond your office time and space.

But, more to the point, a second corollary that says -

The more meetings you have, the more time you spend fending off meeting requests to discuss the results of previous meetings.

If I ever get these formulated right (and proven by other than empirical means), I am sure to try to factor in herding cats - sorry, “working in ad-hoc cross-functional teams” and prove, beyond a shadow of a doubt, that -

It is impossible for any member of such a team to meet with more than three other members of that team at any given moment in time, requiring more separate “issue-driven” meetings.

Which, of course, besides completely nullifying the productivity of such a team, will bring us back to the corollary above. Q.E.D.

And I haven’t even gotten into what it means to do this in a multinational, where people will try to book your time for phone conferences at ungodly times in the morning or fly-to meetings at obscure locations requiring at least one connecting flight and labyrinthine cab rides.

It effectively boils down to the fact that people trying to book said meetings are either trying to herd you into doing that or trying to get you involved in another “ad-hoc cross-functional team”, but desperate either way. And, obviously, whoever asked you to do that doesn’t care neither about your own time nor about logic (let alone common sense), so you’re stuck anyway.

But you can make a difference - even if you can’t break the self-perpetuating cycle of meetings and misdefined goals, that can usually be dealt with by locking yourself in a meeting room, doing that to the best of your ability in one go (leveraging as much context as possible) and getting it out of your system.

You’ll be able to spend the next morning picking up the threads of your other work while the “team” bickers about what to do after that, and hope that you don’t get sucked into another such mental quagmire anytime soon…