Open Thinkering

Menu

Tag: strategy

TB871: Making strategy in difficult/messy situations

Note: this is a post reflecting on one of the modules of my MSc in Systems Thinking in Practice. You can see all of the related posts in this category


Clear systems thinking is one of the basic literacies of the modern world, not least because it offers unexpected insights that are not amenable to common sense.

Mulgan (1997)
Three blocks of texts with two arrows going to and from each:

"Ideas - including systems tools - for making change"

"Practitioners in the act of making change in complex situations"

"Situations of change and complexity"

The above influence diagram, taken from the module materials, illustrates the influences between the three factors of any human endeavour to make strategy:

  • Situation – comprising the arena of change and real-world complexities
  • Practitioners – people effecting change in the situation
  • Ideas – conceptual constructs developed by people for effecting change

I don’t usually find these kind of diagrams particularly useful, because it might as well be the bullet point list. You’re simply saying “take into account these things when doing X.” In this case, X is “making a strategy”.

Equally, I don’t find this kind of table particularly useful because it encourages the typologising of situations rather than understanding that everything is, and forever will be, on a spectrum:

Table comparing Perspectives (single/many) against Variables (few/many)

To that end, I’ve created my own alternative. I’m not sure the background works, but I was attempting to show the ‘one to many’ nature through overlapping grey triangles. Ah well, creating it helped me understand this a bit more:

But what is the difference between a ‘difficulty’ and a ‘mess’?

Issues of concern to us vary enormously in terms of their complexity and seriousness, from minor hiccups to near-catastrophe, and we can think of all issues falling somewhere on a continuum between minor and straightforward to very complex and crucial. We can label one end of the continuum as being a ‘difficulty’ and the other a ‘mess’ (the term coined by Ackoff 1974). We can distinguish between the
concept of a mess, and a difficulty, in several ways.

Messes usually have more serious implications; more people are likely to be involved; they include many interlocking aspects and may appear in different guises. As our three stories illustrate, messes usually have a longer time-scale; and they are often more complicated in terms of having many interdependent factors, than a difficulty. In addition to these broad characteristics there is a crucial difference between
a difficulty and a mess and that is the extent of uncertainty.

Reynolds & Holwell (2020, p.5)

It may be an act of hubris, but one thing that I think might contribute towards a meta-understanding of the systems thinking tradition is my work around ambiguity. We all have a tendency towards reduction and dogmatism, which is spectacularly unhelpful when it comes to systems thinking.

Continuum of ambiguity ranging from Generative Ambiguity, through Creative Ambiguity, Productive Ambiguity, and 'Dead Metaphors#

In the diagram above, this would mean approaches such as the following have the potential to become what philosopher Richard Rorty termed ‘dead metaphors’, no longer having any explanatory power:

  • Messes (Russell Ackoff)
  • Swamp (Donald Schön)
  • Wicked problems (Horst Rittel)
  • Resource dilemmas (Neils Röling)
  • VUCA (volatility, uncertainty, complexity, and ambiguity)

When a term is “literalized into language” (Reynolds, 2009), for example with business jargon, it is no longer conceptually useful as it likes connotative power. I think about this a lot when reading systems thinking literature, as there seem to be a lot of different approaches and traditions which are, in one way or another, trying to hover around the realm of ‘productive ambiguity’.

For more on this, see On the strategic uses of ambiguity.

References

  • Reynolds, A. (2009) ‘The Afterlife of Dead Metaphors: On Derrida’s Pragmatism / A sobrevida das metáforas mortas: sobre o pragmatismo de Derrida’, Revista de Letras, 49(2), pp. 181–195. Available at: https://www.jstor.org/stable/40542131 (Accessed: 3 May 2024).
  • Reynolds, M. and Holwell, S. (eds) (2020) Systems approaches to making change: a practical guide, 2nd edn. Milton Keynes: The Open University/London: Springer.

TB871: Different uses of the words ‘Strategy’ and ‘System’

