TL;DR Knowledge is power - you can't foresee & script creative way of knowledge workers if you really expect valuable outcomes. The only way is (once you get proper people first) to provide them necessary degree of freedom & contextual knowledge - up-to-date, comprehensible, applicable, broad yet adjusted to the goal - in short words: the proper CONTEXT.
My geeking around sometimes sends me drifting towards rather surprising waters ... for instance: behavioral / congitive psychology. "Thinking fast & slow", flow, psychology of change, etc. Some of the most interesting research materials I've got myself through were about ... jet fighter pilots & the way they learn & behave in real combat situations to actually survive.
In the times of open conflict, pilot mortality was skyrocketing & there was no wonder (keeping in mind how much time, money & effort it took to fully train a new pilot) that there was a lot of energy spend on tinkering - how to help aspiring (less experienced) sky aces to survive (or at least increase the probability they will ...) until they actually get some real battlefield experience.
Rulebook no 3125A/74
Unsurprisingly (yet intuitively), it has started with very formal, "algorithmic" prescriptions -> codebook of procedures & conditional reactions (pilot's "framework"). Which of course didn't work out at all:
- concise ones were too ambiguous
- more detailed ones could not have been memorized, tended to increase their complexity in time & in the end even self-contradicted
- all of them were very brittle -> dynamic weather conditions, shifting combat situation, adjustments to the weaponry parameters (e.g. tuned rocker models) were instantly invalidating many of assumptions in a non-predictable way
OODA ...
To keep the long story short, soldier boys (to be precise - military strategist John Boyd) have figured out a much better way to go: they've called it OODA loop & it was all about situational awareness. Feel free to read up on them using the links I've provided, for the sake of this blog post I'll just sum them up by saying that:
- complex situations require different approach then complicated ones (mind the difference between these 2 according to Cynefin framework) -> pre-prepared strategies (that can be executed mechanically) can be guidelines, but do not work literally "in the trenches"
- complex situations should be handled by highly-skilled, well-trained specialist equiped with:
- sufficient degree of freedom (to make their own decisions)
- context-specific, relevant information they need to make decisions
- contextual information provided can't be limited to the goal & basic "rules of the game" - what is equally important is THE CONTEXT -> from big picture (that usually remains stable & changes rarely) to narrow, dynamic nearest surroundings you directly interact with (make an impact on, depend on, ...) - with all levels of detail equally important
Context, its dynamics - these ofc depend on scenario we speak about.
For a fighter pilot it's all about positions & velocities (and changes of these 2 parameters) of machines (& launched missiles ...) in the fire range. Planning long-term (even for ~10 secs ahead) will not end well in close combat. OODA is about very short Observe-Orient-Decide-Act cycles that are aimed to take advantage of the continuously changing combat situation.
Update.
Reassessment.
Immediate Reaction.
Repeat.
... and chess
As you can see it's all about being able to understand (& benefit from) the context, based on your situational awareness.
- Missing or limited context? Acting blindly.
- Wrong, faulty, outdated context? Wrong decisions.
- Too verbose, imcomprehensible context? Too slow decisions.
- Need to reverse engineer context from its derivates? Inefficient, error-prone decisions.
Needless to say, this concept is applicable in other scenarios as well. Ones that do not involve sub-second decision-making & fighting for your life. Next example comes from fabulous keynote of Simon Wardley from last Build Stuff LT conference & is about ... chess.
Imagine you're playing a game of chess against another player, it's in progress for an hour already, your opponent has just made his move & you're next. The key question is - what will your decision be based upon?
Most likely you've said something like that: "current state of the game, a resultant of all the past moves made in this very game". OK, so let's consider two different ways of presenting this information for you:
The first one is a classic view of the chessboard, e.g. like that:
The second one is a full, chronologically sorted list of chesspiece moves in this particular game, e.g.:
- c2 -> c3
- b8 -> c6
- ...
Clearly the 2nd form is more complete -> it presents ALL past actions, applied strategies, overall game dynamics & sum of this information leads you where you're now: current setup on the board.
OTOH, the 1st form is more limited -> history is not visible at all, opposing player's style can only be deduced. All you see is the remaining set of chess pieces in the current places, alltogether, in one, simple, 8x8 board view ... which is in fact MUCH, MUCH better than "more complete" form number 2.
Because it's precisely the context within which you're gonna make the bloody move. Simple, yet very striking (at least it was in my case) example.
Gief context?
Cool. But where's software in all of that?
All non-trivial software making scenario are complex enough to involve creative/knowledge workers instead of 'trained monkeys', yet so many companies still treats developers like sophisticated translate-doc-to-code machines:
- Creative workshops, envisioning, strategy meetings -> devs not invited
- Client visits, direct exposure to end-users -> devs? nah
- Operational KPIs, customer analytics results -> confidential, not for devs
- Business know-how details, value chain (or revenue stream) analysis output - restricted, business only
- Product development, conceptual design, functional modeling - move out tekkies, we need space
What happens next is near to no context (higher or lower level) provided, just "User Stories" on the level of visual detail. How can you expect anyone create a quality software that will actually support your business in reasonable way if your developers act like blinfolded?
Frankly speaking, developers are to be blamed for this state of affairs as well - too many of them are super-comfortable with not caring for what actually is being built. Cool framework? Check! Decent salary? Check! Free coffee & XBox in the chill-out room? Check! It is really the highest time for all of us to think about developers not as Software Developers but (Software-based) Product Developers.
