Production Facilitation

I had an interesting chat with Dirk Slater from Fabriders yesterday. It was a live online interview/discussion about the work I’ve done since FLOSS Manuals which I started 10 years ago.

Here are a few points I want to distill out from my experience evolving the Book Sprints, the Cabbage Tree Method, Workflow Sprints and others…

Production Oriented Facilitation is not the same as ‘unconf’ Facilitation
I like to differentiate facilitation of processes that produce products over a fixed timeline (books, software, workflow designs) from the typical kind of facilitation related to unconfs (etc). They are not the same thing, the former employs some of the tools of the later but also has tools of its own. Importantly, if you bring a (dare I call it ‘too respectful’) unconf tone to a production processes, you won’t get anything done. So don’t expect because you can do unconfs, that you have the tools and right approach to facilitate production processes. Mistaking one for the other is a category mistake.
Remote Facilitation doesn’t work
Facilitation of production events of the type that enjoys radical efficiencies like Book Sprints is not something you want to do remotely. You can’t get the same attention and commitment. Nor can you get the ‘full spectrum’ communication between all members of the group that you need if you are working remotely. At Book Sprints we believe this so much to be the case we don’t like to have even one person working remote.
Not everyone is a facilitator
Facilitation is one of those skills that people think they can ‘just do’. Doesn’t need any ramp-up time or experience, its just someone telling everyone else what to do in a ‘nice way’ right?… I have seen this time and time again. If you think like this, thinking you can facilitate with no experience, then you are at a bad starting point because it is clear you don’t know what facilitation is. Don’t experiment on your friends, family, or colleagues if this sounds like you.
Good facilitation can only be learned by experience
Experience is the only way to learn to be a facilitator. You can’t learn it from a book. So how do you learn? By apprenticeship. Find a mentor that can take you through the process in situ. It is the only way. Don’t expect it to be a quick process.
Technology is not the answer
So many times I have people ask me what tools Book Sprints uses. What is the software? It is not asked from the position of trying to make sense of the ecology of items that are needed as tools, it is asked in the Silicon Valley sense of ‘software solves everything’. Book Sprints is not about the software. Its about the methodology and the facilitation. We could do Book Sprints without the tech we use (and we have in the past). But if you believe you just need to install the software and stand back and watch the magic happen, then you are wasting your time. Sure the software helps us run things smoothly, but it does not automagically ‘provide’ a Book Sprint.
Don’t put people in a room and expect it to work
In the case of Book Sprints I have seen many orgs try and emulate it by just putting a whole bunch of people in the same room and expecting the magic to happen. If you have tried this, I know you have failed. It doesn’t work and you are missing the point. It’s all about the facilitation.
A method is a compass, not a religion
Facilitation methodologies are not religious texts that must be followed to the letter. Unfortunately that is how too many book-learning facilitation courses approach facilitation. It’s very sad to see. Methods are instead merely navigational instruments. However, they are useless in the hands of someone that does not know how to use them. You need to be an experienced facilitator, with experience of that particular method, for everything to work. A facilitator who is experienced with a particular method and knows how to use it will not only be amazingly good, they will also know when the method doesn’t give them what they need, and how to improvise towards true north.

And as a last coda, a note on who makes a good facilitator… I do believe some people, through a combination of nature and nurture, will make excellent facilitators, while others should really not even attempt it. I must say that this is a very hard thing to determine before training someone. I have some clues as to what qualities may contribute to being a great facilitator but it’s still largely a mystery to me. You never really know it until you see it, which is why I prefer to train people with the option of stopping if I can see it won’t work out.

I will say however, that I have found that most unconf facilitators do not make good ‘production’ facilitators. My best attempt to understand this hasn’t got me very far, although I’d say it has something to do with the two processes looking like they overlap a great deal, but in reality they overlap less than you imagine. Consequently the internal rationale and ’emotional position’ you take, as well as the facilitation tools and tricks, don’t actually transfer, and, worse, will probably lead you in entirely the wrong direction. You need to be rewired, and I haven’t seen this work (yet). This my best take on it and is purely anecdotal – garnered from training several people who knew how to facilitate unconfs only to abandon the effort to facilitate production part way through. I can’t entirely explain it, but there you are – take it for what it’s worth.

Mapping Workflows

One of the things I do a lot, is help people think through their workflows and how to optimise them. We do this for all kinds of projects – book workflows, journals, micropubs, pre-print services etc prior to developing a software with them that will help them do what they do better, enable efficiencies, while leaving the door open for continual optimisation of how they work and for possible future transformations of how they work. Drawing from my 10 or so years of facilitation experience I facilitate these processes, and Kristen, drawing from her 20+ years in publishing, is ’embedded’ in the group to be part of the conversation and foster discussion and ideas from ‘within’ the group. We make a pretty good combo.

To do this we must help people ‘think in web-based workflows’. While most journal platforms out there are accessible via the browser they are not what I would call ‘web-based’. They take no advantage of what a networked digital environment can enable. Instead, the web is used as a common way to access what are, primarily, cumbersome database ‘ledger’ systems where workflow is tracked more than it is enabled. Books are even more interesting in that book production staff primarily work directly on the file system with MS Word files. There is little proof the web exists in many publisher’s book production workflows except that they use the network to email collections of files to each other.

So, how do we get people whose primary work environment is anything but the web, to start thinking about how they might work in the web? Well, we essentially follow 3 stages:

document the current workflow
discuss an ‘optimum’ workflow
map this workflow into browser views (we call them ‘collaborative spaces’ or, more commonly, ‘spaces’)

Each of these steps takes several hours. We allow minimum one day for the entire process detailed below. 1.5 – days would make it more comfortable.

Document the Current Workflow

It is important to start the process with all major stakeholders in the same room. Clear out a few hours, or a day, and bring along a lot of paper, post-its, pens and, preferably, some large whiteboards.

Talking through the Journal of Creative Technologies workflow (Auckland, NZ)

It is important to make sure all the major stakeholders are there (or representatives if some groups are large) because when you go through the current workflow you will discover that no one in the room knows the whole story. It is also often true that the organisers of the event have some fundamental assumptions about the workflow that are wrong, and that most people do not understand the knock-on effect of their actions on a co-worker’s job. All this is important to reveal through discussion, while ignoring the claim that ‘we all know what each other does’ – I haven’t ever found this to be the case so far.

This discussion should start right at the very beginning of the workflow. In the case of a Journal Manuscript Submission System, for example, the process usually starts with an author with a manuscript that they wish to submit. That is your starting point. Make sure you really do identify where it all starts as most people will tend to suggest that the early stages are known and understood and simple and consequently they may try to skip this part or deal with it superficially. But your job is to have a discussion that covers the entire workflow and get exact details of what happens, by whom, and when. So keep asking really annoying pedantic questions to get to the clarity you need. Don’t let assumptions leave anything uncovered – I have often found that items everyone assumes are understood reveal hidden, not widely understood, processes when the right, very straightforward, clarifying questions are asked. For this process, you will have to get over your fear of looking stupid! Ask as many pedantic clarifying questions as possible.

Work through the workflow step by step from start to finish. As you do this, document it clearly – a shared large space (eg whiteboard) is best. As you draw it, ask for affirmations that it is correct. Work through all the eddies and conditional forks in the workflow to their conclusion and document them. In the end, make sure you summarise this in one simple document. Theexample below is a document from the Journal of Creative Technologies workflow discussion.

This is a useful process for exposing the actual (vs assumed) workflow to all players, stimulating ideas on how things could be better, and creating a ‘source of truth’ for the current workflow (people often forget details down the road).

While this part of the process is good for raising ideas on how things could be better, don’t let the group get stuck in the future weeds. Planning an optimum workflow comes next and if you let them stray too far into future thinking, they will either not finish documenting the current workflow, or they will confuse how things are now with how they want things to be. But don’t entirely kill these ‘future thinking’ moments either – let them be aired but if it looks like they are going to evolve into deep, nuanced, discussion of one part of the workflow and how it could be improved, then move discussion along. Also, make sure that all people are paying attention through this entire process. Don’t allow side conversations as these take those participants out of the wider discussion as well as distracting everyone else.

Discuss an Optimum Workflow

Next, we lead the group through an open-ended ‘pie in the sky’ discussion about possible utopian workflow futures. We start this discussion very broad – asking anyone to jump in with an idea. The discussion starts broad and we allow it to roam around a little. Often throughout this process, we are taking note of where there is agreement or ‘energy’ around a given idea or approach.

Sometimes people whiteboard ideas but most of the time it is pure discussion.

l1030128 — Discussing workflow possibilities with Collabra Pyschology Jourmal

After a while, perhaps 30 mins, maybe more than an hour, we start bringing back some of the ideas into the discussion that we know the group was interested in and ask them to expand it together. Sometimes we drop in small hints that a particular idea might be a good one but is technically unfeasible – this starts to give the group a sense of what is possible, or what might be technically achievable in the short, medium, or long term. It’s important not to squash ideas as soon as they emerge but to ‘sober them up’ if they get too fantastical. A little bit of realism doesn’t hurt at this stage but, more importantly, you want to get the ideas flowing. Nothing is nailed down or committed to at this point, it’s just exploration and discussion.

Mapping

Now we get to mapping these ideas onto a web-based platform. The group is going to engage in systems design without knowing they are doing so. We do this by first explaining a little about the web – some of the things that are possible. We might show some examples of sophisticated web-based editors like Wax, or in-browser pagination using Vivliostyle. Perhaps we might look at Trello/wekan or kanban examples of workflow management. We might look at Stencil.a or any number of examples of interesting platforms and approaches the web can offer.

We also talk about the efficiences of the web and how that is enabled – mostly this comes down to unpacking why a single-sourced content environment is so powerful, why ‘everyone working on the same object’ is important, how collaboration and concurrency can change the way we do things. As well as preparing them for the idea of designing a new system that is native to the web, we are introducing some new ideas that might reshape how they think about how they work. Why, for example, do we email MS Word files around when we can simply all see the same document, at the same time, in the browser?…these ideas will mean different things to different groups and how they play with them depends on how ready they are to explore new possibilities, combined with how much of their ‘old ways’ they are prepared to let go, plus how much they understand about the web. So it is important to let this conversation go at its own pace across whatever topics the group feels they need to explore. It is important that the discussion evolves of its own accord from the ideas introduced. We ‘shape’ the conversation, point it in a certain direction and signpost with certain interesting examples, rather than provide a soliloquy or monologue about how we would like things to be done. This is important, because unless the group internalises these ideas, they won’t end up exploring them when it comes to design time.

Next, we give a little rundown about ‘thinking in collaborative spaces’. Basically what we are trying to do is to take some of the ideas that emerged in the ‘optimal workflow’ discussion and start prompting them to think how this might be realised ‘inside the browser’. Most commonly we can do this by talking about very concrete things like browser windows, which everyone knows, and asking ‘how could this part of the workflow happen in a browser window?’ For example, in a journal system, we might ask ‘how might submission happen for an author in a browser window’? As a starter example, we could discuss this and draw a box on a whiteboard and draw some basic ‘UI’ elements in that box. This makes everything very very concrete. You are reducing systems design to something they understand without them realising that they are about to start designing a system.

The next step can take several directions, but the most common is that we split the group into smaller groups. 4 or 5 to a group is usually a good number. We then give them large sheets of paper and a bunch of thick pens, and send them to acoustically separated spaces to draw up proposals for ‘several spaces’ that would represent the workflow in the browser. The time we give them depends on the time at hand. You want more than 15 mins, but 45 is probably too long. Sometimes we might also ask them just to focus one one part of the workflow, usually the first part (however you design this is up to you).

l1030400 — Erich van Rijn (UCPress) pitching some ideas to the group while Dan Morgan (Collabra) documents, and Paul Shannon (eLife), and Yannis Barlas (Coko) listen.

It is very important when you send them away to do this that you ask them to draw the interfaces. One big page of paper, for example, per ‘space’ (browser window). If you don’t do this some groups, especially those used to writing requirements docs, will write lists. The problem with that is that these lists don’t tend to be scoped or connected very well. They just turn into a list with as many items relevant to (for example) ‘submission’ as you can imagine. Better is if they draw the spaces as if it was a browser window, putting in UI elements with basic drawing.

