Concrete Culture Change

Culture is often difficult to define, and culture change even more so – what concrete actions do we need to take to change a culture?

Despite this apparent difficulty, it is possible to spend an hour or two with a group, and leave with consensus on practical actions for culture change.

This exercise achieves that by make culture change something concrete. We look to the questions we ask everyday as reinforcing values and thus being drivers of culture. Then we challenge ourselves to find better questions, and explore what it will take to adopt those better questions in our specific context.

Questions driving culture

Let’s keep our definition of culture really simple: the sum of our everyday behaviours as a group.

To give an example: typically, you and your colleagues juggle many tasks at once. Multitasking is part of your culture.

What is driving this behaviour though? One strong driver is the questions that are asked in your group. For instance, in this environment, you probably find people explicitly asking something like “can you take this on?” The multitasking behaviour is a natural response to that question. Especially if all parties are, consciously or otherwise, implicitly asking themselves “how do we get everything done?”

Now let’s assume that you want to change your multitasking culture to one where people limit their work in progress to become more productive overall.

Making change more concrete

To change the behaviour, we can look for the driving questions and change those.

For instance, we might aim to change “how do we get everything done?” to “how do we do a great job of the most important things?”

And that is the heart of the change. If everyone is asking themselves, consciously or otherwise “how do we do a great job of the most important things?”, their behaviours will follow that question. In this case (and with training and support as required), we expect they will try to identify priorities, understand success and deliver on that before moving on to the next thing. People can helpfully answer “no” to the old question “can you take this on?”, but more importantly, that question will no longer be asked as frequently, because it will cease to make sense.

However, that’s still not as concrete a recipe as we would like. The exercise (below) helps us get down to the concrete actions required in a given context to change one driving question to another.

Before we go any further, though, a reminder that questions do not exist in isolation, and that we must tackle consistent set of questions simultaneously:

Today’s orthodoxy has institutionalised a set of internally consistent but dysfunctional beliefs. This has created a tightly interlocking and self-reinforcing system, a system from which it is very difficult to break free. Even when we change one piece, the other pieces hold us back by blocking the benefits of our change. When our change fails to produce benefits, we revert to our old approaches.

Donald G. Reinertsen, The Principles of Product Development Flow

The Exercise

This exercise can be run with the group whose culture we are looking to change.

At the end of the exercise, you will have a list of concrete actions that can be taken to change driving questions, and will have identified potential blockers to plan around.

To prepare:

  1. Observe the group and its behaviours
  2. Identify instances of counter-productive behaviours
  3. Analyse these behaviours to propose driving questions
  4. Pair current, undesirable driving questions with new, desirable driving questions
  5. Find examples to illustrate why each question should change

You should have something like the table below:

Example set of driving questions to change
Example set of driving questions to change

The exercise can then be run as follows:

  1. Discuss the premise of changing culture by changing questions
  2. Share your first example of a pair of driving questions, and the instance of the behaviour (this should be an instance widely understood and accepted by the group)
  3. Work through the other question pairs in your list, and ask the group to come up with examples themselves. They will generally do so enthusiastically! It’s unlikely, but if they don’t, you have your prepared examples to fall back on.
  4. Because you won’t be able to solve everything in this session, prioritise as a group (through dot voting, etc) the question pairs to focus on (no more than 3 for the first session). Allow 30 mins to 1 hour to get to this point.
  5. Now for each question pair, run an “anchors and engines” exercise to identify – in the group’s context – the potential blockers (“anchors”) and the supporting factors or concrete actions (“engines”). Take 15-30 minutes per pair. Synthesise individual contributions into themes.

You now have a set of concrete actions to support, and real issues that might hinder, the type of culture change you are seeking to achieve. It might look something like:

Culture change anchors and engines
Culture change anchors and engines

Of course, effort remains to make this change happen, but it can be directed very precisely, and that is valuable when dealing with culture.

Health Hack Perth 2015

HealthHack is a three-day event bringing medical researchers and health practitioners together with software creators to prototype a new generation of health products.

Business News Western Australia covered the Perth 2015 event in: HealthHack – ailments, remedies in equal doses.

I helped organise this event with assistance from sponsors ThoughtWorks and Curtin University (among numerous other generous sponsors). It was a great event, with important and challenging problems presented, innovative solution concepts delivered, and new relationships formed between individuals and organisations in health and technology.

Health Hack summary
Health Hack summary

