Pages, proofs, and possibilities

In this episode, Arthur talks about that with editor and entrepreneur John Pettigrew, the founder of Futureproofs. How can we innovate in this part of the publishing process? And what lessons can we learn here about innovation in publishing more broadly?

Links from the show:

• Futureproofs
• Book Machine
• The Chicago Manual of Style
• New Oxford Style Manual
• Butcher’s Copy-editing
• The Elements of Typographic Style, by Robert Bringhurst

Transcript

Arthur Attwell 0:04
Welcome to How Books Are Made, a podcast about the art and science of making books. I’m Arthur Attwell.

Arthur Attwell 0:22
I think it was the legendary poetry publisher Gus Ferguson who said that it’s important to leave a mistake in every book, because it gives readers such immense pleasure to spot them. Of course, as humans, we don’t struggle to leave errors in our books. Books are enormously complex creations.

Arthur Attwell 0:40
If you think about it, in a 60,000 word book, at least 60,000 different things can go wrong. They seem to crop up not just in patches, but in layers, so that finding them is a kind of archaeology. You’ll clear a bunch away, return the next day and, with yesterday’s layer cleared, unearth new ones, over and over again. It takes immense repeated effort to dig them all out. Importantly, it takes a team. The author will clean up their own work as best they can, helped along by spellcheck. Then agents and publishers will note a few they missed and introduce some new ones. A copy editor will prize out several hundred more as they work more closely with the text. Finally, a proofreader that great, underappreciated last line of defense will scan every word and surprise everyone by finding an error on every page in even the best prepared manuscripts.

Arthur Attwell 1:45
I’ve never known an extroverted proofreader. They tend to be quiet, unsung heroes. Perhaps that’s why they are so under-appreciated, and why their corner of publishing has seen so little innovation. For the most part, they work with pencils and coloured pens, and a trusty stack of the great publishing reference books–Chicago, Oxford, Butcher, Bringhurst. Today, they’re being asked more often to mark up corrections on screen in PDF in hope that that’ll speed things up. I can’t tell quite why, but I’ve long had an uneasy sense that PDFs aren’t helping.

Arthur Attwell 2:29
I wanted to talk to someone who has thought more about this than almost anyone. Editor, geek, and entrepreneur John Pettigrew, the founder of Futureproofs. A scientist by training, book-maker by profession, and entrepreneur by compulsion, John thinks deeply and sensibly about publishing and technology. Every time I read his posts or talk to him, I come away feeling reassured about the future of fine book-making. John, so nice to have you on the podcast. Thanks so much for joining me here today.

John Pettigrew 3:02
Thanks for inviting me.

Arthur Attwell 3:03
I am really enjoying having conversations with people who are involved in all different parts of book-making. You’ve been making books for over 20 years. Tell me where that began? I’m curious, in particular, about your studies, which were not in publishing.

John Pettigrew 3:23
Like a lot of people, I went to publishing out of university. I’d done my degree and then I did a PhD. I’m a scientist by training, biochemistry, molecular genetics, that kind of stuff. To get a PhD, you have to make an original contribution to human knowledge. Mine was that I don’t like lab work and I’m not very good at it, but I did like reading about it. It’s kind of an axiom that researchers hate writing up, but love doing lab work. I hated lab work and loved doing the writing up. That was a kind of an early hint that perhaps, you know, books and stuff would be a place for me to go. Particularly when I wrote my thesis, and it was on the shelf next to the others, and it was literally half the size of any other thesis on my supervisor’s shelf. Fortunately, I got the PhD and that was fine. It’s one of those yeah, actually, tight writing is something that I’m kind of good at. So I thought, yeah, maybe publishing is a place to go. It took me about nine months to get my first publishing job. This was back in the mid-late 90s. I was working for Elsevier, I was what they call an assistant editor. I was doing the whole process after commissioning and acceptance, taking the journal articles through to publication.

John Pettigrew 4:36
What I particularly loved about that job (I was there for about, only about three years in the end because they made me redundant because they moved the office) was that it was a review journal, which meant they were commissioned articles that were trying to explain particular topics to an audience of specialists, but it was everyone from, you know, the one professor in the world who really understands it down to undergraduates who needs to learn it, which meant that the content was carefully written. It had to be right. It had to be researched, it had to be accessible to people, it had to be understandable.