Oliver Buchtala (Substance.io) holding up his group’s proposal at Erudit, Montreal.

No one has to be an artist, it just needs to be a rough proposal of what that space would enable, and one most people will understand if they were just to look at it.

l1030396 — John Chodacki (CDL) puts some finishing touches on a proposal he designed together with Andrew Smeall (Hindawi), and Jure Triglav (Coko).

We circle around and make sure everyone is getting on with the task and in good time. At the end, we bring everyone back into the room and ask them to present their proposals to the rest of the group.

l1030423 — Lia Schiff (CDL) presenting a proposal to the rest of the group.

We give them a short amount of time to make the presentations. Perhaps 10 mins, more if the scope of the workflow is larger.

What you will be surprised at, I can guarantee it, is that all the proposals are *great* AND they will all be very similar. We have done this many times and the results of each group are rarely very far apart. When they are far apart, it’s usually because a group has locked onto one idea or another as a starting point and designed everything around that. These ideas usually have something very worthwhile that can be combined with the other proposals to improve them.

As each group finishes presenting a space or group of spaces we ask the group for questions or comments. We don’t let this go too deep into the weeds as time is tight at this point, but some discussion is always useful.

Another proposal at the Erudit workshop.

Then at the end, you discuss these approaches and agree on a common approach. We call this an ‘architecture’ which it is to an extent. It is the bird’s-eye view of how their new workflow will fit snugly into a browser based workflow. The following being an early ‘architecture’ or high-level systems view of a journal platform for Collabra.

Handily each of these new spaces can then be built as a PubSweet component! The following is the architecture showing the components we need to design and build – this diagram was the result from early sessions with the staff from UCP I facilitated to produce the Editoria monograph production platform.

This process is a very specific description of the first part of the Cabbage Tree Method. The second part of the Cabbage Tree Method involves facilitating the design of each of these components.

Thoughts on Facilitation

I’ve been sitting on the beach trying to not think about work, which means of course I thought about work…. but in the way where clearing the mind brings up new insights almost ‘out of the blue’. It happens to me a lot when I get away, which is why I sometimes do my best thinking on trains, or at the beach.

I have been pondering facilitation. So here are a few thoughts. The following is very much a sort of scratch pad of ideas / stream of consciousness. I’ll put structure to it and flesh it out later.

First, I have been pondering what makes a good facilitator. How do you know when someone might be good at this. I think there are 2 personal characteristics that might seem contradictory but are essential:

they are very open
they are very controlling

The second one sounds bad I know. I will work out a better way to state this. But in my experience every good facilitator I know is in some way a bit of a control freak. They are also very (very) open. That might seem like a difficult mix to get right – it is! Which is why I’m kinda leaning towards this theory because I have trained several facilitators and the ones that don’t make it don’t strongly represent simultaneously in these 2 categories.

Second, pretentiousness or a ‘high minded’ attitude *does not cut it*. I say this because you can have the above two characteristics right but I’ve seen this attached to a much removed holier than thou attitude and that is the worst. No good facilitator is above the fray in this way.

Ok.. I was about to break out in a rant there… phew…

Alrighty…

Next the facilitator’s role – what is the facilitators job? I see it as this. The facilitator’s role is to maintain process and to pass decisions to the participants over substance.

Sounds simple. But in no way is this simple. To maintain process the facilitator needs to find ways for the group to invest in an artificial culture that is born on the spot. The rules of that culture are almost completely evoked and maintained by the facilitator. This small little bubble, or micro universe with its own rationale and rules, is what the facilitator instantiates and maintains. It more or less comes down to these two things:

methodology (more important than you think, but also not nearly as important as you think).
shaping human dynamics

In other words, your job is to manage what is done (methodology eg. the Book Sprint Methodology), and how it gets done (shaping the internal behaviors).

I think number two is the hardest to master since you can’t be good at any methodology unless you know how to shape human dynamics. And this is all about who you are and finding your own voice as a facilitator. There are so many tricks and techniques here I don’t even know where to start. Maybe a subject for other posts. But what I’d like to point out is that these two things put together equal process. Facilitators manage process so the participants can focus on the substance of what it is they are deciding/creating etc.

I say this because sitting on the beach has made me aware of one of the biggest issues with facilitation that I have experienced. When I used to facilitate Book Sprints I used to ponder why it was that Humanities academics and facilitators were the hardest people to facilitate. Also, in other Book Sprints, staff documentation writers would often prove difficult when I did Book Sprints that focused on documentation. Ponder ponder… now I think I sorta see it. It is because these groups have a strong opinion on process. Academics are experienced in writing books, so they believe they know how books are written. You come at them with something else, another way of doing it, and many of them just flatly freak out. I had one academic who literally said “you can’t just make up how you make books”. That was a pretty extreme example. I was able to bring her round but it was hard work. Facilitators also think they know facilitation process, so you involve them in something new and they almost always think they can see better ways to do it. They are almost always wrong (mainly because no path works the same for any two facilitators because of the need for each and every facilitator, in themselves, to be the instantiation for a temporary, micro, but very real culture). . Same with documentation writers… involve them in a doc sprint and you might very well be asking for trouble.

It is the facilitator’s job to bring the process to the people. If the people are domain experts (ie. know a lot about the topic) then no sweat, they will usually get in there quickly and invest in the mini culture you lay down. But if the participants have opinions on the process you get into all sorts of trouble.

So, that means there are two categories of people that need to be kept in mind:

domain experts – good to go, you should be able to get them inside of the bubble no problems
process experTs – spelled with a capital T for Trouble 🙂

Ok…. so I want to say one last thing before I go practice falling off a surf board inelegantly. There is a group of people that are also difficult to keep inside this bubble. They are, for want of a better word, the ‘power retainers’. These are people that either hold sway with the group because of their massive cultural capital (eg the elder states-person in a sector, or they are the boss), or they have such big egos they think they know whats best (usually they also don’t know when to shut up).

There are three possible ways these people can go:

they give the power away – they step back and let other people in, are careful not to dominate, they get in there shoulder to shoulder with others, really listen, go with the flow
you coach the power away – this can be exhausting, but it works more often than not and when it does it can be dramatic. I’ve seen people swing around from being destructively blocking to being the biggest advocates of the process within a day.
they don’t give it up – i have rarely seen this. Interestingly the two examples that come to mind have been Ministers (I won’t name the country or position!). The way they avoided ‘being one of the people’ was just to disappear from the process entirely. Maybe that’s their job – professional avoiders (hoho). Sigh.

I have to say, when I see people migrate from 2 -> 1 (above) they do nothing but earn my utmost respect. That is humility and human connectedness at its best right there.

But if someone is stuck on 3… that is really trouble and you might need to ask them outside for a talking to. In the past I have threatened to remove them from the process. That’s a tough tough call right there, but you have to get the rest of the group to where they need to be in the time they have. If you don’t make these tough calls you won’t make it. I have, by the way, only had to sideline people for a while. I’ve never had to remove anyone and I even had one elder statesman front up the next day and apologize to me and recognise why things had to flow the way they had to flow. That dude earned a place in my heart forever.

Anyways…back to the beach 🙂 ….

The invisible skill

I do a lot of facilitation and I’m very good at it. I don’t know how I came to be a facilitator exactly, it’s not the sort of thing I think you go to school to learn. It just somehow comes out of you bit by bit on a road to achieving something else entirely. In my case, I think it came about while trying to build FLOSS Manuals (a community that produces free manuals about free software). FLOSS Manuals (FM) needed content, and I realised that it was not going to happen at the scale needed if I wrote it all myself. So I had to learn to build community and building community requires facilitation (even if you don’t know it at the time).

floss-manuals-openmind-4-728

Anyway, long story short, I became a facilitator the hard way – by not knowing that it was facilitation that I was doing. I had no context. ‘How you get things done’ in the world seemed to be all about the doing of those things. If you want to write software manuals, for example, you wrote manuals. That is what publishers and author, editors etc did. Who ever heard of facilitation in the context? No one that I could find.

So it took me a while to even realise that facilitation could play a role in making manuals (books) and I only had that realisation after I first tried it the publishing industry’s way and failed. It’s even fair to say that I had no understanding that facilitation could have a role in helping people to make books until I had been facilitating people to make books for many years. I was that blind to the idea. Instead, I had this strange, slowly evolving awareness that somehow when I got people in a room and I was there also, then books resulted. It seemed like it was the participants that ‘were doing it’ and, bizarrely, every time we did it, it worked, every time we did it it was better than the last time, and I happened to be there to witness it.

8004_11

It took me some time to work out that this result was because of the role I played. It took a very very long time – I would say, possibly, 2-3 years. The awareness didn’t come in one shot either. I first thought it must be the process that made it work. So I started trying some stuff out. I remember very strongly thinking that there was this process that actually existed, like publishing processes exist, and that it was concrete and tangible, but it was just that it was unknown. As seriously kooky as that might sound, that’s how I thought of it at the time. I felt I was discovering something that pre-existed, some process that just needed to be revealed.

Then, slowly, after Book Sprints were really kicking ass and producing remarkable books I’d have thoughts like ‘I wonder how important this process is?’ I wonder if it might actually be me that is the most important ingredient. Not me in an egoist way, like Adam Hyde is the only person that can do this (interestingly, other people thought this might be the case!), but maybe that it is not so much the process but what I am doing that is making this work.

7917_01

So comes the understanding of the extremely interesting and tangled relationship between facilitation and method. I spent many years untangling it and now I think I have a 1.0 understanding. Like, at the school of facilitation if you get this idea, then you are actually allowed to call yourself a facilitator…. it is that basic, and that central to what facilitation is. My un-battle-hardened synopsis is this series of truths might seem a little contradictory: a good facilitator is better with a good methodology. A good methodology is nothing without a good facilitator. And a good methodology to a good facilitator is nothing but an interesting yet weak navigational instrument.

Anyhow. My sum of this is that I often get people telling me they would be a good facilitator for this or that, or that they would be if they had the opportunity. I also see a world where methodology is seen as king, you just need to read it and follow it to the letter and you’ll be sweet! I can’t blame people for this. How could I when it took me so long to understand that facilitation was a thing? I can’t blame people when they think it’s something anyone can do. But of course, I do find it frustrating. I’m no saint! But after many many years of practice and experimentation, pondering, trying things out when I was terrified they would fail, failing, succeeding, mentoring others to do it well, exploring the weird psychology of it all, seeing others do it so very badly – I can now say I know what facilitation is and how special it is to be able to do well this invisible skill that so many do not know even exists.

16312812953_10cda14f90_b

What is the Cabbage Tree Method

Another chapter from the forthcoming book

WHAT IS THE CABBAGE TREE METHOD?

Imagine a bunch of people in a room, all sitting around a table. There are some whiteboards in the room, and coffee, sticky notes, and maybe even a data projector, litter a table. All of those people, except one, share a common problem and they want to create new software to solve it.

But where do they start? There are no developers here … what’s going on? One of them, the facilitator, steps up and initiates a short period of introductions and then asks the question “What is the problem?”

From this, a process unfolds where the people who need this new software (let’s call them the use case specialists) explain all their frustrations with the ways things are done now and what could be better. It is a wide-ranging discussion and everyone is involved. At the facilitator’s prompting, someone jumps up and draws a straggly diagram of a workflow on one of the whiteboards to get their point across. Another pipes up to add nuance to one part of the diagram because they fear the point wasn’t adequately understood. There are some quiet moments, some discussion, lots of laughter, a break for lunch. Plenty of coffee.

Throughout the day, the group somehow (the facilitator knows exactly how) evolves their discussion from big picture problems and ideas to a moment where they are ready to start designing some solution proposals. The facilitator breaks them into small groups and each group has 45 minutes to come up with a solution. When they come back, each group presents their ideas. Some of the ideas are very conceptual, almost poetic. Other ideas are very concrete and diagrammatic. Everyone thinks carefully about the merits of each proposal and what it is trying to say. Discussion ensues. Members of the group ask clarifying questions. After all the proposals are made, they decide on an approach.