Please refer to the report and the catalogue of products for detailed information on this event, and resources for hackathons in general. Health Hack is an Open Knowledge Foundation Australia event, so is predicated on sharing open source deliverables.

Some Highlights and Lessons Learned

We focussed on curated problems for this event, approaching a large number of potential “problem owners” with a checklist to recruit those with the most appropriate challenges for the weekend hackathon format. We then worked with the problem owners to shape their challenges and pitches for the “ideas market”. This was a very substantial effort (primarily by the fabulous Diana Adorno) in the lead-up to the weekend, but the well-formed problems were key to the success of the hack.

Health Hack pitch posters
Health Hack pitch posters

We attracted a diverse set of participants, with skills ranging from design, to software development, to data science, and these individuals organised themselves into teams around the problems most suited to their collective skill set. As organisers, we made only one substitution to balance teams.

We started with fewer participants than expected, because the drop-off rate from registrations was substantially higher (50%) than previous years at other sites (30%). However, attrition over the weekend was virtually zero, as the participants were uniformly enthusiastic and energised by their challenges.

The ideas market built great energy around the challenges and the potential for the weekend. We posted the challenges around the room prior to the event. Then the problems owners took turns to pitch in just 2 minutes each from their challenge posters. The pitches were clear and concise, and the cumulative effect was really energising. When the pitches were done, participants had time to walk the room, seek more information from problem owners, and organise their own teams.

Coaching and regular check-ins on team progress helped keep the teams focussed on solving key problems and having a demonstrable product at the end of the weekend. No team failed to showcase. However, we had feedback that access to more coaching would have been valuable.

Health Hack showcase
Health Hack showcase

The venue at Curtin University Chemistry Precinct was ideal, with team tables, breakout spaces and bean bags, and surrounded by gardens. However, it was the only Health Hack venue not in the CBD of the host city, and this may have presented transport challenges (though we didn’t collect any data on this). The plan at the time was to rotate the venue through various supporting institutions in future years.

Food trucks and coffee vans were a great way to service participants! Although it required some coordination ahead of the event, and may not be possible in CBD sites, it was very easy on the weekend, and lots of fun.

For more, see the full report.

Arguments with Agency

Here are slides from my talk at LASTconf 2015. The title is “Bring Your A-Game to Arguments for Change”. The premise is that there are different types of arguments, more or less suited to various organisational and delivery scenarios, and the best ones have their own agency. In these respects, you can think of them like Pokemon – able to go out and do your bidding, with the right preparation.

Change agents
Change agents

The content draws heavily from ideas shared on this blog:

Your Software is a Nightclub

Why a nightclub? Well, it’s a better model than a home loan. I’m talking here about technical debt, the concept that describes how retarding complexity (cost) builds up in software development and other activities, and how to manage this cost. A home loan is misleading because product development cost doesn’t spiral out of control due to missed interest payments over time. Costs blow out due to previously deferred or unanticipated socialisation costs being realised with a given change.

So what are socialisation costs? They are the costs incurred when you introduce a new element to an existing group: a new person to a nightclub, or a new feature into a product. Note that we can consider socialisation at multiple levels of the product – UX design, information architecture, etc – not just source code.

Why is socialisation so costly? Because in general you have to socialise each new element with all existing elements, and so you can expect each new element you add to cost more than the last. If you keep adding elements, and even if each pair socialises very cheaply, eventually socialisation cost dominates marginal cost and total cost.

What is the implication of poor socialisation? In a nightclub, this may be a fight, and consequent loss of business. In software, this may be delayed releases or operational issues or poor user experience, and consequent lack of business. If you build airplanes, it could cost billions of dollars.

What does this mean for software delivery, or brand management, or product management, or organisational change, or hiring people, or nightclub management, or any activity where there is continued pressure to add new elements, but accelerating cost of socialisation?

Well, consider that production (of stuff) achieves efficiencies of scale by shifting variable cost to fixed for a certain volume. But software delivery is not production, it is design, and continuous re-design in response to change in our understanding of business outcomes.

Change can be scaled by shifting socialisation costs to variable; we take a variable cost hit with each new element to reduce the likelihood we will pay a high price to socialise future elements. Then we can change and change again in a sustainable manner. We can also segment elements to ensure pairwise cost is zero between segments (architecture). But, ideally, we continue to jettison elements that aren’t adding sufficient value – this is the surest way minimise marginal socialisation cost and preserve business agility. We can deliver a continuous MVP.