John Pettigrew 5:10
So it took good editing, you know, you had, unlike a lot of primary research, which is kind of a sausage mill, we were, we were actually paying attention to the content. I love that, taking something, taking a subject people, the writers were passionate about, because it was their life’s work, and helping them to make it understandable, to make it make other people more aware of it. Primarily. I mean, this was in the days of galley proofs. We actually on occasion, we even I remember taking a craft knife to film in the office at the last minute as they had to move something around or correct it. But very quickly, we moved to onscreen editing.

Arthur Attwell 5:45
For someone who’s never seen film, let’s describe that, because I suspect quite a few people who’ve been publishing for the last 10 years might never have seen film.

John Pettigrew 5:54
It was an intermediate stage, after all the typesetting had been done. The typesetting was done on computers at this point, but you, you output, instead of just sending a PDF to the printer, it had to be output onto, I mean, it did go through PDF, but it had to be output onto a big big piece of transparency, basically a transparent piece of plastic of film. On that was the stuff that you were going to, we’re going to print. That piece of film is what was used to create the image on the paper.

John Pettigrew 5:59
Because you had a piece of film, right at that last stage, if there was a mistake that somebody spotted, obviously you don’t want to spot a mistake at that stage, you could edit the film, because you could physically cut a bit out and paste a new bit in. But it was a delicate task, not something you did lightly. From my early kind of experience as an editor was it was all about high stakes, high quality content, that was kind of what it was about. That’s what I’ve always loved about being an editor. Now, I’d say I’m kind of a recovering editor these days is how I describe myself.

Arthur Attwell 7:00
You moved from journal publishing into books specifically, were they very different? I suppose to you they weren’t very different because of the kind of journal publishing you were doing.

John Pettigrew 7:09
I was at Elsevier for about three years. I was very fortunate, kind of, as you say, that my first publishing job landed me somewhere that just clicked … it was, it was right. It was a great team as well. After that, I was actually a freelancer for about six years, which meant I was working for loads of different things, whatever someone would pay me. I was still doing a lot of work on the same kinds of high-quality journals, because that’s where I had my contacts. After about six years of that, I’d kind of enjoyed being by myself and having, you know, control. But after a while, I just felt I needed people around. You know, we’re recording this in, in kind of in the middle of COVID kind of crisis.

John Pettigrew 7:50
It wasn’t a deliberate choice, really, but I ended up working for an education publisher, doing school textbooks, but actually it was it was the same kind of approach. It’s that high stakes content, that in a particularly, you know, school textbooks. I love to work on that kind of stuff. Because you know, it’s really important. Education is an important thing. If you’re producing a good resource, you’re going to help someone get on in their life, they’re going to get the better results and this kind of thing. I loved that. That was really the kind of place that started leading me on this slightly divergent path, eventually, over years, kind of gradually, step by step to not being an editor anymore, which is slightly odd.

Arthur Attwell 8:32
Absolutely. At some stage, you must have become more interested in technology and what that might offer. How did your technology roots and entrepreneurial ventures begin from all of this?

John Pettigrew 8:45
I’ve always been a bit of a geek. I mean, editors, we tend to have a bit of a nerdy tinge to us because we’re very detailed people. But it was in, within the first year or so it was quite evident back in, this was back in the, well, it would have been mid-noughties. We’re publishing textbooks, so all textbooks had a CD in the back of them. Because digital resources were the thing, you had to have digital resources. So we were doing that. We were starting to go okay, well, actually, we need to have a website as well now, because or instead, and how do we do that? A lot of people in the in the team were not really experienced at handling any of that kind of technology. I’d done a bit, I’d done a bit of internet stuff back in the 90s. Because I was in my 30s at that point, you know, and so I started helping people out with this, that, and the other. It gradually ended up being more and more that I was the techie one in the group more by accident than by design. But we were you know, new stuff was happening, the iPhone and the iPad and this kind of stuff. The business started going, oh, well, we have to do something cool with apps because everyone’s doing cool apps.