In a short time, they have agreed on a set of requirements for software that they have consensus on and all believe will solve (at least some of) their problems. They take photos of all the whiteboard diagrams and document the design agreements thoroughly, creating a Design Brief. At the end of the day, they walk out the door and the design session is over.

The next day the Build Team, featuring user interface (UI), user experience (UX), and code specialists, looks over the documentation with the facilitator through remote conferencing. They discuss the brief, what is clearly defined and what is still to be defined. They work through the issues together, jamming out approaches to open-ended questions which are both technical and feature-focused. The session is not long, perhaps two hours. It’s a lot of fun. From this session, the Design Brief is updated with the decisions. Many technical solutions are left wide open for the code specialists to think through and solve over the next weeks. However, the code specialists can, and do, start work immediately, though the UI/UX specialists add mockups to the documents over the next days. The team works things out on the fly where necessary and gets onto it. Over the next weeks, a few questions to the use case specialists surface – these are either asked directly or through the facilitator.

The use case specialists reconvene six weeks later with the facilitator and are presented with the working code that has been created by the build team over that period. Everyone is amazed. It’s just as they imagined, only better! After seeing the working code, they each have further, exciting, insights into how this problem might be solved. The facilitator steps up and they go through it all again to design the next part of the solution. Everyone is bursting to have their say.

The design-build cycle is repeated until they are done and the software is in production.

This is the Cabbage Tree Method.

The Cabbage Tree Method (CTM, for short) is a new way to create open source software products. With CTM, the people who will use the software drive its design and development under the guidance of a facilitator. It’s a strongly-facilitated method that generates and requires immersive collaboration.