So what does this add to the technical debt discussion? All models are wrong; some are useful. Technical debt is definitely useful, and reaches some of the same management conclusions as above.

For me, the nightclub model is a better holistic model for product management, not just for coding. It is more dynamic and reflective of a messy reality. Further, with an economic model of marginal cost, we can assess whether the economics of marginal value stack up. Who do we want in out nightclub? How do we ensure the mix is good for business? Who needs to leave?

What do you think?

Postscript: The Economic Model

We write total cost (C) as the sum of fixed costs (f), constant variable cost per-unit (v) and a factor representing socialisation cost per pair (s):

\[ C = f + vN + sN^2\]

Then marginal cost (M) may be written as:

\[ M = v + 2sN \]

Socialisation Cost
Socialisation cost against fixed and variable costs

Note: This post was originally published August 2014, and rebooted April 2015

Dumbbell Delivery; Antifragile Software

Not online fitness shopping. Not the brogrammer pumping iron. This is a brief discussion of Antifragile – the latest book by Nassim Nicholas Taleb – and relevant insights for software delivery or other complex work.

This isn’t meant to be an exhaustive exploration of the topics. It’s more a join-the-dots exercise, and it’s left up to the reader to explore topics of interest.

Antifragile

Antifragile is a word coined by Taleb to describe things that gain from disorder. Not things that are impervious to disorder; the words for that are robust, or resilient. Of course, things that are harmed by disorder are fragile. Consideration of the fragile, the robust, and the antifragile leads Taleb in many interesting directions.

Fragile, Robust, and Antifragile Software

A running software program is fragile. It is harmed by the most minor variations in its source code, its build process, its dependencies, its runtime environment and its inputs.

But software is eating the world. The global software ecosystem has grown enormously over an extended time – time being a primary source of variation – and hence appears to be antifragile. How do we reconcile this apparent paradox?

Here is a grossly simplified perspective.

First, software code can evolve very quickly, passing on an improved design to the next generation of runtime instances. In this way, tools, platforms, libraries and products rapidly become more robust. However, human intervention is still required for true operational robustness.

Second, humans exercise optionality in selecting progressively better software. In this way, beneficial variation can be captured, deleterious variation discarded, and software goes from robust to antifragile.

So – as fragile parts create an antifragile whole – runtime software instances are fragile, but fragile instances that are constantly improved and selected by humans create an antifragile software ecosystem. (If software starts doing this for itself, we may be in trouble!)

Some Delivery Takeaways

Yes, I know that’s an oxymoron. Nonetheless, here are some of my highlights. It’s a while now since I read the book, and I might add to this in future, so don’t take it as the last word.

Dumbbell Delivery

The idea of “dumbbell”/”barbell” risk management is that you place your bets in one of two places, but not in between. You first ensure that you are protected from catastrophic downside, then expose yourself to a portfolio of potentially large upsides. In such cases, you are antifragile.

If, instead, you spread yourself across the middle of the dumbell, you carry both unacceptably large downside exposure and insufficiently large upside exposure. In such cases, you are fragile.

For me, “dumbbell delivery” is how we counter insidious elements of the construct of two-speed-IT (insidious because no one has ever asked to go slow, or asked for high risk as the alternative). We ensure any project is as protected as possible from catastrophic downside – by decoupling the commission of error from any impact on operations or reputation – and as exposed as possible to potentially large upsides – by providing maximum freedom to teams to discover and exploit opportunities in a timely manner.

Donald Reinertsen makes a similar argument for expoliting the asymmetries of product development payoffs in The Principles of Product Development Flow.

Via Negativa

Those who intervene in complex systems may cause more harm than good. This is known as iatrogenics in medicine. To manage complex systems, removing existing interventions is more likely to be successful than making additional interventions, as each additional intervention produces unanticipated (side) effects by itself, and unanticipated interactions with other interventions in tandem. Via negativa is the philosophy of managing by taking things away.

Software delivery, and organisations in general, are complex in that they are difficult to understand and respond unpredictably to interventions. What’s an example of an intervention we could take away?  Well, let’s say a project is “running late”. Instead of adding bodies to the team or hours to the schedule, start by trying to eliminate work through a focus on scope and quality. Also, why not remove targets?

Big Projects, Monolithic Systems

Anything big tends to be fragile. Break it into smaller pieces for greater robustness. Check.

Waterfall and Agile

Waterfall done by the book is fragile. Agile done as intended is antifragile.

Procrustean Beds