John Pettigrew 9:44
We did an iPhone app, which literally went, no. What we did, we produced the app, it was great, was repurposing old content, taking quiz content from our English-as-a-second-language stuff, and kind of gamifying it a bit with the quizzes and stuff. But that just dropped off a cliff. Then, a couple of years after that the mandate came down that we had to do iPad apps. I worked with the academic group to take XML resources about the Shakespeare scripts that we had and all of the assets the education group had around the interactivity and performance and photos and audio and this kind of stuff and putting them into that. I worked with Dave Addy and his team. We won some real acclaim from people at The Guardian, we were in their top 50 apps of the year, two years running with those, which was lovely. Again, commercially, they dropped off a cliff, because the publishers didn’t know how to sell them. It was a very different way of selling. But look, we learned a lot about putting products together. Because putting a book together, we kind of have done that, we’ve done that over and over and over and over again, we knew how the budgets worked, we knew how the timing was going to work, we knew how the workflow is going to be. Doing so many digital products, you don’t have any of those things. It was really exciting and interesting, learning how to put some of those things together. At the same time, some of those answers in the traditional workflow are starting to break down.

John Pettigrew 11:07
Now, as I alluded to, when I started in my journals publishing back in the 90s, the manuscripts would come in as type scripts, sometimes even as manuscripts literally handwritten. They would have gone be rekeyed and you’d have to edit, we’d edit on paper and stuff. We were, everything was still, particularly the proofreading stages, everything was still happening on paper. Big piles of paper being posted around the world, which to that point had worked really, really well, because it’s well understood, it’s very clear. The paper is how it’s gonna be produced ultimately, anyway, so kind of looking at it on paper makes sense. But the commercial pressures were increasing on us, as on all publishers, and that’s just accelerated. Our being asked to do more, more quickly, with fewer people, for less money. You can’t do all of those things without changing how you go about stuff.

John Pettigrew 12:06
Some stuff we could we could use more outsourcing, blah, blah, blah. But one of the big sticking points was proofreading because the proofreading stage cannot be skipped. There’s no good producing a school textbook if the answers to the questions are wrong, or if the explanations are wrong. All of these things have happened. There are some horror stories out there about whole print runs being pulped, because there’s a mistake. So you have to do it. For a textbook that’s around, you know, 240, 300 pages, the whole production shedule might be about nine months long, ideally a little bit longer, but we like nine months. Of that, about four months was proofreading.

Arthur Attwell 12:45
For those who don’t know the publishing process very well, where does proofreading fit in?

John Pettigrew 12:50
Yeah, so you know, it’s been written, it’s been sent in. It’s gone through a process of development, where either an in-house commissioning editor or an out someone out of house has gone through it with the author in some detail, looking at structure, looking at how things are explained. Where do you need more examples? Where do we need artworks? What should they be? All this kind of stuff to make sure it’s kind of as good as it can be. After that you copy edit it. The text has come in, but you need to go through and look at the detail. You know, do the paragraphs actually make sense? Does it flow properly, that the points build one onto another? Are the technical terms used consistently? Is the spelling right? Is the grammar right? Is it pitched at appropriate level, all of those kinds of things. And, all of your artworks have to be properly and fully briefed. You’ve got to write a really good description of every artwork where it needs to go, every question needs to be checked, the answers correct, all of the detail needs to be sort of gone through. Once it’s copy edited and corrected, it goes off to somebody to typeset. Previous to that you’ve done a design. You’ve come up with how it’s going to look, how it’s going to appear on page and be structured. You have to, someone’s gonna take that design and put the real content into it, into a whole book. Usually InDesign, because you, it’s generally design-lead content. XML is great at the things it’s good at, and terrible at the things it’s bad at.

Arthur Attwell 14:11
[LAUGHS] That’s a great description.

John Pettigrew 14:13
Educational content and a lot of trade nonfiction is non-structured, or only partially structured. It’s quite hard to fit into a template. There’s a lot of work, really interesting work going on about that. But it’s still primarily InDesign there. But once you’ve done that, that’s only the beginning of the checking process, because that’s where proofreading kicks in. Classically, proofreading is checking that the input equals the output. Has everything in the manuscript, in the copy edited typescript, actually appeared in the typeset book? Are there any sections missing, has anything got the wrong style? Is it in the wrong order?

