Adam Hyde

The path for a manuscript from submission to publication is very similar for most publishers. The process comes down to a common path that looks something like this:

submission -> review -> reject / assign editors -> [*] assign reviewers -> review -> accept / revise (return to [*]) / reject  -> production -> publish

That’s about it. There is not much difference between publishers from a bird’s eye point of view.

The difference between each publisher’s workflow comes down to:

1. how they divvy up the work between people
2. cultural oddities

The first issue, divvying up work, is pretty interesting because you might expect a typical role, such as Handling Editor to be the same from one journal to another. But… that’s not the case. Who does what is very organisationally specific regardless of the titles of the actors. It’s not so much that the total work done is very different, rather the scope of each role varies wildly from one journal to another. The scope of each role is most often determined by cumulative legacy workflow decisions and technology choices over many years. For example, each Journal uses an assortment of tools, from google docs to wikis, to augment their manuscript submission system. So the scope of all the current roles is directly affected by this. Consequently, if you design a new system which prescriptively maintains the current scope of actions of a role, then you are hardcoding the mistakes of the past and not enabling the roles to optimise over time. In my opinion, it’s imperative to build systems where the scope of roles can be easily changed. This will allow new ways of working to evolve and the chaff can drop off as the staff realise it is no longer needed.

The second item, cultural oddities, is also interesting. Each journal has some part of their workflow that is peculiar to them. At a certain point actor x has to do something. It is generally not a huge deviation from a common path, but it exists and is significant. A senior academic, for example, may need to bless and article before it is finally published. Or the Handling Editors need to discuss an issue on a paper before they advance it to the next stage. It could be a one of a number of things. The point is, if you are designing a new system, it is easy to see these oddities as complexities to the workfow and it can be difficult to work out what the workflow actually is. It can seem enormously complex. However, the reality is that these are small deviations from a generic common path (as described above). If you can see this, then you can see the simplicity of the process and it is far easier to see these oddities as a kind of exception that needs to be accounted for rather than a major deviation in the path of the document. It makes designing systems a lot easier.