Forcing natural variation into pre-defined, largely arbitrary containers creates fragility. Velocity commitments and other forms of management by performance target come to mind.

Skin in the Game

Of course, anyone making predictions should have skin in the game. On the other hand, Hammurabi’s code is the converse of the safe-to-fail environment.

The Lindy Effect on Technology lifespan

The life expectancy of a technology increases the longer it has been around. Remember this the next time you want to try something shiny.

Phenomenology and Theory

Phenomenology may be superior to theory for decision-making in complex work. Phenomenology says “if x, then we often observe y“. Theory says “if x, then y, because z“. Theory leads to the illusion of greater certainty, and probably a greater willingness to intervene (see above).

Flaneurs and Tourists

Chart your own professional journey. Allow yourself the time and space for happy discoveries.

Narrative Visualisation Tools

I use narrative visualisations a lot. I like to frame evidence so that it commands attention, engages playful minds, and tells its own story (see also Corporate Graffiti). I’ll put new tools on GitHub as I create them. Here are three to start.

Visualising Stand-Up Attendance

I used the Space Invader metaphor with a busy leadership team to explain how things would slip through the gaps from day if they didn’t attend stand-up in sufficient numbers and with sufficient regularity. The invaders represent the team members present each day, and each advancing row is a new day. The goal of the game is reversed in this case – we want the invaders to win! The team loved it and loved seeing their improved attendance reflected in a denser mesh of invaders.

Standup Space Invaders
Standup Space Invaders

Source on GitHub.

Aggregating Retrospectives

Useful if you want to aggregate multiple retrospectives – either the same team over time, or multiple teams on a common theme – and present them back while preserving the sincerity of the original outputs.

Re-retro screenshot
Re-retro screenshot

Source on GitHub.

Cycle Times from Trello

Trello is a wonderful tool for introducing visual management. It is not, however, great for reporting. Trycle (source on GitHub) will calculate cycle times for all cards transitioning between two lists using the JSON export of a Trello board (or the dwell time if just one list). Visuals and narrative not included.

Visual Knowledge Cycles

Visualisation is a key tool for the management of knowledge, especially knowledge from data. We’ll explore different states of knowledge, and how we can use visualisation to drive knowledge from one state to another, as individual creators of visualisation and agents within an organisation or society.

Visualisation Cycle
Visualisation Cycle

(There’s some justifiable cynicism about quadrant diagrams with superimposed crap circles. But, give me a chance…)

Awareness and Certainty about Knowledge

We’re used to thinking about knowledge in terms of a single dimension: we know something more or less well. However, we’ll consider two dimensions of knowledge. The first is certainty – how confident are you that what you know is right? (Or wrong?) The second is awareness – are you even conscious of what you know? (Or don’t know?)

These two dimensions define four states of knowledge – a framework you might recognise – from “unknown unknowns” to “known knowns”. Let’s explore how we use visualisation to drive knowledge from one state to another.

Knowledge states
Knowledge states

(Knowledge is often conceived along other dimensions, such as tacit and explicit, due to Nonaka and Takeuchi. I’d like to include a more detailed discussion of this model in future, but for now will note that visualisation is an “internalisation” technique in this model, or an aid to “socialisation”.)

Narrative Visualisation

I think this is the easiest place to start, because narrative visualisation helps us with knowledge we are aware of. Narrative visualisation means using visuals to tell a story with data.

Narrative Visualisation
Narrative Visualisation

We can use narrative visualisation to drive from low certainty to high certainty. We can take a “known unknown”, or a question, and transform it to a “known known”, or an answer.

“Where is time spent in this process?” we might ask. A pie chart provides a simple answer. However, it doesn’t tell much of a story. If we want to engage people in process of gaining certainty, if we want to make the story broader and deeper, we need to visually exploit a narrative thread. Find a story that will appeal to your audience and demonstrate why they should care about this knowledge, then use the narrative to drive the visual display of data. Maybe we emphasise the timeliness by displaying the pie chart on a stopwatch, or maybe we illustrate what is done at each stage to provide clues for improvement. (NB. Always exercise taste and discretion in creating narrative visualisations, or they may be counter-productive.)

Here is a brilliant and often cited narrative visualisation telling a powerful story about drone strikes in Pakistan.

Drones Visualisation
Screen shot of Pitch Interactive Drones Visualisation

The story also provides a sanity check for your analysis – is the story coherent, is it plausible? This helps us to avoid assigning meaning to spurious correlation (eg, ski accidents & bed-sheet strangulation), but do keep an open mind all the same.