John Pettigrew 14:53
Realistically, you expect your proofreader to do a lot more than that, to do the same job as a copy editor did. To check that same detail of actually, you know, second set of eyes, second proper read, does it all make sense? Checking again. Also, they’re going to be looking at, at a much higher level to look at the page and go, does that page work as a designed object? Is the artwork the right size? Or would it be better if it was a bit thinner? Or half the size? Or on the other column? Or something like that. You know, does it work? Is the layout correct? Or is the page balanced? Are the answers near the questions? All sorts of stuff that needs to be checked. Then of course, they also need to consider what’s going to happen as a result of your requested change. If I make that artwork smaller, I have to fill the space with something. Or if I make it bigger, the stuff that used to be there has to go somewhere else. Where is it going to go? How do I make space? So you’re often checking, text flow, fit, you know, all sorts of stuff around structure and stuff. All of those things are encapsulated in what we tend to call proofreading. It’s basically the whole QA of the typeset object. In most publishers, it varies enormously the number of stages you go through. Some publishers get away with two. That tends to be simpler content, novels and business books and stuff where you haven’t got a lot of complexity. They will check it once, get it corrected, a new version comes back, you’ll check again, maybe make a few tweaks, but then you’re hoping to sign it off and it’s going to go. Education stuff and trade nonfiction, high quality magazine type content … three or four sets of proofs. I do know publishers who habitually hit a dozen, even more sets of proofs and that drives me nuts.

Arthur Attwell 16:43
That’s kind of a red flag for a process problem.

John Pettigrew 16:46
Yes, exactly that. It’s a case of there’s no reason to be doing all of that at this expensive stage of the process, because this is post-InDesign. changes are now quite expensive to make them manual. They involve a lot of tweaking, and really, if it’s a content change, it should have been caught earlier, you can change it in the Word file. Then when you typeset it, you only have to do that work once. This is kind of in a sense it overlaps, as I know, you know, you folks at Electric Book Works have a not, are heavily into the automated workflows where you can make structural changes in the source file, and hopefully all pours through into an automated output. But you know, there’s always a manual element anyway.

Arthur Attwell 17:27
Even with our process, we have to check proofs, PDFs, to make sure that output is correct. Often a human will have to intervene for that last five or 10% of layout that the machine can’t handle.

John Pettigrew 17:40
I mean, yeah, it’s one of those things that, you know, it’s one of the great things over the last 25 years in publishing has been seeing the appropriate use of technology come into the work we do. I say, I’m an immense believer in the value that human beings bring to the process, which is almost why I don’t think you should be wasting that human skill and passion. Checking that there are no double spaces in the whole document manually, one at a time? Search and replace! Use computers for the routine stuff they’re good at and liberate your team for the skilled stuff they are good at, then your team have a better time and your books are better, and you can produce more stuff more easily. You know, it’s a win for everyone.

John Pettigrew 18:23
You know, on-screen editing when Microsoft Word, that was an accidental win, because Word was not designed for us. It was designed for businesses. It developed and gained all sorts of abilities that turned out to be useful for us in publishing. So we’ve got search and replace, we’ve got spellcheck, which is kind of useful. So that was great. Then we got styling. So you suddenly cut out the stage where you either have to go through galley proofs and mark this as a heading one, this is heading two, this paragraph, this is an indented paragraph, this is a bulleted list, just by hand, tagging everything. But if you start a Word file, then it automatically pulls into InDesign, and it’s already styled in the correct way. So that’s great. Other parts of the process haven’t really gained that level of automation yet. I mean, silly stuff like you know, there are scheduling systems out there, but for a lot of people are still drawing up manual schedules in spreadsheets.

Arthur Attwell 19:15
Yeah. They’re also using tools that were not made for publishing.

John Pettigrew 19:19
Exactly that. Some stuff it works, where you can take something generic. I mean, I know you folk use some project management software. That’s a, that’s an excellent example of why would we build publishing-specific project management? Because project management’s kind of a general skill. So if we can bring in something that’s really good, let’s do that, and then let’s build the stuff that’s specific to us when we need to. So you know, the specific workflows that we have, like the stuff you folk are doing, that makes sense because you know that no one else really does that in the same way. We know the problem, so we can solve it. That’s where I ended up doing setting up my own business because I got so annoyed, managing an editorial team being asked to do more, with less, more quickly, more cheaply, being stuck against tools that simply don’t let us do it because traditionally, we worked on paper. That had its advantages, but it was slow. It’s expensive. It’s not great for collaboration and all these kinds of things. The only onscreen option we had was working in Acrobat. Proofreading in Acrobat is horrific because it’s not designed for that job. It’s designed to, well, actually originally, it was kind of designed for a print document to be distributable electronically. Its got some markup tools, but it’s very, very limited. As proofreaders, we had over the decades evolved some very sophisticated ways of marking up paper proofs so that everything was very efficient, and very quick and very clear. So if you want to delete a piece of text, you draw a line through it and put a squiggle in the margin.