You can think of CTM as a new branch on the Systems Development Life Cycle (SDLC for short) tree. Some popular SDLC methods include Spiral, Joint Application Design, Xtreme Programming, and Scrum (some of which conform to the values of the Agile Manifesto – see http://agilemanifesto.org/ for details).

Unlike the various SDLC methods, CTM is specifically aimed at the free software/open source sector. In that sector, the cultural rules are quite different from environments where teams are employed to work within a more formal business or corporate structure. However, CTM differs from open source processes that have embraced developer-centric solution models, thanks to its focus on users designing the software with a facilitator as an enabling agent.

What also sets CTM apart from other methods of developing software, is that it doesn’t have:

personas
avatars
User Validations
user stories
empathy boards (etc)
‘experts’ designing the solution for the user

This process isn’t about development procedures that represent the user at a distance. It’s about communicating and collaborating with the user at the center of the process. It’s not a question of profiling a so-called user, or turning them into an avatar or proposition, or trying to generate empathy with them from afar. Rather, a core requirement of CTM is to directly involve in the design process everyone who will use the system. The idea is that if you want to know what the user wants, don’t imagine their response. Ask them.

THE CYCLES OF CTM

ctmcycle_lines

Like most modern SDLC methods, CTM is iterative and has clear cycles. Each cycle consists of a Design Session followed immediately by a Build Period. These cycles repeat (design, build, design, build, design, build etc) until the solution is complete.

DESIGN SESSIONS

The specialists most in demand for the Design Sessions are the use case specialists – the users themselves. The Design Sessions are always in person – they don’t work well with remote participation. Each design session can be as short as two hours, or as long as one day.

The general principle of the Design Sessions is that all users affected by the software must be present at the appropriate moment – either in total or as a representative group. Without their presence, a solution cannot be developed. A fundamental rule of CTM is that no one speaks for the users other than the users themselves.

From each Design Session, a short brief is created that describes what has been agreed to, what is absolutely required to be done in the following build period, and what is left to be solved during the build period.

BUILD PERIOD

The Build Period takes place immediately after the Design Sessions. The build period can occur remotely and may take two to eight weeks, perhaps longer. Building is the job of the UI/UX and code specialists and it is here they can both be creative and exercise their User Interface (UI for short), User Experience (UX), and programming skills. Use case specialists don’t participate in the Build Period but may be consulted for clarification during this period.

Before the Build Period begins, each of the build team members receives for consideration the initial brief that was created during the Design Session. The Build Period then begins with a meeting where the code and UI specialists discuss the brief, decide on an approach, and together develop solutions for any outstanding issues. This may include solving some complex feature, technical, and usability problems – essentially working out how to achieve everything the users have already decided, plus designing what is left over. Then briefs are written and agreed upon, mocks done where necessary, and building begins.

On creating a methodology

The first 'real' Book Sprint. Inkscape, Paris, 2008. — The first ‘real’ Book Sprint. Inkscape, Paris, 2008.

Some years ago, I developed the Book Sprints methodology. It’s now pretty well defined and is being used very successfully to develop many books for all types of organisations. I am now working on another methodology – Collaborative Product Development. So, this time round, it’s sooo much easier and I thought perhaps I should write down some of the journey from zero to methodology. It will certainly help me to do so and maybe someone else out there will find it useful.

First of all, methodologies are odd things. Book Sprints is a methodology but, at the same time, I often wonder exactly what this means? I mean…you can’t just take a written template and turn it into a successful facilitated process. It just doesn’t work. The reason is because facilitation is a little, if you pardon the strange analogy, like administering the law. The law exists on paper but every time it is administered by a judge it is new. The context requires the law to be interpreted to enable it to be applied.

I think facilitation is like this. You can take a method and apply it but the context is everything. You must always make the application of the method new each time it is applied. Further, you need to extend it and break it when necessary and you have to do it effectively, other wise you break the process and, in the facilitation game, process is everything.

So…you must first be a facilitator to apply a facilitation methodology. Even then you can still screw it up. For example Book Sprints, and Collaborative Product Design, employ all the same skills that you need for ‘unconference’ facilitation plus more. The more is specifically the skills required to drive people effectively along a finite timeline to completion of the thing you are making. The need to drive product in this manner often freaks unconference purists out because you wield a lot of ‘do it now’ power else you will never get there. ‘Do it now’ power is only subtly used in unconferences, in product-driven facilitation you use it like a hammer.

Anyways… the point being that a methodology on paper is nothing. You need to define it, so out comes the pen and paper.

Defining a methodology is actually pretty strange and, in my experience, the newer the ideas in the methodology are to you, the longer it takes to define. Book Sprints, for example, took me about 4 years to work out and I only really knew it had a definition when I had to train someone else. CPD, on the other hand, took me a day to outline on paper. I’m still refining it but that’s normal, the body of CPD came into existence in one day-long session. What’s more, it appears to be working. The bits that are taking the longest to work out are the bits I haven’t experienced before. We haven’t taken a full product to market with CPD, so, consequently, the production implementation phase still needs to be tested and refined. The rest of it, however, seems pretty well constructed.

It took a long time for me to work out a method for Book Sprints. I was really just trying stuff completely blind. It didn’t start that way, as it happens. I first went to people in the publishing industry and asked them how I should do it. I figured they knew how to make books and surely they would have some ideas on how to make it faster. Hah. Was I ever wrong. My experience was that publishing people screwed up the process with their own process. Too much process. So I had to, finally, after a long period of angst, decide I was going to have to work this thing out myself. I didn’t want to do it. I didn’t even know what it was I was trying to do. So, sigh, I relented and proceeded to slug it out.

It was like slugging it out too. I mean, I had no experience in making books. I didn’t want to do anything I considered ‘publishing’. I have an aversion to cathedrals – which is what publishers looked like to me. A deeply institutionalised sect. So I had to actually learn to trust myself and do it my way. It was quite scary at first. I mean, I was inviting a bunch of people to come to some place to work for a week to develop a book using a methodology that actually didn’t exist. I didn’t have much idea what it might look like either. Geez… I must actually be pretty stubborn when I look back on it.

So I went about inviting people to Book Sprints and I challenged myself to trust myself. To listen to myself and observe. I came to understand that the only thing that could enable or prevent a successful Book Sprint was me. There was no other factor. That was pretty frightening at times. I spent many nights during Book Sprints completely terrified that I was about to send this nice group of people into an unproductive deep abyss. They might return from that dark hole but I was pretty sure I wouldn’t.

On this journey, however I had some starting points. I don’t know what triggered it but very early I came to understand that rapid book development of the kind that Book Sprints represents could not be about publishing processes – it was about unconference processes. Luckily I had a mentor, who had, for reasons unknown to me, taken me under his wing. At the time I didn’t know how lucky I was. That was Allen Gunn (Gunner). I had seen him in action many times as a facilitator and I had a few clues to a process. It wasn’t much but it was a start.

So I tried my hand at facilitation. I would, at the time, tell myself that Book Sprints were more about facilitation of people than the production of a book. To say so out loud sounded odd. It didn’t sound true. It sounded like I just made it up. But I kept saying it and trusting it. I kept challenging myself to trust myself. It wasn’t easy but as I became used to it, the process became easier.

Anyway, I still couldn’t call this thing a methodology. All I knew was that I was trying things out and formulating some kind of Book Sprints worldview. I think it’s fair to say the worldview was nothing I could articulate. I worked through gut and felt that everything was instinctual. However, I was learning useful tricks. For example, I remember Gunner saying he tried something new each time he facilitated an event. So I tried something new each time. I learned that if you failed with the something new, the trick was to make out like it was a success and, further, an expected success. This way I created a fallback framework that would allow me to experiment, to try and fail, to learn on the job and to get away with it.

So, I iterated forward. Rather slowly really. I mean, I had to convince people that this non-existent Book Sprint thing was not only possible, but they should do it, while I had little to point to as proof. Yeesh. Talk about a hard sell. But some people saw the possibilities and tried it out. I am forever grateful to Leslie Hawthorn who was working at Google Open Source Programs Office at the time. Leslie (introduced to me by Gunner) backed me and sponsored the first 3 Book Sprints. Amazing. I got something I could start with and that was critical. Later, with a few under my belt, it became easier to convince others.

So I did this for many years and felt I something taking shape. It was actually working. The books were getting better which seemed to indicate I was improving the process. I was starting to construct an embedded framework and the things I did were tested against it. It was filling out and becoming more consistent. I could finally start becoming a little more playful with the process. Still, when I started to talk about it as a method it was a query more than a statement. I wasn’t even sure what a methodology was. I wasn’t sure if Book Sprints was a method or even a stable set of practices. Others also said they same thing. David Berry and Michael Dieter, two good friends and critical theorists, would ask me what I thought it was. I had no idea how to articulate it. I asserted at time that it was a methodology but I wasn’t even sure I convinced myself.

A critical break through came when David and Michael (who had both been to 2 Book Sprints by this time) wrote a post about the process:
http://ausserhofer.net/2013/02/the-method-of-book-sprints/

I was amazed. They saw things that I didn’t. It was stunning to me. They had given me my own framework. From this point I started to construct a much better understanding of what I was doing.

The next step that finally defined the process was when I actually had to train someone to do it. I had other work offered to me (designing platforms) and I had a Book Sprints client base to keep happy. So I needed to scale. I needed me times 2. So I brought in Barbara Rühling (as introduced to me by Zara Rahman). It was at this moment, during a Book Sprint in Malta, and Barbaras first training session, that I started to make up a language to explain what a Book Sprint was. It flowed out of me like I knew it all along. I was very lucky in that Barbara trusted my narrative. It allowed me to expand notions as they came out of my mouth. I could define and refine a language and process as I spoke. It was fantastic and it was the final moment in the long process of defining a method. Hard won experiences were suddenly made salient and coherent though in situ explanation.

Now when I look at Book Sprints it appears pretty concrete. I laugh when people talk about it as if its a ‘known thing’. How can it be? I just made it up! 🙂 Of course, I didn’t just make it up. It is the result of a lot of trial and error and observation, risk, stress, unbelievable elation when things worked out, and the inability to give up. I still don’t know why I didn’t give up. I like to think if I did it again I’d give up. It might be a better way to live my life 😉

Collaborative Product Design v0.9 Ch4 Facilitation

Facilitation is a key ingredient for Collaborative Design Sessions. No group should attempt this process without a facilitator. Some important things to get right going into the event include:

The facilitator is not a Benevolent Dictator
The facilitator here is not the Benevolent Dictator For Life, cat herder, or Community Manager (or other models) commonly found in open source, rather the model is closer to an unconference-style facilitator. Don’t confuse these very different approaches!

Organisational neutrality
The facilitator should not be part of the organisation that is in need of the solution. This frees the facilitator from internal politics and dynamics and enables them to read the group clearly and interact freely.

Domain Knowledge is not necessary but useful
A facilitator may be entirely neutral or, in the case where an organisation is working already with an open source product in mind, be part of the open source product development team or community. The facilitator of these sessions may or may not have domain or product knowledge. If there is no domain knowledge it is recommended product and domain experts be present. This helps a great deal to keep the process anchored to ‘product reality’.

However…there are some gotchas. If the facilitator is part of the org with ‘the solution’ (eg an open source product) then make sure someone else from your team is present. Facilitation is about trust and you can’t be both a facilitator and a product advocate. You need someone else present to advocate for the product. The second gotcha is that it is generally better for the facilitator to be neutral to all parties, however, in this case, I believe there is value in the facilitator knowing the proposed product-solution intimately (with some knowledge of how it could apply to the use case being confronted), but you will need to work extra hard to maintain your trusted neutrality (you might have to work out in advance how to manage your feelings if the group starts advocating that they don’t use your product, for example).

Tools
You may wish to have tools such as post-its etc, but generally, a large whiteboard and markers (or large pieces of paper) will take care of it. Most shared objects are documentation but it may be necessary at times to use other facilitation tools and tricks to move a group process along.

ch4_top

Facilitation Tips
Here are some things to remember when facilitating Collaborative Design Sessions:
Build trust before products

As a facilitator, your job is to build trust in you, the process, the group, and the outcomes. Each time you make a move that diminishes trust you are taking away from the process and reducing the likelihood of success. For this reason, you must put building trust, working with what people say and towards what people want, ahead of building ‘your’ product. Trust that the product and a commitment to it, will emerge from this process, and it will be better for it.

Change is cultural, not technical
Too often technology is proposed as the mechanism for change. Technology does not create change. People create change, with the assistance of technology. Make sure the group is not seeing technology as the magic wand. Change is not magically ‘embedded’ in the technology. Improvement, optimisation, or radical reworking of workflows requires people to do things differently. The group must be committed to changing what they do. The ‘what they do’ should not be posited as a function of technology, it is their behaviour that will always need to change regardless of whether there is a technology change. Behavioural and cultural change is a necessity, not something that ‘might happen’. The group needs to recognise this and be committed to changing how they work.

Focus on problems and solutions not technology
As mentioned above, cultural change is necessary and many behavioural changes can occur that will produce positive results without the need for a technology change. It is important that you and the group can identify these issues and bring them into a focused discussion. For this reason, it is very important that the initial sessions focus on what the problems are, irrespective of whether they are born of technology or workplace process. If you can accomplish this then the group may very well propose changes that have nothing to do with technology. This is a very good outcome, as the end goal is to improve how things are done. If technology change is not always (or ever) part of the solution that is also success for the process.

ch4_middle

Even the best solutions have problems
Own that even the best solutions, including the one you are representing, will have problems. There is no perfect solution, and if there is then time will inevitably make it imperfect.

Leave your know-it-all at the door
If you are part of a product team then you may be expected to be somewhat of a domain and / or product expert. Leaving that at the door is not possible of course, but you should be careful that you do not use this knowledge as heavy handed doctrine. Instead, it should manifest itself in signposts, salient points, and inspiring examples at the right moments. These points should add to the conversation not override it. Don’t overplay your product knowledge and vision, you will lose people if you do.

Give up your solution before you enter the room
If you are part of a product team it is a mistake to enter into a Collaborative Design Session and advocate or direct the group towards your solution. If the group chooses a technology or path you do not have a stakeholding in, then that is fine. The point is, however, that the likelihood is that they will choose ‘your’ technology, otherwise, you would not be asked to be in the same room with them. However, if you facilitate the process and drive them to your solution you will be reading the group wrong and they will feel coerced. You must free yourself from this constraint and be prepared to propose, advocate, or accept a solution that is not ‘yours’ or you did not have in mind when you entered the room. This will not only free you up to drive people to the solution they want, but it will earn you trust. When they do they choose your solution, and chances are they will, then they will trust it because they trust you and trust the process. If they don’t choose it, they will trust you and come back another time when they are ready for what you have to offer and, additionally, they will advocate your skills to others.

Involve a broad set of stakeholders
The sessions should involve as diverse a range of stakeholders as possible. This will not only improve the product but increase stakeholder ownership of the solution and that in turn will help the organisation implement it. If people feel they own the solution, they will work towards seeing it implemented. Stakeholders in this context can apply to the organisation you are working with (to solve their problem) or other projects that might play a part in solving the problem. Inviting the later to the events will greatly enhance the final product and produce valuable collaborations.

Move one step at a time
Move through each step slowly. The time it takes to move through a step is the time it takes to move through a step. There is no sense in hurrying the process, this will not lead to better results or faster agreements. It will in all likelihood move towards shallow agreements that don’t stick and ill-thought out solutions that don’t properly address the problem. The time it takes to move through a step will also give you a good indication of the time needed for the steps yet to come. Be prepared to re-scale your timelines at any time and to return to earlier unresolved issues if need be.

Ask many questions, get clarifying answers, ask dumb questions, the dumber the better
Ask many many questions. Try not to make them leading (note: sometimes leading questions are necessary for points of clarification or illustrating an issue). Keep asking questions until you get clear simple answers. Breakdown compound answers where necessary into fragments and drill down until you have the clarity you need. Dumb questions are often the most valuable. Asking a dumb question often unpacks important issues or reveals hidden and unchallenged assumptions. It is very surprising how fundamental some of these assumptions can be, so be brave on this point. If necessary feign humbleness and stupidity for asking an obvious question.

ch4_bottom

Own stupid problems, laugh about them!
Every workplace culture knows they do some stupid things. When you find these, call them out, and, if possible, laugh about them. Providing a context where people can bring forward and own ‘stupid’ processes in an easy way is going to help identify the problems and move towards solving them. It also sometimes gives people an opportunity to question things that they never felt made sense and this may, in turn, help others question the ways things are done – this is very valuable and is not always possible in the everyday workplace environment. Bringing these issues out can be very revealing, it gets people on the same page, and is often cathartic.

Reduce, reduce, reduce
The strongest point is a simple one.

Get agreements as you go
Double check that everyone is on the same page as you go. Get explicit agreement even on seemingly obvious agreements. Total consensus is not always necessary but general agreement is.

Document it all
Get it down in simple terms on whiteboards or whatever you have available. At the end of sessions commit this to digital, shareable, media.

Summarise your journey and where you are now
At the end of a session, it is always necessary to summarise in clear terms the journey you have taken and where you have arrived. Get consensus on this. It is also useful at various points throughout the session to do this as a way of illustrating you are all on the same journey and reminding people what this is all about. When doing this it is very useful to make points in this summary that illustrate that you understand them – bring out points that may have taken a while to get clarity on or that you may have initially misunderstood (there will be many of them if you are doing your job well!) so the group knows that you are embedded with them and not merely massaging them towards your own pre-designed end game.

State your willingness to discard your own product
Nothing builds trust more than statements to show that you are invested in helping them achieve what they need over what you want. Your investment in this, as with all your actions and statements, must be genuine. For this reason, too, you should accept conclusions that propose cultural solutions over technical, and other people’s products over yours. This also implies you need some fair understanding of products competitive in your space and you should not make denigrating comments about them, but instead recognise when they have value. The assumption is however that since they invited you here, and if you are doing a good job, people will choose your product anyway – but you must let them make that choice. It’s OK to highlight this dilemma and probably helps things if you do and do so in a light-hearted way.

All solutions must be implemented incrementally
Do not design and then build the final solution all at once. Solutions must be deployed incrementally and learnings folded back into the proposed solution. Build to a minimum proposition, try it, learn, redesign, repeat.

Bring in the competition
During CDS it is sometimes a good idea to have complementary or competing technology providers at the session. You will probably find that his leads to great collaborations, each contributing what they excel at.

Use their semantics
Use terminology to describe the problem and solution that come from the group. Don’t impose your own semantics.

Facilitation is an art of invention
While this section has not been about how to facilitate it is important to make a note about invention before the next section in the hope that no one just reads the below as an instruction manual. There are processes and methods that you can use ‘off the shelf’ as a facilitator but none of them will translate from paper to reality in a one-to-one mapping. People are too weird and contexts too variable to ever allow facilitators the luxury to do it by numbers. At the very least facilitation is an act of translating known patterns into a new context and tweaking it to fit. But the reality is that much of the what a facilitator does is to make things up. Instinct and the fear of failure force on-the-fly invention of methods, but each time a good facilitator makes it appear that the method has existed for a hundred years and never been known to fail. When it does fail, a really good facilitator will ensure no one notices and that the outcomes were the typical, expected, ones you were after.

Collaborative Product Design Sessions Scratch Pad

This is a rough v0.5 version of a Collaborative Design Sessions method template. Many thanks to Arthur Attwell for working with me to improve this.

Collaborative Design Sessions are one or (more likely) a series of events as part of the Collaborative Product Development cycle, that help an organisation design a solution. In many cases, this solution is a change of behaviours (cultural change) supported by technology (an open source product).

Collaborative Product Design is a new branch on the Systems Development Life Cycle tree. SDLC methods include Spiral, Joint Application Design, Xtreme Programming, SCRUM and others (including those which conform to Agile Manifesto values). Collaborative Product Development is such a method, posited within the free software / open source sector where the cultural rules are quite different to environments where teams are employed to work within a more formal business or corporate structure.

The Sessions

These Collaborative Design Sessions are facilitated-processes and work better as physical gatherings with a facilitator and a wide range of stakeholders. These stakeholders may be from a single organisation, or from a number of organisations with similar needs. Sessions can be 2 hours (no less) or more, in some circumstances they may take several days. Commonly a session is a morning or afternoon (4 hours or so). It is sometimes necessary to break these up over an extended period of time. Each case is different and no ‘one size fits all’ strategy is possible.

The Product

It is assumed that an open source product is already in mind when going through this process and that this product can be adapted to meet the needs of the organisation. It is also assumed that the introduction of any product to an organisation is only in part a technical question, the larger issue is generally cultural.

Facilitation

Facilitation is a key ingredient for Collaborative Design Sessions, no group should attempt this process without a facilitator. Some important things to get right going into the event include:

The facilitator is not a Benevolent Dictator
The facilitator here is not the Benevolent Dictator For Life, cat herder, or Community Manager (or other models) commonly found in open source; rather the model is closer to an unconference-style facilitator. Don’t confuse these very different approaches!
Organisational neutrality
The facilitator should not be part of the organisation that is in need of the solution – this frees the facilitator from internal politics and dynamics and enables them to read the group clearly and interact freely.
Domain Knowledge is not necessary but useful
A facilitator may be entirely neutral or, in the case where an organisation is working already with an open source product in mind, be part of the open source product development team or community. The facilitator of these sessions may or may not have domain or product knowledge. If there is no domain knowledge, it is recommended product and domain experts be present. This helps a great deal to keep the process anchored to ‘product reality’.
Tools
You may wish to have tools such as post-its etc, but generally a large whiteboard and markers (or large pieces of paper) will take care of it. Most shared objects are documentation but it may be necessary at times to use other facilitation tools and tricks to move a group process along.

Note: this document assumes some experience in facilitation. This document is not intended to train facilitators (indeed, experience is the only way to learn facilitation), rather it is intended as a suggested framework-guide for those wishing to try this process.

Here are some things to remember when facilitating Collaborative Design Sessions:

Build trust before products
As a facilitator, your job is to build trust in you, the process, the group, and the outcomes. Each time you make a move that diminishes trust you are taking away from the process and reducing the likelihood of success. For this reason, you must put building trust, working with what people say and towards what people want, ahead of building ‘your’ product. Trust that the product and a commitment to it, will emerge from this process, and it will be better for it.
Change is cultural, not technical
Too often technology is proposed as the mechanism for change. Technology does not create change. People create change, with the assistance of technology.
Even the best solutions have problems
Own that even the best solutions, including the one you are representing, will have problems. There is no perfect solution, and if there is then time will inevitably make it imperfect.
Technology is not a magic wand
Make sure the group is not seeing technology as the magic wand. Change is not magically ‘embedded’ in the technology. Improvement, optimisation, or radical reworking of workflows requires people to do things differently.
Leave your know-it-all at the door
If you are part of a product team then you may be expected to be somewhat of a domain and / or product expert. Leaving that at the door is not possible of course, but you should be careful that you do not use this knowledge as heavy handed doctrine. Instead, it should manifest itself in signposts, salient points, and inspiring examples at the right moments. These points should add to the conversation not override it. Don’t over play your product knowledge and vision, you will lose people if you do.
Cultural drives change, technology assists
The group must be committed to changing what they do. The ‘what they do’ should not be posited as a function of technology, it is their behaviour that will always need to change regardless of whether there is a technology change. Behavioural and cultural change is a necessity, not something that ‘might happen’. The group needs to recognise this and be committed to changing how they work.
Give up your solution before you enter the room
If you are part of a product team it is a mistake to enter into a Collaborative Design Session and advocate or direct the group towards your solution. If the group chooses a technology or path you do not have a stakeholding in, then that is fine. The point is, however, that the likelihood is that they will choose ‘your’ technology, otherwise, you would not be asked to be in the same room with them. However, if you facilitate the process and drive them to your solution you will be reading the group wrong and they will feel coerced. You must free yourself from this constraint and be prepared to propose, advocate, or accept a solution that is not ‘yours’ or that you did not have in mind when you entered the room. This will not only free you up to drive people to the solution they want, but it will earn you trust. When they do they choose your solution, and chances are they will, then they will trust it because they trust you and trust the process. If they don’t choose it, they will trust you and come back another time when they are ready for what you have to offer and, additionally, they will advocate your skills to others.
Focus on problems and solutions not technology
As mentioned above, cultural change is necessary and many behavioural changes can occur that will produce positive results without the need for a technology change. It is important that you and the group can identify these issues and bring them into a focused discussion. For this reason, it is very important that the initial sessions focus on what the problems are, irrespective of whether they are born of technology or workplace process. If you can accomplish this then the group may very well propose changes that have nothing to do with technology. This is a very good outcome, as the end goal is to improve how things are done. If technology change is not always (or ever) part of the solution that is also success for the process.
Involve a broad set of stakeholders
The sessions should involve as diverse a range of stakeholders as possible. This will not only improve the product but increase stakeholder ownership of the solution and that in turn will help the organisation implement it. If people feel they own the solution, they will work towards seeing it implemented.
Move one step at a time
Move through each step slowly. The time it takes to move through a step is the time it takes to move through a step. There is no sense in hurrying the process, this will not lead to better results or faster agreements. It will in all likelihood move towards shallow agreements that don’t stick and ill-thought out solutions that don’t properly address the problem. The time it takes to move through a step will also give you a good indication of the time needed for the steps yet to come. Be prepared to re-scale your timelines at any time and to return to earlier unresolved issues if need be.
Ask many questions, get clarifying answers, ask dumb questions, the dumber the better
Ask many many questions. Try not to make them leading (note: sometimes leading questions are necessary for points of clarification or illustrating an issue). Keep asking questions until you get clear simple answers. Breakdown compound answers where necessary into fragments and drill down until you have the clarity you need. Dumb questions are often the most valuable. Asking a dumb question often unpacks important issues or reveals hidden and unchallenged assumptions. It is very surprising how fundamental some of these assumptions can be, so be brave on this point. If necessary feign humbleness and stupidity for asking an obvious question.
Own stupid problems, laugh about them!
Every workplace culture knows they do some stupid things. When you find these, call them out, and, if possible, laugh about them. Providing a context where people can bring forward and own ‘stupid’ processes in an easy way is going to help identify the problems and move towards solving them. It also sometimes gives people an opportunity to question things that they never felt made sense and this may, in turn, help others question the ways things are done – this is very valuable and is not always possible in the everyday workplace environment. Bringing these issues out can be very revealing, it gets people on the same page, and is often cathartic.
Reduce, reduce, reduce
The strongest point is a simple one.
Get agreements as you go
Double check that everyone is on the same page as you go. Get explicit agreement even on seemingly obvious agreements. Total consensus is not always necessary but general agreement is.
Document it all
Get it down in simple terms on whiteboards or whatever you have available. At the end of sessions commit this to digital, shareable, media.
Summarise your journey and where you are now
At the end of a session, it is always necessary to summarise in clear terms the journey you have taken and where you have arrived. Get consensus on this. It is also useful at various points throughout the session to do this as a way of illustrating you are all on the same journey and reminding people what this is all about. When doing this it is very useful to make points in this summary that illustrate that you understand them – bring out points that may have taken a while to get clarity on or that you may have initially misunderstood (there will be many of them if you are doing your job well!) so the group knows that you are embedded with them and not merely massaging them towards your own pre-designed end game.
State your willingness to discard your own product
Nothing builds trust more than statements to show that you are invested in helping them achieve what they need over what you want. Your investment in this, as with all your actions and statements, must be genuine. For this reason, too, you should accept conclusions that propose cultural solutions over technical, and other people’s products over yours. This also implies you need some fair understanding of products competitive in your space and you should not make denigrating comments about them, but instead recognise when they have value. The assumption is, however, that since they invited you here, and if you are doing a good job, people will choose your product anyway – but you must let them make that choice. It’s OK to highlight this dilemma and probably helps things if you do and do so in a light-hearted way.
All solutions must be implemented incrementally
Do not design and then build the final solution all at once. Solutions must be deployed incrementally and learnings folded back into the proposed solution. Build to a minimum proposition, try it, learn, redesign, repeat.
Bring in the competition
During CDS, it is sometimes a good idea to have complementary or competing technology providers at the session. You will probably find that his leads to great collaborations, each contributing what they excel at.
Facilitation is an art of invention
While this section has not been about how to facilitate, it is important to make a note about invention before the next section in the hope that no one just reads the below as an instruction manual. There are processes and methods that you can use ‘off the shelf’ as a facilitator but none of them will translate from paper to reality in a one-to-one mapping. People are too weird and contexts too variable to ever allow facilitators the luxury to do it by numbers. At the very least facilitation is an act of translating known patterns into a new context and tweaking it to fit. But the reality is that much of the what a facilitator does is to make things up. Instinct and the terror of failure force on-the-fly invention of methods, but each time a good facilitator makes it appear that the method has existed for a hundred years and has never been known to fail. When it does fail, a really good facilitator will ensure no one notices.

Phases

The following is a rough structure for a CDS implementation. Facilitation of CDS is necessarily fluid and it is not expected that there are strongly delineated phases, rather that there will be some ebb and flow between each. As a rule, however, you should be moving forward through these stages in a somewhat sequential and linear fashion.

Each of the following phases are guides, and they may all be done in one CDS or over multiple sessions:

Introductions
No matter if everyone knows each other, always do a round of introductions. It sets a baseline expectation that even the obvious should be stated. It will also help you to understand something of the stakeholders present and the roles they play. Experienced facilitators also use this time to read the interactions in the group and start formulating strategies to get them collaborating.
Why are we here?
Ask the question – do we want change? Before starting on any Collaborative Design Session you must first confirm that the group actually wants to produce change. This should be explicit, the facilitator can actually ask this question outright. The answer is yes, but it is not the answer that it is important, it is an affirmation by the group that they are prepared to undergo a process that will instigate change.
Where are we now?
We need a good understanding of the current workflow.
- Start with a description of the current workflow
- identify pain points
- quantify time periods
- identify roles & gatekeepers
Turn all of the above into easily consumable artefact’s (may need to occur after the CDS) and share them.
Identify Scope
The problem space identified above may be huge. If this is the case then some scoping is necessary. Ask the group to define the most important problems to solve first. If possible you want one nice cohesive problem to solve. Avoid trying to solve too much.
Solution Proposition
We are now in search of the Solution Proposition. An SP is not a solution, it is a proposition. It’s very important to frame it this way. We are not under the illusion that the final design is a magic cure-all, rather it is a hypothesis that we are now prepared to test out. There are a number of ways you can develop an SP. Your choice of method is a product of observations about how the team works together, the problems they are trying to solve, and your experience as a facilitator. Here are some example methods to get there, these are some things that could work. However, facilitation is about invention. Invent processes like the below on the fly and then test them out in your sessions and learn. If you are doing your job well then you will be experimenting all the time, and if you are doing your job really well then no one will notice when one of your new inventions (possibly made up as you are saying it) fails. Those listed below work, but the first time I used each I made them up on the spot (shhh…).Blank Canvas
Start with a very open-ended session. Ask how they would like to work, let the conversation roam. Document anchor points that seem important and/or repeated themes. Essentially what you are looking for is a starting point for the new story on how things will be done. This starting point might be very concrete, or it might be highly conceptual. It could also be that you think you have the starting point but find that actually, some in the group want to take the starting point back to the fundamentals of what they are trying to achieve as an organisation. Your job is to witness this and keep the process going until you find the point where most, if not all, participants what to start the new story.

At this point, you need to make sure the new story is well documented and you are getting good clear, simple, points. There is no substitute for facilitation experience at this point, but if you are struggling then the best strategy is to try and make the starting point somewhat concrete and less conceptual. For example, draw a blank box and say something like”how do we start the new process in a browser?” (assuming we are discussing web-based solutions). Get to a blank canvas that is somewhat parameterized and contained. Then draw out concrete details about what ‘could’ happen in on this new canvas. Enable people to roam and use what you have learned from the previous phases and what you know about the domain and product to ‘keep the conversation real’. This will make your work much easier.

Iterate like this and work towards building concrete steps that illustrate the new ways of doing things. It is surprising that in some situations this process will lead directly to a pretty good understanding of what user interfaces and flow you are building. Other times, you may need to keep the conversation going until something concrete will materialise. In general, the more experienced you are as a facilitator, the better this part of the process will proceed.

Pitching
Give each of the participants some large pieces of paper and ask them to each to draw a solution. Set a finite amount of time. Don’t let anyone claim they ‘don’t know enough’ about the problem space – ‘naive’ Solution Propositions often have very insightful points. At the end of the time limit, each participant is to pin their paper to the wall and speak to it in 5 minutes. These are not real pitches, just a light presentation of what they were thinking. Then have 5 minutes of questions and comments. Leave all papers on the wall (just add to them for every pitch).

After everyone has presented, it is good to break for a while as this was probably a long session. It is also good to break here to take some time and consider what your next step be. From the pitches, you must derive a single Solution Proposition. It is OK at this point to propose it yourself when the group returns to the room. Make sure that when you do this you are proposing ideas that the group has had and not your own pre-designed solution. Invite comment on the Solution Proposition.

You should end this phase with a good understanding of the cultural changes necessary and what you are trying to build. It is not unusual to have whiteboard wireframes at the end of this process.
Working Agreements
Agree on how you will work together. What channels you will use, what information goes where, when the next face to face or remote meetings will be etc.
Mocks and prototypes
If there is ‘something’ to build, don’t build anything yet. Create image mockups, get feedback, iterate to sign off. Then move to some form of interactive prototype. HTML is often a quick way to do this, you don’t need all the functionality in place and not everything needs to be working. Get feedback, iterate to sign off.
The Build
As a result of the phases above, changes may need to be done internal to the organisation – this will quite probably not involve you. However a product, most likely, also has to be built hence following from the Collaborative Design Sessions is the build period. This is possible to do within group sessions as outlined above but is more likely to be done outside of these sessions. Generally, tasks are allocated to individuals with the necessary skills. UX people, for example, will generate mockups or developers will work on code. These materials are then brought back to the group for discussion, it may be that this process is conducted remotely in part or whole.

Leadership, diversity and sector change in open source

Recently I have been pondering how sector change is possible. Sector change, specifically change in the publishing sector, is a key goal of mine. I don’t want to be involved in just improving sector publishing, I want to change it completely – so even the language we use to describe what was once ‘publishing’ is shifted into another domain, that of knowledge production.But how to do such a thing? How can you shift an entire sector sideways and rewrite processes, tools, value systems, expectations, career paths, language: the whole works?

Examples of sector change

Community building begins with convincing people who don’t need to work together that they should.
– John Abele

Recently I have found some clues to these questions in the writings of John Abele (founder of Boston Scientific), particularly “[Bringing Minds Together]”(https://hbr.org/2011/07/bringing-minds-together). His writings have inspired me to look again at how I see Open Source.

Early in his career, John was involved with some technologies for non-invasive surgery. Today, such matters are handled day-to-day. Back then, however, surgery was invasive by definition. Back then, talk of non-invasive instruments for surgery would be like talking about screen-less phones today. Imagine trying to sell that.

So he had a hard time trying to sell a new idea that he knew could transform the medical sector. As he writes, “We were developing new approaches that had huge potential value for customers and society but required that well-trained practitioners change their behaviour. … Despite the clear logic behind the products we invented, markets for them didn’t exist. We had to create them in the face of considerable resistance from players invested in the old way and threatened with a loss of power, prestige, and money.”

That’s more-or-less what we face with Coko (Collaborative Knowledge Foundation) at the moment. Smart people that are under the painful burden of outdated workflows and technology often resist systemic change because it requires them to alter their normal ways of working. Their resistance to change is a huge problem if you wish to modernise the way knowledge is produced and reduce that burden on them.

In John’s case, he drew on some insights he had gathered early on in his career from Jack Whitehead, CEO of Technicon, a small company that had the patent for a new medical device. When trying to bring this product to market, Technicon had the odds stacked against them. No one, from the lab technicians through to the professional societies and manufacturers, wanted anything to do with it. So Jack drummed up some interest from early adopter types and came up with a surprising next step. He “told all interested buyers that they’d have to spend a week at his factory learning about it.”

That sounds like an odd sales pitch now, but back then (early 60s) apparently it sounded a whole lot more crazy. Nevertheless, Jack convinced a handful of excited early adopters to seize that day, and brought them into his factory.

During that week, the early adopters were not treated like customers but like partners. They were part of the team. They came to know each other, they worked together, they shaped the product. They became the team. As John says:

“When the week ended, those relationships endured and a vibrant community began to emerge around the innovation. The scientist-customers fixed one another’s machines. They developed new applications. They published papers. They came up with new product ideas. They gave talks at scientific meetings. They recruited new customers. In time, they developed standards, training programs, new business models, and even a specialised language to describe their new field.”

This meeting of once potential customers, now team members, not only contributed to the design of the technology but then took it out into the world and fueled adoption and interest in the product. What had humble roots with a group of early adopters was on its way to creating large-scale change.

John witnessed this process and realised this was strategy, not whimsy: “[Jack] was launching a new field that could be created only by collaboration — and collaboration among people who had previously seen no need to work together.”

John went on to form Boston Scientific and refined this strategy further with Andreas Gruentzig when introducing the balloon catheter to a hostile and uninterested market. Again he was successful in catalysing large-scale change.

Astonishing. But you could have told the same story about any number of successful Open Source projects. Indeed, John reflects on the parallels to Open Source :

“Just as Torvalds helped spawn the Open Source movement, and Jimmy Wales spearheaded the Wiki phenomenon, Andreas [Gruentzig] created a community of change agents who carried his ideas forward far more efficiently than he could have done on his own.”

The strategy in both cases started with a simple idea – to create a community of change agents.

Leadership

Leaders need to cede control, not vigorously exert it.
– John Abele

The creation of a community where collaboration can flourish is a product of a particular kind of leadership – what John calls ‘collaborative leadership’. I have also seen this in many places including Open Source, Unconferences, and Book Sprints (which I founded). In the latter two cases, we call the collaborative leader a facilitator.

There are many modes of facilitation and choosing the right characteristics, the right mode, to create the right environment, is critical. John gives some interesting tips on what this mode looks like. The characteristics that I have gleaned from his article include the ability to:

foster “collaboration among people who had previously seen no need to work together”
manage egos
earn trust
respect stakeholder interests
be authentic
“listen, share, and ask good questions”
share the credit
use “we” not “I”
support the choice of ‘alternative methods’
create rituals
create non-traditional spaces and experiences to come together
ensure people “feel like partners”
be willing to take direction from the ‘customer-participants’
build trust over control
“point out the deficiencies in the tools” you are making
present ideas “in ways that [cry] out for input”

A good facilitator knows this language and these modes and can apply them but there are different requirements for facilitation depending on what you are trying to achieve. Book Sprint facilitation, for example, is much more product- orientated (books) than Unconference facilitation and requires a different set of strategies and tools. Most of the issues above I would categorise as being general rules of facilitation, however, those that modes that hint at enabling a group to create llarge-scalechange are the most interesting here. I think the last four points are telling:

be willing to take direction from the ‘customer-participants’
build trust over control
“point out the deficiencies in the tools” you are making
present ideas “in ways that [cry] out for input”

The most important issue at stake here is for the facilitator to create the space so others will come up with the product solution. This kind of facilitation creates vacuums, spaces where solutions don’t yet exist. This kind of facilitation is focused on a diverse range of stakeholders to design the product. This kind of facilitator doesn’t have all the answers but instead highlights problems and brings people together to create the solutions. Typical facilitation modes are necessary to enable an environment of trust and sharing, but enabling the participants to own the problems and create the productized solution requires a very specific mode of facilitation.

Can Open Source do this?

Open source software is about people.
– Sacha Greif

While these examples are about proprietary technology. It is not the proprietary-ness at stake here, it is the process that is important – and good process is the product of good facilitation. Often there is facilitation active in Open Source projects, but not necessarily, and where it does exist it is not typically with the kind of framing John has pioneered. Sure projects want people to use their software, they want to be sustainable, they don’t want to do all the work, they want community. However, Open Source projects are typically interested in bringing in more developers and not necessarily on fueling wide scale adoption (as odd as that may sound), and this informs the kind of people involved and the facilitation strategy employed.

There is a great article by Telescope founder Sacha Greif that illustrates this quite well. Sacha writes – “So why did I decide to make Telescope open source in the first place? It’d be easy to answer with typical clichés about “giving back to the community” or “believing in free software”….But the truth is a lot more pragmatic and selfish: I thought it would be a good way to get other people to help me accomplish my own goals, for free.”

Sacha goes on something of a journey with Telescope, undertaking some course corrections, and concludes “when it comes to Open Source software, software actually plays a fairly minor role. Open Source software is about people.”

I think this illustrates quite nicely where the mindset of open source projects generally are. Sacha went past the ideal of ‘build it and they will come’, a very tech-centric way of seeing things, through to understanding that the secret to success for an Open Source project lies with people, not technology. Sacha transitioned from developer to facilitator.

That is very laudable. However, facilitating developers to build your technology, is very different from facilitating a diverse set of stakeholders to develop a product, fuel adoption, changing user behaviors and putting your project on the path to creating wide scale change. The later requires involving different stakeholders and it involves a different mode of facilitation.

This is where Open Source is getting in its own way. Open source is about employing the right tools, facilitation included, to expand your developer base. That’s fine if you are building the plumbing – Open Source libraries, under-the- hood services, backend functionality etc can all be built well using this kind of method. However, if you want to be part of a team that creates wide scale change through a user-facing product, then I would suggest that open source as a culture-methodology is not the way to do it. Open Source is, at its heart, a techno-meritocratic culture. Great for building under- the-hood tools (builders building for other builders), terrible for producing products.

This shouldn’t be surprising. Somehow, however, it is. But then again when we look closely it sort of makes sense…Even the term ‘Open Source’ expresses just how much the code and those that make it form the core orientation and value metrics. Additionally, in a typical Open Source project, the person at the top isthe person with all, or most of, the technical answers (in a techno-meritocratic culture you can only not know so much before you ain’t the boss anymore). The famed benevolent dictator. And they are the culture keepers, the arbitrators, the facilitators. This sets the scene for a particular kind of facilitation that privileges the involvement of those with technical skills over anyone else. This all points to a certain kind of mono-cultural community.

To see a good example of this have a look at this post about Octocat. The entire emphasis of this article is to find ways to celebrate ‘non-code’ contributions. The term ‘non-code’ in itself is an indicator that anything other than code only has value by association (imagine a manager in any industry thanking a group of workers for their ‘non-management contributions’). Octocat was developed to measure ‘non-code contributions’ and to be effective ‘non-coders’ must log their activities in the projects issue tracker. Hence all contributors must use the same tools that the developers use. Octocat is a good project but it highlights just how focused the entire culture of Open Source is on technical development and needs everyone to fit into that paradigm. I believe this is at the cost of the product, adoption, and the potential change the product could make if managed differently.

Diversity

“Diversity creates better projects. So, why aren’t designers participating in open source?” – Una Kravets

So, what must open source change to enable a project to create massive change? Open source requires a different kind of culture. Open source must diversify away from technocratic meritocracy to become diverse communities of stakeholders. Unfortunately just the opposite is happening – ‘non-coders’ are being chased away in droves.

This is not new news. Open source has sort of known there was something wrong with its culture for sometime. The wholesale migration to closed source desktops (Apple) by the open source development world highlights this. Why did we see this enormous migration? Because OSX is ‘nicer to use’. That tells us something. Open Source has generally failed on user experience (I must note that I do not believe that to be the case now for open source desktops) and it has failed because Open Source culture is not inclusive of designers. The mono-culture has very firm boundaries for what it can do well, and it cannot provide good UX unless it diversifies.

Una Kravets has done a very nice presentation about these issues. In this presentation Una goes into detail of why designers are not involved in open source and how to enable the conditions to improve participation.

The point here is that it is not just a question about representation (and the shockingly low numbers of women involved), it is also a question of the health of a product. As Una has argued well ‘diversity creates better projects’. I would like to take that one step further and suggest that diversity not only creates better projects, it creates better conditions for wide scale adoption and change. To develop a successful product you need to have the customers designing the solution, you need UX designers to finesse the interactions, designers to make it look great, evangelists to present it at conferences, you need developers to do the plumbing, you need users for the feedback, and you need facilitators that can bring all these people together and enable them to function as a passionate, problem-solving, engaged whole. To do that, all those people need to be drawn from a diversity of contexts, valued equally, and they must all have a say in what it is that is being created. You need what John Abele calls ‘a community of change agents,’ not a community of developers.

Involving and privileging only developers is not the right kind of culture to achieve success with a product. We must do away with the techno-meritocratic culture of Open Source and replace it with a more change-centric paradigm – the community of change agents. The root of this new kind of product development culture requires a specific kind of facilitation (‘collaborative leadership’), and the passionate involvement of a diverse set of stakeholders.

The writings of John Abele have led me through a curious journey. While I was always troubled by the technocratic nature of Open Source, I figured it was a transformational movement and I would figure out a way to exist within in it and assist where I could. However, I am now seeing very clearly that, while there are individual exceptions, Open Source as a movement has its own hard coded limits. Unfortunately, these are limits that stunt effectiveness and the ability to create wide scale change, especially with the user-facing products. Unfortunately, the Open Source movement itself is barely cognizant of these limitations, why they exist, and how they could be removed.

Coda for the trolls

It probably won’t help moderate your responses but just in case… a bit of a background of where I am coming from. I love Open Source, I think it has done amazing things. I am a free license and free culture advocate. I started communities of free documentation writers to support Open Source, have initiated many software projects – all Open Source – and contributed in humble ways to others. The Open Source projects I work in now use entirely open source tools. I have supported free culture campaigns with my own time and money including (most recently) The Cost of Freedom. I have lived and breathed Open Source for about the last 20 years. I haven’t used any other desktop since 2000 or so, and have belonged to, and worked with, many hacker collectives. I don’t intend to give up on Open Source any day soon, but I do intend to do what I can to make it better, however small that contribution might be.

*original article and history here https://www.adamhyde.net/open-source-is-not-about-people-or-technology-its-about-change/ *

With thanks to Andrew Rens for great feedback, and Steve Song for some inspiring asides.

Open Source is not about technology, or people, it’s about change

NB Now updated, renamed, and moved to here
https://www.adamhyde.net/leadership-diversity-and-sector-change-in-open-source/

v 0.5.1 – Feb 3 “clean up”
v 0.5 – Feb 2 “rewrite, thanks to Andrew Rens”
v 0.4 – Jan 31 “add facilitation mode on product dev”
v 0.3 – Jan 30 “added more detail on good collaboration”
v 0.2 – Jan 29 “some lessons for open source added”
v 0.1 – Jan 28

needs more content, fact checking, structure. Be patient with me! Will improve it in the next days

[new working title]

Leadership, diversity and sector change in open source

Recently I have been pondering how sector change is possible. Sector change, specifically to change the publishing sector, is a key goal of mine. I don’t want to be involved in just improving it, I want to change it completely – so even the language we use to describe what was once “publishing” is shifted into another domain, namely knowledge production.

But how to do such a thing? How can you shift an entire sector sideways and rewrite processes, tools, value systems, expectations, career paths, language? The whole works.

Examples of sector change

Community building begins with convincing people who don’t need to work together that they should. - John Abele

Recently I have found some clues to these questions in the writings of John Abele (founder of Boston Scientific), particularly “Bringing Minds Together“. His writings have inspired me to look again at how I see open source.

Early in his career, John was involved with some technologies for non-invasive surgery. Today the stuff is day-to-day. Back then, surgery was invasive by definition. Back then, talk of non-invasive instruments for surgery would be like talking about screen-less phones today. Imagine trying to sell that.

So, he had a hard time trying to sell a new idea that he knew could transform the medical sector. As he writes, “We were developing new approaches that had huge potential value for customers and society but required that well-trained practitioners change their behaviour. … Despite the clear logic behind the products we invented, markets for them didn’t exist. We had to create them in the face of considerable resistance from players invested in the old way and threatened with a loss of power, prestige, and money. ”

This is what we face with Coko (Collaborative Knowledge Foundation) at the moment. Smart people that are under the painful burden of outdated workflows and technology are often resistant to change because it requires them to change their behaviours. It is a huge problem if you wish to modernise the way knowledge is produced and reduce that burden on them.

In John’s case, he drew on some insights he had gathered early on in his career from Jack Whitehead, CEO of Technicon, a small company that had the patent for a new medical device. When trying to bring this product to market, Technicon had the odds stacked against it. No one from the lab technicians, through to the professional societies and manufacturers, wanted anything to do with it. So Jack drummed up some interest from early adopter types and came up with a surprising next step, he “told all interested buyers that they’d have to spend a week at his factory learning about it.”

That sounds like an odd sales pitch now, but back then (early 60s), apparently it sounded a whole lot more crazy. However, Jack convinced a handful of excited early adopters to take that step, and brought them in.

In this week, the early adopters were not treated like customers but like partners. They were part of the team. They came to know each other, they worked together, they shaped the product. They became the team. As John says:

This meeting of once potential customers, now team members, not only contributed to the design of the technology but then took it out into the world and fueled adoption and interest in the product. What had humble roots as a group of early adopters, was on its way to creating large-scale change.

John witnessed this process and realized this was strategy not whimsy: “[Jack] was launching a new field that could be created only by collaboration—and collaboration among people who had previously seen no need to work together.”

Astonishing. You could have told the same story about any number of successful open source projects. Indeed, John reflects on the parallels to open source:

“Just as Torvalds helped spawn the open source movement, and Jimmy Wales spearheaded the Wiki phenomenon, Andreas [Gruentzig] had created a community of change agents who carried his ideas forward far more efficiently than he could have done on his own.”

The strategy in both cases started with a simple idea – to create a community of change agents.

Leadership

Leaders need to cede control, not vigorously exert it. - John Abele

The creation of a community where collaboration can flourish is a product of a particular kind of leadership – what John calls ‘collaborative leadership’. I have also seen this in many places including open source, unconferences, and Book Sprints (which I founded). In the later two cases we call the collaborative leader a facilitator.

There are many modes of facilitation and choosing the right characteristics, the right mode, to create the right environment is critical. John gives some interesting tips on what this mode look like. The characteristics that I glean from his article includes the ability to:

foster “collaboration among people who had previously seen no need to work together”
manage egos
earn trust
respect stakeholder interests
be authentic
“listen, share, and ask good questions”
share the credit
use “we” not “I”
support the choice of ‘alternative methods’
create rituals
create non-traditional spaces and experiences to come together
ensure people “feel like partners”
- be willing to take direction from the ‘customer – participants’
build trust over control
“point out the deficiencies in the tools” you are making
present ideas “in ways that [cry] out for input”

A good facilitator knows this language and these modes and can apply them but there are different requirements for facilitation depending on what you are trying to achieve. Book Sprint facilitation, for example, is much more product-orientated (books) than Unconference facilitation and requires a different set of strategies and tools. Most of the issues above I would categorize as being general rules of facilitation, however those modes that hint at enabling a group to create large-scale change are the most interesting here. I think the last four points are telling:

be willing to take direction from the ‘customer – participants’
build trust over control
“point out the deficiencies in the tools” you are making
present ideas “in ways that [cry] out for input”

The most important issue at stake here for the facilitator is to create the space so others will come up with the product solution. This kind of facilitation creates vacuums, spaces where solutions don’t yet exist. This kind of facilitation is focused on a diverse range of stakeholders to design the product. This kind of facilitator doesn’t have all the answers but instead highlights problems and brings people together to create the solutions. To do this, typical facilitation modes are necessary to enable an environment of trust and sharing while enabling the participants to own the problems and create the productized solution. This comprises a very specific mode of facilitation.

Can Open Source do this?

Open source software is about people.
 - Sacha Greif

While these examples are about proprietary technology, it is not the proprietariness at stake here, it is the process that is important – and good process is the product of good facilitation. While facilitation is active in many open source projects, it is not necessarily so, and where it does exist it is not typically with the kind of framing John has pioneered. Sure projects want people to use their software, they want to be sustainable, they don’t want to do all the work, they want community. However, open source projects are typically interested in bringing in more developers yet not necessarily on fueling wide-scale adoption (as odd as that may sound) and this informs the kind of people involved and the facilitation strategy employed.

Sacha goes on something of a journey with Telescope, undertaking some course corrections, and concludes “when it comes to open source software, software actually plays a fairly minor role. Open source software is about people.”

I think this illustrates quite nicely where the mindset of open source projects generally are. Sacha went past the ideal of ‘build it and they will come’, a very tech-centric way of seeing things, through to understanding that the secret to success for an open source project lies with people, not technology. Sacha transitioned from developer to facilitator.

That is very laudable. However, facilitating developers to build your technology is very different from facilitating a diverse set of stakeholders to develop a product, fuel adoption, change user behaviours and put your project on the path to creating wide- scale change. The later requires involving different stakeholders and it involves a different mode of facilitation.

This is where open source is getting in its own way. Open source is about employing the right tools, facilitation included, to expand your developer base. That’s fine if you are building the plumbing – open source libraries, under the hood services, back end functionality, and so on can all be built well using this kind of method. However, if you want to be part of a team that creates wide scale change through a user-facing product, then I would suggest that open source as a culture-methodology is not the way to do it. Open source is, at its heart, a techno-meritocratic culture. Great for building under the hood tools (builders building for other builders), terrible for producing products.

This shouldn’t be surprising. Somehow however it is. But then again when we look closely it sort of makes sense…Even the term “Open Source” expresses just how much the code and those that make it form the core orientation and value metrics. Additionally, in a typical open source project, the person at the top is the person with all, or most of, the technical answers (in a techno-meritocratic culture you can only not know so much before you ain’t the boss anymore- and become the famed benevolent dictator. And they are the culture keepers, the arbitrators, the facilitators. This sets the scene for a particular kind of facilitation that privileges the involvement of those with technical skills over anyone else. This all points to a certain kind of mono-cultural community.

To see a good example of this, have a look at this post about Octocat. The entire emphasis of this article is to find ways to celebrate ‘non-code’ contributions. The term ‘non-code’ in itself is an indicator that anything other than code only has value by association (imagine a manager in any industry thanking a group of workers for their ‘non-management contributions’). Octocat was developed to measure ‘non-code contributions,’ and to be effective ‘non-coders’ must log their activities in the projects issue tracker. Hence all contributors must use the same tools that the developers use. Octocat is a good project but it highlights just how focused the entire culture of open source is on technical development and wants everyone to fit into that paradigm. I believe this is at the cost of the product, adoption, and the potential change the product could make if managed differently.

Diversity

"Diversity creates better projects. So, why aren't designers participating in open source?" - Una Kravets

This is not new news. Open source has sort of known there was something wrong with its culture for sometime. The wholesale migration to closed source desktops (Apple) by the open source development world highlights this. Why did we see this enormous migration? Because OSX is ‘nicer to use’. That tells us something. Open source has generally failed on user experience (I must note that I do not believe that to be the case now for open source desktops) and it has failed because open source culture is not inclusive of designers. The mono-culture has very firm boundaries for what it can do well, and it cannot provide good UX unless it diversifies.

Una Kravets has done a very nice presentation on these issues. In this presentation, Una goes into detail why designers are not involved in open source and how to enable the conditions to improve participation.

The point here is that it is not just a question about representation (and the shockingly low numbers of women involved), which is an effort we should all support in its own right, it is also a question of the health of a product. As Una has argued well, ‘diversity creates better projects’. I would like to take that one step further and suggest that diversity not only creates better projects, it creates better conditions for wide-scale adoption and change. To develop a successful product, you need to have the customers designing the solution, you need UX designers to finesse the interactions, designers to make it look great, evangelists to present it at conferences; you need developers to do the plumbing, you need users for the feedback, and you need facilitators that can bring all these people together and enable them to function as a passionate, problem-solving, engaged whole. To do that , all these people need to be drawn from a diversity of contexts, valued equally, and they must all have a say in what it is that you are creating. You need what John Abele calls ‘a community of change agents,’ not a community of developers.

Involving and privileging only developers is not the right kind of culture to achieve success with a product. We must do away with the techno-meritocratic culture of open source and replace it with a more change-centric paradigm – the community of change agents. The root of this new kind of product development culture requires a specific kind of facilitation (‘collaborative leadership’), and the passionate involvement of a diverse set of stakeholders.

Summary

I love open source, I think it has done amazing things. I am a huge free license and free culture advocate. I started communities of documentation writers to support open source, have initiated many software projects – all open source – and contributed in humble ways to others. However, the writings of John Abele have lead me on a curious journey. While I was always troubled by the technocratic nature of open source, I figured it was a transformational movement and I would figure out a way to exist within in and assist where I can. However, I am not seeing very clearly, that, while there are individual exceptions, open source as a movement has its own hard-coded limits. Unfortunately, these are limits that stunt its effectiveness and its ability to create wide-scale change, especially with user-facing products. Unfortunately, the open source movement itself is barely cognizant of these limitations, why they exist, and how they could be removed.

tbc

older version:

Recently I have been pondering how sector change is possible. Sector change, specifically to change the publishing sector, is a key goal of mine. I don’t want to be involved in just improving it, I want to change it completely – so even the language we use to describe what was once ‘publishing’ is shifted into another domain, namely knowledge production.

But how to do such a thing? How can you shift an entire sector sideways and rewrite processes, tools, value systems, expectations, career paths, language. The whole works.

It seems to me that the critical methodologies for wide-scale change like this are ‘almost native’ to open source. I’ll explain the ‘almost’ in a bit. But as an opener, open source has the ability to produce massive change. I don’t mean that open source can change the way that software is produced, we all know that. I mean the strategy for running a successful open source project is the same strategy you should adopt if you are trying to enable change, or massive change – of a sector, for example. I’m kind of surprised to arrive at this conclusion. I always loved open source but I am starting to realise that I have loved it for the wrong reasons.

Over the last 20 years or so of being involved in open source I have felt myself in a kind of continual falling forward into open source values. Who can’t love open source when you get down to it? The idea that software should be available to anyone that wants it, to do with it as they please. Its a great idea. It is about empowerment and that is something powerfully valuable it itself.

Empowerment through open source occurs because people have access to free tools and for this to happen we need generous tool makers. That highlights more good values active in open source, namely sharing. The fact that the technically gifted have brought these tools into our lives and generously shared them for free is something we should celebrate.

Of course, the sharing has its own reward system and isn’t all altruistic. Paid programmers building everything from Facebook to the technology that runs your dentist’s office systems (a reference to this ridiculous article in case you missed it) could not do their work without all the open source libraries they can handily import for free into their projects. Also, to ensure they don’t have to do the same work again in other projects, possibly for different clients or employers, they also share what they build (where possible). By reusing your own work and that of others like this, the total workload is then also decreased and people can get further faster. Progress can be made. Programmers can also enhance their reputations if their work is re-used by other programmers. This becomes value in the market place. Hence this sharing has turned into an economy. It’s a good one, who couldn’t love an economy that encourages sharing? This economy also makes many open source software projects sustainable so the whole system has a beautiful internal logic.

The openness of all this is also something to be valued. Exposing the code to all eyes is a famous strategy for reducing bugs. It’s also touted as a strategy for increasing security. It also means programmers can learn from code developed by others (both the good and the bad). Openness and transparency also have a lot of utility in this world, and open source has proven this utility time and time again. Openness is not only good for the code, but it makes us feel good (if we are not too tainted by the proprietary way of life).

Then there is community. You can’t go far into a conversation about open source without mentioning community. Community is the metric for the well-being of any open source project and seeing a healthy open source community is a sight to behold. It is astonishing. All these people somehow, impossibly, co-ordinating to pull in (more or less) the same direction. Good governance plays a role in this after a certain threshold of participants has been exceeded and good governance in itself is quite miraculous to consider. How do the guardians make the wise decisions necessary to balance participation and technical development, uptake, funding, systems, protocols, agreements…the whole works. To consider the day-to-day decisions, project leads must need to make and the context in which they operate is quite dizzying.

I love all of this.

These are many of the reasons I have loved open source. I mean, who couldn’t love sharing, transparency and community? Well, there are actually many, many other values! But I want to think of the open source developers as very cold-hearted. I still believe in good guys and bad guys – the world is more fun that way, more energising. However, as much as I love open source, I think I have been in love with it for the wrong reasons.

How did I get to this realisation?

Recently I have been reading the writings of John Abele (founder of Boston Scientific). This has lead me down another path and provided me with fresh lens through which to value open source. Strange for me as I am allergic to proprietary-ness and John Abele is a good proprietary citizen. Ranked high on the Forbes rich list – net worth 600 million I believe – John has made a lot of money from Intellectual Property, specifically via the sale of medical instruments.

So, why did this entrepreneur, with whom I would initially assume I would share few values, inspire me to look again at how I valued open source? Well…it all comes down to the fact that John did achieve wide scale, sector-wide, change and he did it in a way that is radical to proprietary culture, but I would consider more native, almost native perhaps, to open source.

Early in his career, John came up with some technology for non-invasive surgery. Today the stuff is day to day. Back then surgery was invasive by definition. Talk of non-invasive instruments for surgery back then would be like talking about screen-less phones today. Imagine trying to sell that.

So, he had a hard time trying to sell a new idea that he knew could transform the medical sector. He did transform a sector, so how did he do it?

John has written quite a bit on how he was able to do this, in particular he writes a lot about collaboration and even brought a conference center specifically to change it into a center for collaboration. But it is his ideas on change that most interest me. His article in this HBR article “Bringing Minds Together” gives some good insights. In this article John speaks of how openness can accelerate adoption where ‘walled’ processes have failed:

https://hbr.org/2011/07/bringing-minds-together

I really encourage you to read that article, I summarise it in part below but the full article is well worth reading.

As he writes:
“We were developing new approaches that had huge potential value for customers and society but required that well-trained practitioners change their behavior. … Despite the clear logic behind the products we invented, markets for them didn’t exist. We had to create them in the face of considerable resistance from players invested in the old way and threatened with a loss of power, prestige, and money. ”

So to overcome this John drew on some insights he had gathered early on in his career from Jack Whitehead, CEO of Technicon, a small company that had the patent for a new medical device. When trying to bring this product to market Technicon had the odds stacked against them. No one from the lab technicians, through to the professional societies and manufacturers wanted anything to do with it. So Jack drummed up some interest from early adopter types and came up with a surprising next step, he “told all interested buyers that they’d have to spend a week at his factory learning about it—and that payment was required in advance.”

That sounds like an odd sales pitch now, but back then (early 60s) apparently it sounded a whole lot more crazy. However, Jack found this handful of excited early adopters and brought them in.

In this week the early adopters were not treated like customers but like partners. They were part of the team. They came to know each other, they worked together, they shaped the product. They became the team. As John says:

They were on the way to creating large-scale change.

John witnessed this and realized that this was no one-off but “something much bigger was actually going on. [Jack] was launching a new field that could be created only by collaboration—and collaboration among people who had previously seen no need to work together. ”

Astonishing. You could have told the same story about any number of successful open source projects. Indeed after applying this strategy with Andreas Gruentzig some years later with Boston Scientific, introducing the balloon catheter to a hostile and uninterested market, John reflects on the parallels to open source:

The strategy in both cases was simple. To create a community of change agents.

The change agent meeting became something of a user group, which in turn became a regular symposium, which then grew in size and prestige that it rivaled the established legacy events.

I feel compelled to note that the kind of product development we are talking about here is qualitatively different from developing a product for an organisation. Product development for a sector and creating large scale change is what this post is investigating.

There are many factors that play into the success of this approach. John Abele doesn’t go into detail what these are but he gives some hints, notably the creation of a culture of what he calls ‘leader – followers’ and a specific kind of ‘collaborative leadership’.

I think by ‘leader – followers’ he is referring a culture where everyone has the opportunity to be heard and to participate in the development of the solutions at stake. This kind of environment is what I would describe as strong collaboration and the interesting thing about this kind of approach is that it creates a strong feeling of shared ownership of the output. Who it is that owns the product, who are the best kinds of candidates to make up this group, so that they can go forward and take the product into the world, is a very interesting question and there might be some lessons to be learned here for open source.

John Abele doesn’t provide much detail in his article as to the desired make-up of this group. Beyond stating that they are potential customers there is very little detail on who these people are. It is interesting that they are customers however as this reflects a lot of the ‘itch to scratch’ mantra of the open source world – get people that have a problem to create the solution. However there might be something of an unintended but interesting critique here for open source. The open source world, it might be argued, leans too heavily on programmer involvement and does not necessarily directly involve the people that have the problem – the users – to design the solution.

The creation of a collaborative environment, in turn, is a product of collaborative leadership, which I have also seen in many places including open source and in Book Sprints (which I founded). In the later case we call the collaborative leader a facilitator.

Facilitation is a good art to place at the center of this strategy to create change and I far prefer this framing (‘collaborative leadership’ is a fine term but I think not many people know what this means, whereas I think ‘facilitator’ has much more currency) than those that exist in the open source world ie. ‘cat herder’ or ‘benevolent dictator’. These roles in open source are applied to co-ordinating programmers, and this highlights the techno-meritocratic approach that open source projects tend to subscribe to. Once again, the open source world could be criticized as too closely marrying this leadership to technical expertise. In the cases John outlines, the leaders don’t seem to necessarily have deep technical skills (although they appear to have a hand in the technical development), but they do have strong facilitation skills.

There are many modes of facilitation. Choosing the right characteristics, the right mode, to create the right environment is critical. John gives some interesting tips on what this might look like. The characteristics that I glean from his article includes the ability to:

foster “collaboration among people who had previously seen no need to work together”
manage egos
earn trust
respect stakeholder interests
be authentic
“listen, share, and ask good questions”
share the credit
use “we” not “I”
be willing to take direction from the ‘customer – participants’
support the choice of ‘alternative methods’
build trust over control
create rituals
create non-traditional spaces and experiences to come together
make people “feel like partners”
“point out the deficiencies in the tools” you are making
present ideas “in ways that [cry] out for input”

A good facilitator knows this language and these modes and can apply them but it is good to recognise that there are different requirements for facilitation depending on what you are trying to achieve. Book Sprint facilitation, for example, is much more knowledge product (books) orientated than Unconference facilitation and requires a different set of strategies and tools. Most of the issues above I would categorise as being general rules of facilitation, however those that are specific to the kind of product-orientated process designed to enable large scale adoption and change are the most interesting. I think the last two points are pointing in this direction:

“point out the deficiencies in the tools” you are making
present ideas “in ways that [cry] out for input”

The most important issue at stake here for the facilitator of this kind of project is to create the space so others will come up with the product solution. Don’t have all the answers, instead identify problems and bring people together to create the solutions. To get to that point the typical facilitation modes are necessary to enable an environment of trust and sharing but enabling the participants to own the problems of a product and create the solutions is slightly different from other facilitation modes.

This is the key ingredient, I believe, to the kind of processes that John and colleagues have pioneered and others have made the same observation. The quote below is taken from here:
http://www.kornferry.com/institute/709-growth-through-collaboration-john-abele-s-vision

“…Abele’s success at Boston Scientific was built upon his ability to bring together extremely competitive intellects and create an environment where participants could meet and be candid about what they were working on, including the new techniques, the risks, the benefits and the strategies they employed…’It was about really sharing what they were learning rather than lecturing about what they were teaching’ Abele said. ‘That was powerful because it really accelerated the development of these new technologies in health care — such as revolutionary steerable catheters — and I believed there must be more opportunities to apply this collaboration in a lot of different areas.'”

While these examples are about proprietary technology. It is not the proprietariness at stake here, it is the process that is important – the methods you use to enable early engagement with a wide diversity of stakeholders, bring them into the team, and enable them to be part of the product development. As the passage above states this is a default almost native methodology for open source but also found in the proprietary world. I say ‘almost native’ because I don’t think that this particular framing is the modus operandi for most open source projects, especially those starting out. Sure projects want people to use their software, they want to be sustainable, they don’t want to do all the work, they want community. Most open source projects start off thinking this way but few develop their thinking beyond this starting point, as this beautiful article by Telescope founder Sacha Greif states well:
https://medium.com/@sachagreif/open-source-lessons-learned-two-years-of-telescope-be4ed955b39

Sacha writes – “So why did I decide to make Telescope open source in the first place? It’d be easy to answer with typical clichés about “giving back to the community” or “believing in free software”….But the truth is a lot more pragmatic and selfish: I thought it would be a good way to get other people to help me accomplish my own goals, for free.”

I think this illustrates quite nicely where the mindset of open source projects generally are. Sacha went past the ideal of ‘build it and they will come’, a very tech-centric way of seeing things, through to understanding that the real secret to success for an open source project lies with people, not technology.

That is very laudable. However, thinking about how to get people involved to build your technology, is very different from thinking about what you do as a methodology for creating change. I would say one particular issue at stake here is who you involve. If you want to create a technical product, you try and engage developers. If you are trying to create change, you must engage a much wider group of stakeholders.

Open source is a strategy, and a proven one, for product development. All the standard lessons have been learned for this, if not universally shared. Openness, sharing, community can lead to a healthy open source project. However these methods are not only about how the product is developed and who is developing it, but they are the basic tools necessary to create change. When wielded right, these strategies can, and have, lead to large-scale change as John Abele has already proven more than once in his life time and as we have seen with some open source projects.

Although I’m very much in love with the many values of open source I am more interested in their ability to create change which I think is an under considered effect. Its not that creating change is the only thing that should be considered but rather it is a lens that must be considered. It is as important to look at your open source project as a strategy for creating change (which, whether you own it or not, you are trying to do) as much as it is important to see it as being about technology and people.

This is a new realization for me. It opens a lot of doors. It perhaps explains, for example, why many open source projects do not succeed. The famous ‘build it and throw it over the wall’ strategy, for example, that so often leads to a lack of adoption and eventual failure. It perhaps presents an argument that the success of a project aimed at large-scale adoption and change is reliant on the involvement of a diverse range of stakeholders – changemakers not just programmers. It explains why open source is good at developing libraries and tools for other programmers but not necessarily very good at producing platforms for non-programmers. It also explains why other projects succeed even if they are not conscious of this framing.

This is, as if it had to be said, extremely important for publishing right now, or ‘knowledge production’ as I would prefer to talk about it, since sector change is what we need as workflows and outputs are still stuck in (what one may call) ‘post-paper’ processes and thinking. Open source can change this sector if viewed as a strategy for creating change. Massive change. However, if you want change to be native to your open source project, you have to own it. And that’s what I intend to do from now on.