Discovery Visualisation

But where do the questions to be answered come from? This is the process of discovery, and we can use visualisation to drive discovery.

Discovery Visualisation
Discovery Visualisation

Discovery can drive from low awareness, low certainty to high awareness, low certainty – from raw data to coherent questions. Discovery is where to start when you have “unknown unknowns”.

But how do you know you have “unknown unknowns”? Well, the short answer is: you do have them – that’s the thing about awareness. However, we’ll explore a longer answer too.

If someone drops a stack of new data in your lap (and I’m not suggesting that is best practice!), it’s pretty clear you need to spend some time discovering it, mapping out the landscape. However, when it’s data in a familiar context, the need for discovery may be less clear – don’t you already know the questions to be answered? We’ll come back to that question later.

A classic example of this kind of discovery can be found at Facebook Engineering, along with a great description of the process.

Facebook friends
Facebook friends visualisation

In discovery visualisation, we let the data lead, we slice and dice many different ways, we play with the presentation, we use data in as raw form as possible. We don’t presuppose any story. On our voyage of discovery, we need to hack through undergrowth to make headway and scale peaks for new vistas, and in that way allow the data to reveal its own story.

Inductive Drift

What if you’ve done your discovery and done your narration? You’re at “known knowns”, what more need you do?

If the world was linear, the answer would be “nothing”. We’d be done (ignoring the question of broader scope). The world is not linear, though. Natural systems have complex interactions and feedback cycles. Human systems, which we typically study, comprise agents with free will, imagination, and influence. What happens is that the real world changes, and we don’t notice.

We don’t notice because our thinking process is inductive. What that means is that our view of the world is based on an extrapolation of a very few observations, often made some time in the past. We also suffer from confirmation bias, which means we tend to downplay or ignore evidence which contradicts our view of the world. This combination makes it very hard to shift our superstitions beliefs. (The western belief that men had one less rib than women persisted until the 16th century CE due to the biblical story of Adam and Eve.)

So where does this leave us? It leaves us with knowledge of which we are certain, but unaware. These are the slippery “unknown knowns”, though I think a better term is biases.

Unlearning Visualisation

Unlearning visualisation is how we dispose of biases and embrace uncertainty once more. This is how we get to a state of “unknown unknowns”.

Unlearning Visualisation
Unlearning Visualisation

However, as above, unlearning is difficult, and may require overwhelming contradictory evidence to cross an “evidentiary threshold”. We must establish a “new normal” with visuals. This should be the primary concern of unlearning visualisation – to make “unknown unknowns” look like an attractive state.

Big data is particularly suited to unlearning, because we can – if we construct our visualisation right – present viewers with an overwhelming number of sample points.

Unlearning requires both data-following and story-telling approaches. If we take away one factually-based story viewers tell themselves about the world, we need to replace it with another.

Recap

Visualisation Cycle
Visualisation Cycle

Your approach to visualisation should be guided by your current state of knowledge:

  • If you don’t know what questions to ask, discovery visualisation will help you find key questions. In this case, you are moving from low awareness to high awareness of questions, from “unknown unknowns” to “known unknowns”.
  • If you are looking to answer questions and communicate effectively, narrative visualisation helps tell a story with data. In this case, you are moving from low certainty to high certainty, from “known unknowns” to “known knowns”.
  • If you have thought for some time that you know what you know and know it well, you may be suffering from inductive drift. In this case, use unlearning visualisation to establish a new phase of inquiry. In this case, you are moving from high certainty and awareness low certainty and awareness, returning to “unknown unknowns”.

Of course, it may be difficult to assess your current state of knowledge! You may have multiple states superimposed. You may only be able to establish where you were in hindsight, which isn’t very useful in the present. However, this framework can help to cut through some of the fog of analysis, providing a common language for productive conversations, and providing motivation to keep driving your visual knowledge cycles.

Playing Games is Serious Business

Simple game scenarios can produce the same outcomes as complex and large-scale business scenarios. Serious business games can therefore reduce risk and improve outcomes when launching and optimising services. Gamification also improves alignment and engagement across organisational functions.

This is a presentation on using games to understand and improve organisational design and service delivery, which I presented at the Curtin University Festival of Teaching and Learning.

(Don’t be concerned by what looks like a bomb-disposal robot in the background.)

The slides provide guidance on applying serious business games in your context.