Note: this is a post reflecting on one of the modules of my MSc in Systems Thinking in Practice. You can see all of the related posts in this category


Activity 1.1 is to complete the following:

Make some brief notes, and perhaps drawings, in your journal on what the words ‘strategy’ and ‘systems’ mean to you. Do this as a brief brainstorming exercise, noting down any word associations or images that come to mind in relation to each term.

After jotting down a few ideas, I used GPT-4 as a thought partner along with Whimsical to separate this out into two mindmaps with themes, sub-themes, and examples.

Strategy

Different examples of the use of 'strategy' broken down by theme (e.g. business, military, games) and then by sub-theme, with examples

System

Different examples of the use of 'system' broken down by theme (e.g. computing, biology, society) and then by sub-theme, with examples

Example from course authors

Once I’d done this, I then pressed ‘reveal discussion’ in the module pages and saw what the course authors had created as an example:

Spray diagram showing thoughts around definitions of 'strategy' and 'systems'

It turns out I approached this from a ‘noun’ rather than ‘verb’ perspective. If I was going to do this again, I’d definitely add a temporal dimension.

The course authors go on to mention that there are two prevalent views of systems in modern industrial societies. One sees systems as real-world entities with a degree of autonomy or as forces opposing human efforts, like the ‘health system’ or ‘legal system’. This perspective treats systems as independent and engineerable (i.e. reified). The other view is to see systems not as physical entities but as conceptual tools to help us understand and manage various situations. With systems thinking we are, of course, interested in the latter view.

Some thoughts and recommendations on the future of the Open Badges backpack and community

Recommendation Theater

Intro

Back in January of this year, Mozilla announced a ‘continued commitment’ to, but smaller role in, the Open Badges ecosystem. That was as expected: a couple of years ago Mozilla and the MacArthur Foundation had already spun out a non-profit in the form of the Badge Alliance.

That Mozilla post included this paragraph:

We will also reconsider the role of the Badge Backpack. Mozilla will continue to host user data in the Backpack, and ensure that data is appropriately protected. But the Backpack was never intended to be the central hub for Open Badges — it was a prototype, and the hope has forever been a more federated and user-controlled model. Getting there will take time: the Backpack houses user data, and privacy and security are paramount to Mozilla. We need to get the next iteration of Backpack just right. We are seeking a capable person to help facilitate this effort and participate in the badges technical community. Of course, we welcome code contributions to the Backpack; a great example is the work done by DigitalMe.

Last month, digitalme subsequently announced they have a contract with Mozilla to work on both the Open Badges backpack and wider technical infrastructure. As Kerri Lemoie pointed out late last year, there’s no-one at Mozilla working on Open Badges right now. However, that’s a feature rather than a bug; the ecosystem in the hands of the community, where it belongs.

Tim Riches, CEO of digitalme, states that their first priority will be to jettison the no-longer-supported Mozilla Persona authentication system used for the Open Badges backpack:To improve user experience across web and mobile devices our first action will be to replace Persona with Passport.js. This will also provide us with the flexibility to enable user to login with other identity providers in the future such as Twitter, Linkedin and Facebook. We will also be improving stability and updating the code base.

In addition, digitalme are looking at how the backpack can be improved from a user point of view:

“We will be reviewing additional requirements for the backpack and technical infrastructure gathered from user research at MozFest supported by The Nominet Trust in the UK, to create a roadmap for further development, working closely with colleagues from Badge Alliance.

Some of the technical work was outlined at the beginning of the year by Nate Otto, Director of the Badge Alliance. On that roadmap is “Federated Backpack Protocol: Near and Long-term Solutions”. As the paragraph from the Mozilla post notes, federation is something that’s been promised for so long — at least the last four years.

Federation is technically complex. In fact, even explaining it is difficult. The example I usually give is around the way email works. When you send an email, you don’t have to think about which provider the recipient uses (e.g. Outlook365, GMail, Fastmail, etc.) as it all just works. Data is moved around the internet leading to the intended person receiving a message from you.

