In the last 2 years, I have been very privileged to see inside the workflows of many publishers (book, journal, micropubs), aggregators, and preprint servers.
As a system designer, or one that facilitates others to design their own systems, this provides incredible insights into common struggles all of these organisations have. Recently this has given me pause to think about the system design process. So below is a little emergent theory of the importance of mental models in the process of workflow design….
- Who better to ask about an organisation’s workflow than the publishing staff themselves?
There isn’t anyone better! Publishing staff are experts in what they do and they know every nook cranny of their workflow. They know the broken parts *intimately* since they live the pain on a day to day basis. They also know what works and what cannot be sacrificed. - Publishing staff are the best placed to know how to improve their workflow (if given the chance)
In order to be able to improve a workflow you need to first know it intimately. As above, there is no one better to do that than the publishing staff themselves. If you want to solve the problems, publishing staff need to be at the core of the design of solutions. By publishing staff I mean the actual people doing the publishing work. - Publishing staff don’t design their own solutions
This may seem like an oxymoron, but hear me out. In order to design an improved workflow you need a *perfect* mental model of the current workflow and what needs to be done. You need the first so you make sure you aren’t missing anything, you need the later so you know exactly what you can miss (what can be left out, what needs to stay)… Often I have seen one person given this job, and that person comes in from outside the org, or they are from within the organisation but have never done the publishing work directly. That leads to an imperfect mental model and pure speculative theory as to where and how the flow can be improved. It simply doesn’t work but it is the way it is done everywhere.
So… the heart of what I am trying to get at here are these three questions that lead on from the above which I am currently asking myself – why it is we don’t involve the publishing staff intimately in the design of better workflows? What is this mental model stuff and why is it so important? Why do I have this growing gut feeling that it’s all about workflow?
So… as a first, rather rough and quick response to myself on the above three issues…
- why it is we don’t involve the publishing staff intimately in the design of better workflows?
Ok… I might actually sound rather nutty when I say this out loud. I believe the problem lies in the history of software development… First of all, these days we conflate workflow with software. They are not the same thing, but we make the mistake of equating the solution to workflow as software. This is far from the truth… but it is what it is…so, this is where the problem starts. To compound the problem, I’m going to go out on a limb and say that I think software dev today, including ‘Agile’ and Lean etc… repeat the same mistakes as older methodologies like, for example, ‘Waterfall’ and Xtreme Programming etc… That mistake is simple – the solutions providers are outsiders to the problem. I have at times, to be sure, been that person in the past. So I’m not pointing any sticks here…well at least, if I am its also at a past me. Waterfall treated the ‘users’ as research objects. That will only give you an outsider’s solution. Agile (etc) make me a little crazy because they try and cross that divide with tricks like ’empathy maps’ and creating avatars (which is, literally, a process of drawing pictures of the ‘users’ and guessing what they want). It’s no good. Why use avatars when you can actually just ask a real, living, experienced, member of the publishing staff? I have a lot more to say on this…but I’ll leave it here for now, suffice to say these problems situate the ‘end user’ at the end of the process ie. when the software is designed and / or delivered. - What is this mental model stuff and why is it so important?
This is a new insight for me. In a former life, I was a Book Sprint facilitator, and I own Book Sprints Ltd (though I have little to do with the operations). Recently the staff there have been pondering how to communicate the value of Book Sprints and interviewing people that love the process. One such interviewee hit so many deep points I was astounded (I’ll ask if I can share her name and credit her here). Her core point was this – Book Sprints, as a highly immersive collaborative model for book production where the experts (usually programmers) write the book together — [in this paarticular case we are talking about corporate documentation of highly complex software systems], gets to a shared mental model of the complex system exceedingly fast – less than 2-3 days. This is shared as a book so others can ‘get inside’ that mental model. If the same company hires an experienced tech writer to do the same thing, they will take at least 6 – 8 months to arrive at the same level of understanding. It will take them that long to develop the same mental model of the system. That’s the point. (Also, the collaborative effort will simply pull in more nuance, at a deeper level of understanding, that the lone contractor can, arguably, ever do).That is quite an insight, and when I heard it, I recognised the truth in it right away. The same is true for our workflow design processes. If you want the best workflow design you first need a perfect mental model of the problem. It is critical. So, get the staff involved, and if you want to save money and get the quickest design process possible, get them involved early. - Why do I have this growing gut feeling that it’s all about workflow?
Well… because publishing is not about technology, nor is it about formats, nor is it about a confused lexicon that we all think is stable (how many different types of Editor roles are there? what do you mean by peer review?). Publishing is about none of this. It is about how you get a document, how you improve it, and how you get it to others. That’s it. And that is all about workflow…