(My talk at SpeakerConf was about something I've dubbed "Situational Context" and why its important for structuring work among groups trying to accomplish something technical. This material is the first part of that talk)

Situational Context is the local knowledge within someone's work space.

Now there is a branch of philosophy devoted to Knowledge called Epistomology. It turns out that knowledge is a funny thing. It seems obvious to us that we know something, and yet an exact definition has eluded philosophers for millennia - going back at least as far as Plato.

To summarize the common (problematic) definition: We know something when a) Its true b) We believe its true & c) We are justified in believing its true.

It's that last bit that causes all the trouble.

As you might expect, much of the debate has turned on what is "justifiable", but in 1963 a philosopher named Edmund Gettier showed that even if we are justified in believing something that is actually true, we still may not really have known it (not only is Gettier's paper pretty compelling, its short, interesting and pretty easy to follow - what a rarity in a philosophy text!).

Further, there are different types of knowledge: scientific, partial & situational (among others). Scientific knowledge is the most sure, but much of our knowledge about the daily world around us consists of the other two.

So what does this have to do with technical work? Well, if its not entirely certain what knowledge is and much of the daily knowledge about what people do is partial & situational and yet we tend to believe what we know is obvious, then clearly figuring out just what a piece of software or hardware should actually do is not as easy as it might first appear.

Technologists need hard unambiguous facts to successfully implement systems (my theory as to why so many of us are pedantic), but most of the knowledge available to us is partial and/or situational. Further, many (most?) decisions are made using something called Bounded Rationality (a topic for another post) meaning that at any given time people are making decisions (and changing what's known) using the partial situational knowledge available in their... context.

And it is this Situational Context that we need knowledge of to do technical work successfully. The problem is: that knowledge is only really available to those within the context. Whenever we try to move it out, it costs us - at least the time spent in informal conversation, but more so in actual meetings and even more if we attempt to write it down. It gets even worse when we introduce managers, PM's, analysts and others in a ever-expanding game of telephone that forces us to go round and round seeking the truth.

The XP movement made a point of emphasizing that having customers and programmers working closely together greatly reduced the cost of writing software. Like other early messages of XP (again a topic for another post) this has been diluted by the Agile diaspora, and so now its much more common to see programmers working from story cards that either attempt to render explicit the situational knowledge of the customer or (at best) serve as placeholders for a conversation for transferring that knowledge. As agile techniques infect IT, this (anti?) pattern will likely spread to other forms of technical work.

I think we can do better.

This transfer (however accomplished) crosses what I have termed the Situational Context Boundary and like any other context boundary, cost goes up exponentially when you do this. Story cards, iterations, etc reduce the cost relative to other techniques, but I've begun to think we're optimizing the wrong part of the process.

What if we kept the work inside the boundary? Then presumably costs can be kept lower. How? Well for those within the context, terms can remain undefined because everyone just "knows" what they mean allowing whomever is available to simply do the work. Edge cases can be safely ignored because everyone knows they won't be encountered. Features can be anticipated because we know what people are actually doing with the system. The list goes on and on.

This is more than just Daily Customer and it plays out at all levels: Between end-user & programmer, between programming teams (e.g. shared services) and even within them (between pairs & individuals). Its true within IT departments too - especially since they tend to be organized into silos around parts of the whole (e.g. hardware, networking, sys admin, etc).

If people are mostly working within a context, you can reduce or eliminate lengthy conversations to share that context. The trap is that people think they are reducing cost by separating the work, but I posit that any time we save by doing so is lost (with interest) in the endless questions, discussions, rework, loss/gain of trust, maneuvering and just-plain politicking that results from us knowing a hell of a lot less about one another's situation than we think we do.

In short: Be aware of when you are moving effort across a situational context boundary, because the cost of getting things done is going to increase as people switch from working to talking about work. Look for ways to keep the work within a context while sharing effort among many participants.

In a future article I plan to talk more about techniques for doing so.