Archive

Monthly Archives: August 2018

Alien Tech Alien Tropes

August 28, 2018
Culture change, Organisational effectiveness, Organisational Therapy, Software development
1 Comment

Alien Tech Alien Tropes

 

“Any sufficiently advanced technology is indistinguishable from magic.”

~ Arthur C Clarke

One of the reasons we chose the name “Familiar” for our software house (the first 100% Agile software house in Europe, BTW) was a homage to the above Arthur C Clarke quotation, and the connection with things magical. (Familiars, black cats, toads, witches, and so on).

The results we delivered to our clients were – mired as those clients were in traditional, failing approaches to software development – to them quite magical. And very alien.

And the idea that Alien Tech, although often inexplicable to us Homo sapiens, can confer amazing benefits has been a staple theme of science fiction books, films and TV for many decades (see: Stargate, Alien, Predator, Slan, Null-A, etc.)

It’s not much of a stretch to regard Organisational Psychotherapy as a kind of technology (see definition, below). And there’s no denying it’s an idea and a discipline alien to most organisations today. So, in my book, that makes Organisational Psychotherapy some kind of ALIEN TECH.

Organisational Psychotherapy is but one of many alien tropes which offer amazing benefits, yet from which most organisations recoil, due to the sheer alienness of such tropes (we could call this reaction “alienation”).

Put another way, the traditional tropes of conventional (Analytic-minded) business and management leave organisations floundering in a swamp of ineffectiveness, compared to the alien tropes of the less conventional Synergistic- (a.k.a. Teal) and Chaordic-minded organisations. Alien tropes are the sine qua non of highly effective organisations.

In my wider role of enterprise software development coach or tech business coach, one of my core value-adds is bringing alien tech and alien tropes to the attention of my clients, highlighting the benefits of these alien ideas, and helping my clients address and hopefully resolve their issues of alienation, such that they can begin to replace their conventional tropes with these alien tropes and reap the benefits.

By way of example, here’s a brief list of some alien tropes, “alien” that is to conventional management thinking:

  • Flow
  • Systems Thinking
  • Theories
  • Self-organisation
  • Fellowship
  • Cost of Focus
  • Cost of Delay
  • Play
  • Slack
  • Nonviolence
  • Psychology
  • Generalising specialists

See also my post entitled “Baggage”

Some Definitions

Alien

(adjective)

  1. unlike one’s own; strange and not familiar; not belonging to one.
  2. coming from another world; extraterrestrial.
  3. differing in nature or character, typically to the point of incompatibility.

Technology

(noun)

  1. the branch of knowledge that deals with the creation and use of technical means and their interrelation with life, society, and the environment, drawing upon such subjects as industrial arts, engineering, applied science, and pure science.
  2. the application of this knowledge for practical ends.

Trope

(noun)

  1. commonly recurring clichés in e.g. business literature. For example: Leadership; Utilisation; Management; etc..
  2. involving an agreed-upon narrative, an archetypal reading of a story or situation according to the simplest and most widely-held beliefs, a kind of narrative stereotype.
  3. a word or expression used in a figurative sense
  4. devices and conventions that a speaker can reasonably rely on as being present in the audience members’ minds and expectations.

– Bob

Further Reading

Trope (Literature) ~ Wikipedia entry

Excolat in Pace

August 10, 2018
Coding, Dialogue, Organisational effectiveness, Software development
Leave a comment

Excolat in Pace

There’s a common idea which has been doing the rounds, ever since development (coding) first became a thing. We might sum it up as:

“Developers just want to develop in peace.”

As someone who spent more than a decade in the development trenches (and still does development today, occasionally), I can instantly relate to this issue. Indeed, focus is the key question. Any kind of interruption or distraction whilst reading or writing code can suddenly evaporate the evolving mental model of the inner workings of that code, a model built up painstakingly, with deep concentration, over twenty minutes or more. So three for four interruptions or distractions, however trivial, can wipe out an hour of otherwise productive effort. And that’s before we get to the question of frustration, the impact of frustration-induced stress on the individual, and the stress-related impairment of cognitive function more generally.

On the other hand, having developers separated from the folks that matter introduces other productivity-sapping dysfunctions, such as misunderstanding folks’ needs, building the wrong things, and reducing the joy of getting to see how the developers’ efforts make a difference to others.

Conundrum

So, how to ensure developers have the peace they need to focus intently on their coding efforts, whilst also ensuring they have sufficient interactions with the folks that matter – sufficient to ensure that needs are understood and the right solutions get built?

In the past, specialist intermediaries a.k.a. Business Analysts and Project Managers have served to address this conundrum. And solutions (including the role of specialists, and the workplace environment) have been imposed on developers without much consultation. Rarely have developers, or the folks that matter, been involved in finding a way forward together.

Personally, and in the context of self-managing teams in particular, I’m all for the teams and their customers (both internal and external) getting together and thrashing out a way forward. And then having regular check-ins to improve those ways of working together.

As an example, BDD (Behaviour-deriven development) is a current set of practices that offers one such way forward. Customers and suppliers sitting down regularly (as often as several times a day, for maybe twenty minutes at a time) and working through a User Story, Scenario, or Use Case, together.

And let’s not forget that the other folks involved, aside from the developers, also have their day jobs – jobs which require them to focus and spend time on things other than working with the developers.

How do you, your teams, and their folks that matter, propose to tackle this conundrum? How are you handling it at the
moment?

– Bob

Postscript

Another option that comes to mind is mob programming a.k.a. mobbing, particularly with the involvement of folks having in-depth domain knowledge (i.e. customers and users).

What is Expertise?

August 3, 2018
Antimatter principle, General, Organisational effectiveness
2 Comments

What is Expertise?

Hiring an expert is a pretty much everyday occurrence. There’s accountants and lawyers, bankers and insurers, butchers and burger flippers, gardeners and mechanics. Sometimes we hire people not for their expertise, but simply to save us time, for example dog walkers or housekeepers.

For those folks we hire for their expertise, what does that actually mean? In the Antimatter frame, we might choose to say that experts possess – and can apply – more effective strategies for getting (some of) our needs met than we possess ourselves.

We’d not often tell our accountant how to calculate our tax liabilities. Nor our lawyer how to prepare and present our legal case. That’s because, with their more effective strategies, they’re likely to achieve a more effective outcome than we, with our relatively ineffective strategies, could. So we’re more likely to see our needs (in the round) get met.

Where’s this Going, You Might be Asking

Well, let’s turn our attention to hiring people – be that employees, contractors or consultants. Sometimes we’ll hire people to save us time. We could do the job that we’re hiring them to do, but we have more valuable things we can be spending our time on, so we hire them to do the less valuable things.

But sometimes, we’ll hire folks for their expertise. There’s some needs for which we accept our own strategies for getting those needs met are relatively ineffective. Like, running a software team or department, for example. So we find someone who appears to possess – and can apply – relatively more effective strategies.

So far, so good. If we choose our experts well, we’ll see our needs met more effectively – sometimes very much more effectively – than if we chose to attempt to meet those needs ourselves.

However. What happens when the effective strategies employed by our experts seem inexplicable to us? When we just can’t understand how applying their preferred strategies can achieve getting our needs met? We rarely quiz our accountants and bankers on their strategies. But we do quiz our new hires. As if we’d understand.

The Credibility Barrier

We have crashed headlong into the “credibility barrier”. Where it’s our own incredulity that blocks us from hiring those very folks possessing the most effective strategies for getting our needs met. And the most likely outcome being, we’ll reject the expert and their expertise, rather than recalibrate our assumptions and beliefs about what’s credible.

– Bob