Pretty funny. Sent to me from a buddy who probably prefers not to be named 😉
The Wax (a web based word processor we are developing) lead dev -Christos Kokosias – yesterday embedded another editor, in the editor. We need this for the PubSweet Book Sprint where we will be including code snippets in the documentation we create. So we need a nice way to manage that… consequently Christos embedded the CodeMirror code editor into Wax. So it has things like syntax highlighting, line numbering, auto complete etc all built into the code blocks…its pretty cool… below is are two short vids Christos made to show it in action:
Pretty cool stuff and extremely useful for writing documentation that includes code…ask yourself… can MS Word or Google Docs do that? #opensourceisbetter
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.
The Coko community is having a Book Sprint in Cambridge next month. It will be about 10-12 people, and facilitated by BookSprints.net and featuring folks from Hindawi, eLife, EBI and Coko! Community making docs for the community.
A document worth remembering – http://antitrust.slated.org/www.iowaconsumercase.org/011607/2000/PX02991.pdf
I don’t like reading Twitter, let alone quoting it…but this thread is something that came into my view and admittedly it has some very good points.
1/ Product Management isn’t a major one can study, few folks graduate into, and most people learn by apprenticeship. There are number of dangerous myths about what the PM role is. Here is a thread with five…
— Noah Weiss (@noah_weiss) May 23, 2018
I particularly like these points:
4/ “PMs are the decision makers”: Many people who convert from another role into product see it as way to get to “make the calls”. It’s a common pattern, especially for disempowered engineers on dysfunctional product development teams.
— Noah Weiss (@noah_weiss) May 23, 2018
6/ That does not, however, mean they should make even a small fraction of decisions themselves. They should be the ultimate facilitator: pull the best ideas from their team, coordinate with xfn partners, get exec context, etc.
— Noah Weiss (@noah_weiss) May 23, 2018
I have problems with the Product Management role, which can also be called Product Owner, Project Manager, … there is a ill defined ‘scopeless nature’ of each of these roles and they are often used evasively and interchangeably. Product Owner is particularly insideous as it is tinged with the Agile religons practice of ‘proxying the user’ (of which they use many tools – empathy maps, avatars etc).
I don’t know Noah Weiss, never heard of him before today, but he seems to have some culture capital in this area going by the amount of chatter on that thread. I can only say it is refreshing to see someone with such high cultural capital speaking sense.
My own take on all of the above is that the role of facilitator is never called out or given a central focus. Noah Weiss speaks of facilitation as a feature of ‘product management’ but I think it is the definition of the role. So much so that I prefer to throw away terms like ‘Product Manager'(etc) in favour of Facilitator. Titles are strong sign posts, navigational instruments that act as framing devices. Hence where lang doesn’t work I like to seek out a more compelling and accurate lexicon. Which is why we (at Coko) don’t have Product Managers etc… we have a Facilitator, which is basically me, and as we scale my job now is to embed that understanding and role definition/practice in the culture and school others (gently) as to what that means.
Twice a year the Shuttleworth Foundation hosts present and past fellows in a one-week meet. This time it was in a beautiful estate in the UK. I have struggled at times to understand the beauty of the UK but this week the English countryside was luscious and beautiful…