Arthur Attwell 20:48
It’s a very specific squiggle. Right?

John Pettigrew 20:50
Exactly that. And if you wanted to make something italic, you’d underline it and put different things, a symbol in the margin. Everything had its own symbol. There are various different standards. The British have the British Standard, the BSI markup, the Americans have the Chicago Manual of Style, there’s an ISO standard. But you have this system. When you go to InDesign, all of a sudden, you have post it notes. That’s all you have. Well, there are five, you can strike text through, you can underline it, you can highlight it, and you can insert text and type. That’s it. It’s like, I mean, I would liken it to working with boxing gloves on, you’re kind of bashing at it, but you can’t get the accuracy, and so it takes longer. It takes 20, 25% longer to work on screen and Acrobat than it does to work on paper. Because you have to write everything out longhand. Please take this piece of text, move it over there. This text should be Helvetica, not Times New Roman. Whatever. You have to explain everything.

John Pettigrew 21:47
Any time computers are making your life harder, something has gone wrong. It’s a sign that there’s a problem there. There must be a way of doing proofreading on screen that isn’t completely horrific. Well, actually, the genesis of it was I was at a conference in New York, the old Tools of Change conference with some friends, Laura and Gavin, who founded BookMachine. They were talking about how they started BookMachine and the problems they were trying to solve for that. I was walking back to the hotel, after dinner and thinking, you know, you could do that with software. Yeah, that would work. By the time I got back to the hotel, kind of a 20-minute walk, I had in my head the genesis of what became Futureproofs.

John Pettigrew 22:27
That was fundamentally about, was about exactly this thing of precise markup. Because computers are bad at random stuff, at ill-defined stuff. They’re good at well-defined stuff. As copy, as proofreaders, we had these proofreading standards and symbols, and a structure. It was a case of, Oh, computers like structure. So if I can connect the symbol to the structure, yes, that would work. A bit of this and a bit of that, and, and that there were three key ideas. It was about gesture-based markup, it was about collaboration, and it was about data, project management. All of those three things were basically in my head by time I got back to the hotel. I pondered it over the next few months, and I talked to people and did research and so forth while my team was still struggling, trying to make this whole thing work. Eventually, I was made redundant. I thought, excellent. That’s good timing. And so I started the business.

John Pettigrew 23:24
But it’s still that thing of finding the right tool for the right job, as you say. Tools from outside can be great if they happen to solve the problem that we’re solving. The problem I had was Acrobat was solving a completely different problem, and didn’t really solve the problem of proofreading. The the issue I think that publishers have at the moment, is they’re doing one of two things. They’re working on paper, or they’re working on a PDF with Acrobat, or Foxit, or Preview or whatever piece of software, they all work the same way. Because it’s the same file format. It’s about half and half, I reckon these days, there’s still a lot of people working on paper, and a lot of people working on screen. Most editors I talk to put up with working in PDF, because they think it’s the only way. Most people don’t have, aren’t used to the software world where you can just create a tool. That way of thinking that actually the world could be better if only, because most of us are too busy doing our actual jobs to be able to step back and go, ooh, yes, you know that there is, there is a better way of doing this potentially.

Arthur Attwell 24:27
Yeah, actually feeling a pain point here. I think being aware of when something is making you feel a little bit resentful, is a good signal. I remember my mother, who was a great publisher many years ago, saying, when you get that resentful feeling in the pit of your stomach about the work you’re doing, it’s because it’s not your job. What you’re doing right then is not what you’re meant to be doing.

John Pettigrew 24:51
I mean, it is interesting when, I’m not a natural salesperson, but when I go out and sort of talk to people about Futureproofs saying you know, there is a better way. Generally, if you go and try and sell things to editors, they sit there with their arms crossed. and just go, no, not interested in new stuff, I know how my job works, I’m just gonna stick with that. But within about five, 10 minutes, I can see them start to lean forward, and go, ooh. Because most of the time as a person, when you’re publishing, when you’re being sold to you being sold to by tech people who have a shiny toy they want you to buy. I’m not that. I’m an editor. I’m, I always come at it with you know, here’s a problem that I’ve had, I think you might have the same problem, and here’s how I think I’ve solved it. The message is always, you know, if you’re happy with how you’re working, great, that’s brilliant. If you’re not happy, maybe here’s a way of improving things. I think that’s the, making that step to change can be good, can be, can be the trickiest thing I think, for a lot of people, a lot of teams, just because they’re busy in part, I think.