The email analogy breaks down a bit if you push it too hard, but in the Open Badges landscape, the notion of federation is crucial. It allows badge recipients to store their badges wherever they choose. At the moment, we’ve effectively got interoperable silos; there’s no easy way for users to move their badges between platforms elsewhere.

As Nate mentions in another post, building a distributed system is hard not just because of technical considerations, but because it involves co-ordinating multiple people and organisations.

It is much harder to build a distributed ecosystem than a centralized one, but it is in this distributed ecosystem, with foundational players like Mozilla playing a part, that we will build a sustainable and powerful ecosystem of learning recognition that reflects the values of the Web.

 

Tech suggestions

I’m delighted that there’s some very smart and committed people working on the technical side of the Open Badges ecosystem. For example, yesterday’s community call (which unfortunately I couldn’t make) resurrected the ‘tech panel’. One thing that’s really important is to ensure that the *user experience* across the Open Badges ecosystem is unambiguous; people who have earned badges need to know where they’re putting them and why. At the moment, we’ve got three services wrapped up together in badge issuing platforms such as Open Badge Academy:

OBA venn diagram

One step towards federation would be to unpick these three aspects on the ecosystem level. For example, providing an ‘evidence store‘ could be something that all badge platforms buy into. This would help avoid problems around evidence disappearing if a badge provider goes out of business (as Achievery did last year).

A second step towards federation would be for the default (Mozilla/Badge Alliance) badge backpack to act as a conduit to move badges between systems. Every badge issuing platform could/should have a ‘store in backpack’ feature. If we re-interpret the ‘badge backpack’ metaphor as being a place where you securely store (but don’t necessarily display) your badges this would encourage providers to compete on badge display.

The third step towards federation is badge discoverability. Numbers are hard to come by within the Open Badges ecosystem as the specification was explicitly developed to put learners in control. Coupled with Mozilla’s (valid) concerns around security and privacy, it’s difficult both to get statistics around Open Badges and discover relevant badges. Although Credmos is having a go at the latter, more could be done on the ecosystem level. Hopefully this should be solved with the move to Linked Data in version 2.0 of the specification.

Community suggestions

While I’m limited on the technical contributions I can make to the Badge Alliance, something I’m committed to is helping the community move forward in new and interesting ways. Although Nate wrote a community plan back in March, I still think we can do better in helping those new to the ecosystem. Funnelling people into a Slack channel leads to tumbleweeds, by and large. As I mentioned on a recent community call, I’d like to see an instance of Discourse which would build knowledge base and place for the community to interact in more more targeted ways that the blunt instrument that is the Open Badges Google Group.

Something which is, to my mind, greatly missed in the Open Badges ecosystem, is the role that Jade Forester played in curating links and updates for the community via the (now defunct) Open Badges blog. Since she moved on from Mozilla and the Badge Alliance, that weekly pulse has been sorely lacking. I’d like to see some of the advice in the Community Building Guide being followed. In fact, Telescope (the free and Open Source tool it’s written about) might be a good crowdsourced solution.

Finally, I’d like to see a return of working groups. While I know that technically anyone can set one up any time and receive the blessing of the Badge Alliance, we should find ways to either resurrect or create new ones. Open Badges is a little bit too biased towards (U.S.) formal education at the moment.

Conclusion

The Badge Alliance community needs to be more strategic and mindful about how we interact going forwards. The ways that we’ve done things up until now have worked to get us here, but they’re not necessarily what we need to ‘cross the chasm’ and take Open Badges (even more) mainstream.

I’m pleased that Tim Cook is now providing some strategic direction for the Badge Alliance beyond the technical side of things. I’m confident that we can continue to keep up the momentum we’ve generated over the last few years, as well as continue to evolve to meet the needs of users at every point of the technology adoption curve.

Image CC BY-NC Thomas Hawk

css.php