Arthur Attwell 25:52
They’re super busy, and usually a new tool requires some kind of investment, usually money, right? And often time, obviously, and that feeling of risk when you change your workflow. One of the difficult things with the money side of it is that usually you’re buying the tool because it’s going to save you time. Therefore, the money you’re saving is in salaries. That’s very hard to measure in companies. Weirdly, it’s almost, well, this new tool is going to cost us X to set up and to run, but you don’t have any direct cost compared to, you’ve got to somehow quantify your salary time, which is surprisingly difficult. It also means that those of us who are selling technology products that we know will make people’s lives easier have a hard time sometimes helping people do the maths, do the cost-benefit analysis. That must affect, you know, much more than just Futureproofs. How do you approach that?

John Pettigrew 26:51
It is a big one. I mean, I’ve once, to be fair, only once or twice come across the kind of extreme version of that where for us, we’re focusing on proofreading, and we charge people money to use our service to make proofreading go more smoothly. I’ve only once or twice come across the thing where they expect to make all of these the money they pay us back in reduced freelancer costs. Yes, you are going to save a bit of money there. But most of it is your in-house team. As you said, it’s that salaried employee, where they’re spending time chasing around after project status data. They’re spending time chasing over what what work has been done. They’re spending time desperately trying to find what changes have been made on that version, while all they’re dealing with an author who’s complaining that changes have been made on their book when they never said they could that that should happen. You know, you’re chasing through piles of paper or a history in an email chain or something. That’s a lot of wasted time, like you say, it’s not the stuff you became an editor to do. You want to spend your time on the book.

John Pettigrew 27:48
We have kind of a, kind of various places where we say you know, you’re going to save money here, you’re going to get an ROI of you know, two or three times what you spend, or whatever it might be. Every publisher is different in their own workflow so I don’t honestly think there’s a generic answer to this. It’s always a case of listening to a particular person or particular publisher and saying, Okay, great, I see how you’re working, here is probably where you’re gonna see the benefit. For us where people see the benefits, they save some time in markup, they do, because it’s more effective. The big win there, as much as anything is annoyance, that, that the editors are less annoyed. The freelancers and authors are less annoyed with their work, which is kind of a very hard thing to quantify. But we do see some savings there. We see a big saving in collaboration, and communication, because it tends to be very siloed and disparate and scattered. There’ll be some emails, there’ll be some phone calls, and there’ll be some things written on pieces of paper, and then some things written on the proofs themselves. We try and bring all of that together, make it more manageable, less email, less random phone calls and stuff, because its all right there. That is, was an unexpected big win.

John Pettigrew 28:55
The third one is in terms of insight, and then that’s again hard to quantify, because publishers are used to not knowing stuff. They’re used to not knowing how the project is going because they’ve sent the stuff out of house. They used to just think, well, I’ll know when it comes back. They’re not used to being able to go, Oh, well, I can see the author spent four hours on it and they’re three quarters of the way through so it’s probably gonna come back on Thursday. But we can tell them that, we can show them, we can give them data about overall performance, you know, how many corrections being made in all your projects, how many of them are sort of editorial changes and how many of them are designer errors? What types of change are they? You know, there’s, what you can do with data is really interesting these days. We catch it by accident, because you have to catch it to do the mark up, but you can then start to analyse it. That’s kind of really interesting to me. Again, quantifying that, I think it’s less, it’s less about being able to get an ROI figure for us quite often. It’s about being able to give a business case, because some of that stuff is new, so that you can say okay, it can cost you X amount and you’ll save Y ammount in direct cost and Z amount in indirect costs. But you’re also going to gain these capabilities that you’ve never had before that are going to make your life as a, and very often as a manager, much better.

Arthur Attwell 30:12
Yeah, absolutely. There was a time when you could define publishers as this very particular industry sector. It’s just impossible to do now, the sector itself is broader and more diverse. Increasingly, any organisation can be a publisher. The people you’re speaking to, what kind of organisations are they actually running these days?

John Pettigrew 30:33
Yeah, it’s interesting. I mean, the company, there are two sides to that, aren’t there. We talk to a fairly defined group of people who are publishers in the traditional sense, who are doing high quality, high stakes, illustrated content, by and large. We do deal with some nonfiction text and some fiction text and stuff as well. But primarily, it’s the people who have a high investment in the proofreading stages, because that’s what we do. It’s fascinating, fascinating, last 25 years watching what we used to think of as publishing, fragment and break apart. We used to think publishing was an industry. Now you look at it, and you think, yeah, I mean, realistically, what have science journals, and erotic fiction got to do with one another? Other than that they used to produce their product on a printed Codex. They have different commercial models, different audiences, different business structures, different content types, different everything, you know, there’s almost nothing but they’re both publishing somehow.

John Pettigrew 31:32
There are other businesses that publish, but they were never part of the publishing sphere. Standards organisations, banks, engineering firms produce huge amounts of printed content. We sit kind of deliberately, within publishing, traditional publishing. Because the language we speak is the language of publishing. We talk about proofreading, we talk about editors and authors and typesetters and designers. We keep looking each other and going, you know, we know we could take this into finance, or legal stuff, or you know, where they have similar document quality control issues. There are definite advantages that are, but we’d have to change stuff, we’d have to change the language, we would have to change some of the workflow and stuff. So we haven’t done it yet.

Arthur Attwell 32:21
That’s really interesting. I think that there is so much to be said for software that knows who it’s for. We’ve found ourselves in a time, in the world where everyone expects every technology project to do everything for everybody. That’s the exact opposite of good software, good software does a very particular thing for a very particular kind of person. I for one, I’m really chuffed that you are producing software for publishers by publishers, because, as you’ve said, so much of the software we use in publishing was created in other industries, and then we co opted it in publishing, which means it isn’t quite what we really need. Then we end up hacking our way along and getting annoyed with it. So so that’s fantastic.

Arthur Attwell 33:04
Increasingly, it would be nice to see more of those. Do you think it’s simply a matter of growing technical skills within publishing to start seeing other new ideas and approaches emerge? Or do you think that because of the nature of publishing, book-making, publishing will always be about the quality of its products, and there won’t be a lot of people in publishing, working on the nature of the tools? Is all that criticism of publishing, being slow, unfounded, perhaps?

John Pettigrew 33:37
[LAUGHS] Publishing is definitely slow, and it’s definitely, has a traditionalist mindset. Because if something works, why break it? The situation we’re in is that some things have broken. If you’re in a situation where something has broken, and you’re not acknowledging that, then you have a problem. I think actually, both things you suggest the true, I think, there will always be a minority of people in publishing who are interested in that, in fixing process. Because that’s just human nature. Most people don’t care or don’t care sufficiently. That’s perfectly reasonable. But you need enough people who care, otherwise, you’ll never solve your problems. We should be fostering that mindset of, Yeah, this is broken. Why? How can we fix? Or, ah, don’t really think that’s where, how we want to be doing it. I know we’ve done it that way for the last 10 years. But did we do it that way deliberately, and is it still the right answer? The way I think you empower those people, first of all, you’ve got to foster them, and encourage that mindset and freedom. Once you’ve got them, you need some of them to have some technical skill and insight. Otherwise, they won’t be able to see the solution. It’s that creativity, I think, that’s going to take us forward.

Arthur Attwell 34:56
Fantastic. John, where can people find what you’re working on now? Are there other projects you’re working on now that we should point people to as well?

John Pettigrew 35:05
Well, yes, Futureproofs lives at wearefutureproofs.com. If you want to know how to do proofreading on screen better, come talk to us. I mean, talking about kind of learning to code and stuff, I am involved in a second project. I’m working with a friend on a business called Umbrella Analytics, where we’re taking technology and data and applying it to the problems of diversity and inclusion in our businesses. Having some ability to take code has meant that we can build something that’s genuinely useful and really exciting, as you can tell, but that’s a whole different thing.

Arthur Attwell 35:39
Well, it’s a fascinating topic, and one that is part of publishing as well, so maybe we’ll get to talk about it one day. John, thank you so much. It’s been an absolute pleasure and I’ve learnt a lot.

John Pettigrew 35:48
Thanks. It’s always good to talk to you.

Arthur Attwell 35:52
You can send us your own book-making topics and conundrums and questions at howbooksaremade.com and we’ll tackle those in future episodes.

Arthur Attwell 36:00
How Books Are Made is supported by Electric Book Works where my team and I make books all day, every day, in sunny Cape Town, South Africa.