Giles Turnbull, Author of The agile comms handbook

Len: Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Giles Turnbull.

Based in Bradford-on-Avon, Giles is a communications consultant who, after an earlier career as a journalist writing about the internet and computers, founded Use the human voice, a company that helps both public and private organizations find their voice through clarity and brevity, and bringing a thoughtful, human tone to the ways people think and speak about the work they do togehter.

You can follow him on Twitter @gilest and check out his website at usethehumanvoice.com.

Giles is the author of the book The agile comms handbook: How to clearly, creatively work in the open.

In the book, Giles offers readers a set of ideas and techniques to help teams communicate about work in progress, adjusting how they communicate in changing circumstances, while at the same time adding a flair of creativity to what they say and how they say it.

In this interview, we’re going to talk about Giles's background and career, professional interests, his book, and at the end we'll talk about his experience writing and self-publishing his book.

So, thank you Giles for being on the Leanpub Frontmatter Podcast.

Giles: Thank you very much for inviting me. It's a pleasure to be here with you.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you found yourself in your first career as a journalist, writing about the internet and technology?

Giles: Mostly through a series of accidents. I grew up in the southeast of the UK in Kent, by the sea. And now I live in the southwest of the UK - slightly too far from the sea, to be decent. I would prefer to be closer to the coast than I am.

I ended up in journalism in the early 90s, mainly because I was one of those people - and there were a lot of them, and I suspect there are probably still a lot of them now - who got to the end of an undergraduate degree, and still had no clue what to do with their life. That was me.

While I had been studying my undergraduate degree, I had written occasional contributions to student newspapers and student newsletters. So it was at a fairly drunken party, where a friend of mine said to me, "Why don't you go into journalism?" Because that was exactly what she was doing. She had got her career much better planned than I had. And I said, "Oh yeah, maybe I'll give that a try." So I did.

I went and did a journalism training course, which taught me a few things. But most of what I really needed to know, I learned on the job.

I got my first job on a newspaper in Cambridge, in the UK, called, The Cambridge Evening News, back in the days when small regional cities could have their own daily newspaper. I learned the basic skills there.

One of the things that happened to me in Cambridge in the early 90s, was that a cyber café opened about ten minutes' bike ride from my house. This was when cyber cafés were a new and exciting idea.

At the time, as far as I'm aware, there were only cyber cafés in London in the UK. This was the first one to open outside of London, and it was just down the road from me.

So, I went and visited it. I wrote an article for that newspaper about the cyber café, and I continued to do so. I got to know the owner a bit, and he let me have some free time on the internet, which was quite a big deal. I taught myself about the internet at this cyber café.

Fast forward a couple of years - a journalist friend of mine, had got a job in London with a news agency called the Press Association. She phoned me up and said, "You know a bit about the internet, don't you? We need someone who can write about it. Do you want to come down here and do some work for us?"

So, I ended up being a journalist about the internet in London, almost entirely by accident. That was the beginning of a specialist career in writing about the internet and technology and computers and software, and stuff like that.

Len: I have to ask you, because it's a bit of a kind of a running theme on the podcast, because I moved to London a couple of times myself - what neighborhood did you move to when you moved there?

Giles: Initially I stayed in my Grandma's house in the very north bit of London in Edmonton. That was just a few months. Then I got married, and my wife and I bought a house at almost the diametrically opposite side of London, in the south - in a place called, Penge, which is near Croydon and Beckenham and that sort of area of South London, if you know that?

Len: Yeah, I used to live in Beckenham Hill.

Giles: Okay.

Len: Briefly, yeah.

Giles: There you go. Practically neighbors.

Len: Thank you very much for sharing that. Actually, just very briefly - what was that like, moving to what they call the Big Smoke?

Giles: It was fine. Both my wife and I at the time had jobs in the center of London. This is the mid-90s at this point, when property was affordable. We were earning peanuts, and we could still afford a small two-bedroom house. So we did.

We chose where we lived based entirely on commuter railway lines. We basically followed the commuter railway line out of Victoria Station and worked our way southwards to a point where we could afford a house, and said, "Right, well we'll look there and see if we can buy one." We found one, and we did.

It was a good time to live there, because a lot of our friends lived not far away. So we knew a lot of people in the area, and that was nice. It didn't feel very big smoke-y, to be honest, because it's the suburbs of South London. It doesn't feel like the big smoke at all, it feels like quite a small smoke.

Len: Yeah, it's funny - actually one of the reasons I ask about the neighborhood is that - I mean, everybody knows this about every big city, but where you actually live is very different, it's not all just one place.

So, there you were. You were the first internet correspondent for the Press Association. It's sort of funny - I've interviewed quite a few people on this podcast, who found their ways into careers in technology one way or another.

But for people who kind of came up in the 90s, it's - a pretty common thread is, "I was the only one at the company who could make web pages. I was the only one in town who could set up a server rack." That kind of thing.

I'm sure that's true of any sort of new thing. People don't expect to, but they find their way into it through accidents, like being the one at the internet café who has access for free.

I was just wondering if you could talk a little bit about what that was like? I mean, there you were at the beginning of the web writing about things - did you have any big scoops or anything like that?

Giles: No. Because I was a terrible journalist.

Len: Okay.

Giles: It took me several years to grasp this. I didn't realize I was a bad journalist at first. I'm not a bad writer. I can write okay. But I didn't have the hunger for the story that good journalists have, because I really wasn't that motivated. I didn't really care much.

But the crucial thing that happened in those years for me - as you've pointed out, is - at the time there weren't many people in journalism who really understood how the internet was working, and the potential that it offered, and the consequences that were enabled by it. I wasn't the only one at the Press Association. There were other people there, but we were a small group.

I made the most of that, and I made the most of the opportunity to meet lots of people and make lots of contacts in what was then, quite an exciting scene in London. The first dot com boom, I suppose it must've been? When there were loads of new companies starting up. There was lots of exciting internet activity happening. There were lots of people to go and interview and talk to about all sorts of things, which is what I spent a lot of my time doing. It was largely because I made those contacts and met some of those people, that some other interesting stuff happened later on in my career - that I suspect you might ask me about in a minute.

Len: Yes. Actually that was where I was going to go next. I'm just sort of going in reverse order on your LinkedIn profile here that I'm looking at.

Eventually you ended up being a consultant for the government, and actually being a civil servant - is that what you were expecting me to ask you about next?

Giles: Yes.

Len: That was about like 2010 or 2012, or something like that?

Giles: Yeah. So there was a decade in-between, when I was mostly freelancing and doing childcare, just juggling those two things at the same time. But then, towards the end of that decade, some of the people that I had got to know as a reporter writing about the internet in the late 90s, they started to get involved with government in the UK. Particularly with the creation of a new website called GOV.UK, which was created to replace literally hundreds of government websites that existed at the time. All of which were funded differently and commissioned differently.

Some of them were good, and some of them were bad. None of them shared any common navigational techniques or common methods of writing copy, or anything like that.

So a small team was created in government, to start doing something about that. They built initially an alpha, and then a beta of this new website, called GOV.UK. The team was growing and growing and growing, and it took on more responsibilities within government. Not just making GOV.UK, but doing other things as well. Things that consultants would label under the heading, "Digital transformation." But not everybody likes that term, especially quite a lot of the civil servants.

I got a call during this process, at the point where the team was trying to expand its influence, mainly with the rest of the British civil service. They wanted to make their work make sense to the rest of the British civil service in Whitehall, which is thousands and thousands of people.

So, they hired a small creative team of writers, filmmakers, photographers, producers - and I was one of the writers on that team. Our job was to make GDS - that was the name of the organization - understandable, make it accessible, make it visible to the right people.

Len: It's a really fascinating subject. Just to build a little bit more scaffolding around it a bit, I memorized the number - I think it's 1,882, from a couple of talks that I'll link to - that you've given, that are on YouTube, that people can find - actually relatively recent ones as well, talking about this. So there were 1,882 or so UK government websites, all of which had been commissioned by different people, and designed and built by different people. As you say, the quality varied - some were good, some were bad. It was collectively a giant mess.

Particularly with respect to the way people think about the government. They think of it as a unitary thing. Like, "I want to talk to the government. I want to find out from the government what things are."

So, after this initial kind of Cambrian explosion of diversity and evolution, people realized actually, diversity and evolution are good things, but there should be a central coordination behind this.

Very particularly - one of the interesting features of the culture in the UK - there are groups that advocate for measuring how much beer foam gets in people's beards. Not joking. So you can make sure people aren't being taken advantage of by paying for a beer they're not drinking.

But there's also clarity associations. There are actual groups about like, "Public speech should be clear and understandable by people." People listening might be thinking, "Oh it's like -" This is actually from the ground up. It's the government doing it, in response partly to some catastrophic IT failures as well.

But the idea was like, "Let's really think about it. Let's really simplify it, and let's be coherent about it."

I was wondering if you could share a little bit about what your experience was working on this very important, formative project. I know there was, for example, a poster that you made, with a yellow poster, to help people get on board with new jobs in an organization, without having to read a 80,000 word document.

Giles: I'll come to the poster in a minute. You asked what it was like working on this transformative project. It was transformative for me. It changed my life. I have a strong feeling it changed quite a lot of lives of the people who worked there, and still work there to this day.

Because - that might sound hyperbolic. But it genuinely did make an enormous difference to my career. Because I learnt so much, because the organization was full of so many smart people - who were so much smarter than me. I was able to spend a few years learning an enormous amount from my colleagues about the nature of good communication.

What I say in the book that I wrote and published on Leanpub, is - I wouldn't have been able to write it, had I not had that experience learning from those colleagues. Everything that's in it came from working with them.

In terms of the day-to-day experience of it, it was exciting and challenging - and sometimes stressful, sometimes a great deal of fun, working with a spectacularly talented and lovely team of people, who were the creatives and the communicators in the organization. That was a privilege, frankly. I consider myself profoundly lucky to have had that privilege.

Government had not - before GDS came along - you made this point about how the people on the outside, the citizens see the government as a single entity. That is true. When people are talking about dealing with government, they very rarely refer to the particular department that they're having to deal with. Sometimes they do, but not very often. They will usually just say, "Oh, I had to apply for a new passport. I had to get a new driving license. I phoned the government." "I wondered where my - I didn't know what was happening with my benefits, why haven't I had my benefits? I'm going to have to call someone at the government."

Part of the point of the GOV.UK project, was making sure that information about - what is behind the scenes, an immensely complex set of organizations - making that all appear as clear as it possibly can to the end user, to the point where they don't need to know what department they are dealing with. They don't - there simply shouldn't be - that is not something that they should have to worry about or care about. GOV.UK - as a whole, was designed and built to meet needs of users, rather than needs of organizations, departments.

So it wasn't about, "I work in the Home Office, and I need to publish this information about passports." It was all about, "I am a citizen, my passport has only six months left on it, and I need to apply for a new one. Tell me what to do. Give me a series of steps to follow. Step one, step two, step three. Just make it easy for me - so that at the end of it, I get my new passport and I can go on holiday." It was all designed with that in mind.

The clarity of the communication was something that ran as one of many threads through all of that work. Our team's job was - we weren't working directly on GOV.UK, the product. We didn't help build those web pages. We have very little to do with that part of the work, because there was another extremely talented team doing that.

Our job was explaining that work to others. That meant that as GDS continued to grow and expand, we had to explain that work to people who may or may not want to come and work for us.

We were recruiting like mad. Loads of people were coming and joining the organization. So a lot of the open working that we were doing - a lot of the publishing, blog posts - and stuff like that, about the work - had this fantastic side effect, which was that it helped people understand us. That helped - once they'd understood us, that helped them make the decision, "Should I apply for a job there or not?" We know this is true. People told us in job interviews when they arrived. "Oh yeah, I've been reading your blog posts. I really want to work here, because I've been reading about what you do, and it sounds really exciting and amazing. I want to be part of it." So we had that feedback loop.

One of the consequences of that, was that there was a time some years later, when my team was recruiting new writers, and I found myself idly wondering one day, "Wouldn't it be nice if there was something that told you the things that it's nice to know, when you start working here - but that it's nobody's job to tell you?"

So, I'd started writing a list. I shared it around the team, various people on the team chipped in with ideas. We edited that list as a team, and turned it into a finished list.

Then one of the designers, Sonia Turcotte, designer turned it into this gorgeous, eye-catching, bright yellow poster with black text on it. We printed a few of these and stuck them up on the walls.

It went down very well with the team. It went down very well more widely. It's an idea that's been copied and remixed now, by quite a lot of other organizations, quite a lot of other government organizations - not just in the UK, but around the world.

Most recently, last year, Google used the idea for some internal team activity that they were doing. They kept the yellow color, but they changed some of the words. They changed quite a lot of the words actually. So it's been a great joy watching that idea spread further and ripple outwards, and see the different ways that different teams in different organizations make use of it.

Len: There's actually a lot to unpack there. Particularly one of the driving forces behind a lot of this is the assumption that people are too busy, which is one of your theories. You tell this great story, explaining these things very clearly and at length and in detail, and it's fascinating to hear about how, sometimes when you're getting onboarded at a new organization, you might get - like I said, an 80,000 word document. you have to tick a box, as you describe, saying, "I read it," but no one does. Why is there an 80,000 word document?

Because there's all kinds of cruft and self-involvement that get built into working things when, and people forget that, a) everybody's really busy, and b), what are the actual needs that need to be addressed here? It might sound very simple, but actually the usefulness of a poster that's like, "Just look at this nice looking poster" - maybe I didn't even have to ask you, because it was eye-catching and you already looked at it. "Here are all the things that we don't normally say to each other, but should just be taken for granted. It's okay to say you don't know the answer. It's okay to say you made a mistake."

That's incredibly important. When we talk about, and we'll get to the book, agile comms, but when we talk about communications, people might just think, "Oh, how do I act in Slack?" Or, "How do I write an email?" But how you're communicating is all around you.

Giles: Yes. People are really good at verbal communication, it comes naturally to most people. Because you and I are doing it right now. Verbal communication is something that we all grow up with.

Written communication is different. Written communication is something that most of us learn at school. At school you get taught a set of rules about how to write. As you go through senior school, and you take the exams - in the UK, they're called "A Levels," in other countries they're called other things - but you take a set of exams that prepare you to go to university. If you go to university, then you are taught to write in another very set, prescribed way.

by the time you've come out of your education at whatever level, and you start in the world of work, my theory is that you've had years and years - you've had at least a decade of instruction in how to write in one particular way. The chances are that you're pretty good at writing in that particular way.

But it's not necessarily a way of writing that is well-suited for communicating complex ideas to busy people. It's not a way of writing that is particularly engaging or interesting or lively. Because, particularly, if you're one of the people who's ended up going through university, you are very strongly encouraged, in your essays at university, to not be those things.

Your job is to be an academic researcher, and to keep your writing as dry and as straight and as academic and as rigorous as possible. There's a reason for that. Academia requires that.

But when you come out of it at the other end, my theory is that there are still a lot of people who emerge from education into the world of work, and haven't learned how to communicate in an accessible way - how to communicate where you really need to understand the perspective and the circumstances of the person at the other end, who would likely be reading what you write. That is partly what the book is about.

Len: It's really interesting too, touching on the experience that people have going through the education system with writing. There's this one like, in a sense, negative feature of it, in that you're always being graded. You always have in mind that you're going to be giving this to someone to evaluate in a very particular way. There's probably going to be a grade, and that's going to carry with you forever thing, right?

There's some people who just don't care, and that's fine. But if you're really thinking about that context of writing, it's like, "My God," like you get conditioned to be quite worried about your writing, and how it's going to be received.

But the second negative feature it has, is that it's not time-stamped. What you produce is supposed to be, in a sense, finished and timeless.

This is one of the things you talk about. I think that you have this great phrase of, "Blog posts being a timestamped thought." That is a really fascinating idea. Because the thing about a blog post is that it is - and I bring this up, because I hadn't quite thought about it quite concretely in those terms before - but like, it's not just that it's timestamped. It's that that brings with it the feature of being part of a succession of events.

So, when you talk about writing about how you should be communicating with your colleagues, and with your stakeholders and your audience about work in progress - you've got to keep in mind that what you're producing isn't the final word, the final timeless answer. That this is part of a continuum, and people are going to drop into it at various times and places, and in various contexts as well.

Giles: Yeah, absolutely. The longest chapter in the book, by far, is the one about blogging. Because I have a lot to say about it.

Part of that is because of this experience I had in the 90s and the early 2000s, back in the days when blogging was new and exciting, and the big wild thing that we were all going to do on the internet forever. But then of course, social media came along and changed all of that.

The argument I make in the book is, "Yes, blogging is old-fashioned, it's old-hat. The only people doing it personally are old geezers like me, with nothing better to do with their spare time."

But it still has value as an activity for teams or organizations that want to tell a story over time. You don't have to call it a "blog," if that troubles you. It does trouble some people. You can call it something else. You can call it a "journal" or "notebook," or an "insights library." I don't know? It doesn't matter.

The point is - as you say, you have these timestamped thoughts - and you can link one to another. You can link a series of them together to create a sub story within the longer story. You can tell stories about teams, stories about products, stories about strategies turning into realities. All of this stuff you can do, with just something really simple and basic like a blog.

One of the benefits of that for an organization, is that because your blog is a storytelling platform, that each individual blog post is an empty box waiting for you to fill it with something engaging and something interesting. The more creative you can be in that empty box - you don't have to be wildly creative, just a tiny bit of creativity is all you need to really bring in readers who might otherwise be expecting something quite dull.

If, for example, they're coming to the blog to read about activity in a government team, they're probably initially not expecting something really fascinating. They probably won't be expecting that maybe someone cracks a joke. But if you can be fascinating, or if you can crack a joke - you've got them. You've got their interest, they're going to stick around longer. They're going to hang around for more. They're going to maybe come back to read about you again in future.

This is why I argue that this way of writing doesn't come naturally to a lot of people. It's something you can learn. It's something particularly that teams can learn as a team, with everybody on the team editing each other and encouraging each other to be more creative.

The upshot is that if you adopt these techniques and you do it right, you can end up telling a really interesting story about topics that, at first glance, most people would think, "Really? That's interesting?"

But you can make things like fishing licenses interesting. You can make things like technology platforms interesting. All of these different things. Even web development. The writing of code - HTML, CSS, JavaScript. But writing about that stuff, and putting it on the web, is usually not that interesting - unless you are a web developer. But you can make it interesting to everybody if you add that little sprinkling of creativity on top.

Len: When you mentioned fishing licenses and things being interesting, that reminded me about some recent controversy between France and the UK, post-Brexit, about fishing rights, and how that became quite the exciting topic. It reminded me, also - one of the organizations you've been working with is Defra, which is the government department that communicates and works with farmers in rural areas. Post-Brexit, they've been very anxious.

In addition to that, often - I come from a rural part of Canada, and I understand very well the often antagonistic, or at least suspicious relationship that farmers in particular, can have with the government. Openness in communication in things like blogs, or in explaining, "We don't know - we don't really know what we're doing either right now," can actually really help establish trust in a way that can seem paradoxical to people who think that actually what you should be putting on is a front - that, "We're never wrong, and we know exactly what we're doing," and that's the government that people want to relate to.

That's not true. If you show the mistakes, if you tell the story, "Here's what we learned," that "we're learning ourselves," that can really help draw people in.

Giles: Yeah, and that - that aspect of humility, of acknowledging that you - even though you are a government department with responsibility for policy in a particular area, acknowledging that you still don't know all the answers - that takes enormous courage. But there is a team at Defra, in that particular bit of the UK government, who have that courage. Their leader has that courage. She's a woman called Janet Hughes. She has been using a blog to communicate with the farming community about changes to government policy that have come about as the result of Brexit.

There used to be grants available, funding available for farms from the EU. That money is not going to be available anymore. So instead, the UK Government is providing money itself. But all of this is an immense change for an industry that doesn't feel like it's been well looked after by the government over many decades. There are quite a lot of people in Defra itself, who would very happily, readily admit, "We didn't used to communicate with the farming community very well." That relationship, it needed to get better. The way to make it better was to build trust with the community. The way to build trust with the community was openness and honesty and humility.

That's why Janet and her team at Defra are doing a terrific job of communicating in the open, with the blog. Where they are publishing lots of blog posts, they're publishing lots of podcasts. They are very clearly indicating that they are listening to the farming community. Which - as you will know, if - as you say, you come from this rural background - no two farms are the same. The soil in your neighbors' farm is going to be different to the soil in your farm. Your neighbor might have a river running through their land, and you don't. All of that stuff, it's all different.

So meeting needs here, suddenly becomes an order of magnitude more complicated than it is for some other government services. The only way to really engage an audience like that, is to be honest about what you know and what you don't know. To be open about how you're willing to change.

They've done that on the blog. They have changed policy as a result of farmers saying, "You proposed X. Well, it doesn't work for us. We're not going to be able to do X. What are you going to do about it?" The response has been, "We will change the policy. We will change X to Y, to make it easier for you." They've documented that thought process in public, in a series of blog posts - it's been very successful.

Len: This is really fascinating - I mean, I'm on the outside observing, rather than being on the inside like you've been. But I could talk about it forever. Particularly the way that - there's a certain mindset that hears terms like "humility" and "openness," and thinks, "weak and vulnerable." It's exactly the opposite. The hardass thing is to be like, "No, no - here's what we really know, and here's how little that amounts to." The hardass thing is to be open and tell the story. It's not a vulnerability, it's not a weakness. It's a very profound strength.

Getting past the reactionary mindset, when it comes to that kind of thing, I imagine is probably one of the biggest challenges when you're working within an organization, working with people who are watching it and going like, "This isn't how the government should be presenting itself with the people," and things like that. It's like - you didn't just talk to someone who's like, "You solved the problem for me, and now I can dig my ditch, finally."

Giles: Yeah. If you're going to be a hardass about it, you might get people - you might bully people into submission, into seeing your way of doing things. But you won't earn their respect. All you will get is antipathy from them, or fear or loathing - or worse. That's not the right way to behave with people generally, I don't think.

Trying to show that you, as an organization, are capable of learning, which implicitly implies - you are capable of making mistakes. We know that's true. Every organization makes mistakes. There isn't a single one that doesn't. The corporate attitude of attempting to pretend that you never make mistakes - personally, I find not just off-putting, but downright ridiculous. No sane individual would stand up and say, "I never make mistakes." No organization should do the same. Every organization should be quite happy to say, "Yeah, we are humans just like everyone else. We make mistakes, we recognize that, we learn from them - and we do something as a result."

Len: Just in the interests of time, I think we should move on to start talking about your book, your actual book.

Giles: Okay. Yeah.

Len: Moving onto the next part of the interview. So we've been talking a little bit about clarity and simplicity of communication and things like that. But as you yourself say - there is a time for technical terms.

There's one in the title of your book, the "agile comms," notion, has the word "agile" in it. You get to it right away in your book, right at the beginning - and anyone who buys it will see that right away. But I was wondering if you could talk a little bit about your relationship to the word "agile?" How are you using it in the book, and when you talk about it generally?

Giles: Almost every day, I think I should've perhaps called it something else. But it's too late, I'm calling it that now.

I mainly called it that, because the term "agile comms" had started to be used by various people, in various circumstances, and it felt like it lined up with what I'm talking about, or the nonsense that I get paid to talk about by my clients - felt like it needed a name. It needed a label that I could give it.

The word "agile" causes a lot of reactions with a lot of people, for all sorts of reasons. I am not an agile fundamentalist. I'm not like saying that, "If something is going to be agile, then it has to work in a particular way."

My use of the word "agile" is entirely related to flexibility, that's all. I'm proposing ways in the book that a team - any team, not just a software team - but any team working on anything can communicate about their work in progress, at the same speed as the work moves ahead. That's the agility that I'm trying to express in the book.

If you have a team working on any output, and the nature of the output changes from one week to the next - which, hopefully it does - then there are ways that you can write about that work. There are ways that you can organize your team to write about that work, in such a way that you can update your blog or you can make some note or public announcement or something. You can talk about your work as fast as the work is moving.

Most - no, maybe not most - a lot of organizations that I have worked with, have struggled with that in the past. Because normally there is - communications about work, is seen as - first of all, something that is very separate from teams that are doing work. That's one thing.

The communication is also seen, usually, as something that happens only at very specific intervals. The beginning, maybe the middle, and the end. I'm arguing, "Well, if you want to influence people who are interested in your work, or if you want to make them interested in your work, then it's good to tell that story much more often, much more frequently - and as quickly as the work itself.

Therefore, you need to be a bit more agile in the way that you organize your team. That means you might have to have creative types - writers, for example - working with your team. If your team is a software development team, and they are using agile ways of working - then your writer needs to know about that, and understand that at the same time. Does that make sense?

Len: It does, it does. That actually gives me an opportunity to talk about something very specific.

One of the things that I find really interesting about the work that you do, is that you're talking about talking, right? Which brings with it this inherent - t can be a little bit - you have to do a little bit of a dance in your mind to do things like that. But you bring these very clear categories, linked categories to ways of thinking about communicating.

So, for example, layers of communication. I'm just thinking specifically about like - on the bottom - you just think of a pyramid, on the bottom of which is "detail." The next layer up is "context." The next layer up is a "lure."

I find this categorization very fascinating, because as you talk about detail, for example - if you ask somebody, "What are you working on," your typical answer is to give all the detail, right? As though you're talking to someone who's you. Not even a teammate, someone else who's also you.

And that's fine, if the other person is you - or maybe is on your team, or does something that you want - and that's what they were asking you about, was, "Give me the detail." When they ask you what you're doing, it's often - if you have this set of concepts, that for example you give, you can go, "Wait, hold on a second here. Should I talk about the detail, should I talk about the context, or should I talk about the lure?"

For example, if you're in the elevator, and the cabinet minister asks you what you're working on, the best thing to do, is to give them a lure. Which is like, "I'm helping farmers deal with their anxiety over Brexit." As opposed to, "The thing is that the legislation has changed, and in article 510.2 on ditch digging," blah, blah, blah. Right? That's the detail.

I was just wondering if you could talk a little bit more about that? Specifically, I know you get asked about this, but can you talk about the "lure" aspect of communicating?

Giles: Okay. Most teams that I encounter, when I first encounter them, if they are already struggling with communication in any way - nine times out of ten, it's because they are communicating by handing over the detail. When other teams come to them, or when leaders come to them - or other stakeholders, whoever it is - and says, "What are you working on?" Or, "How much progress have you made?" Then one of the most common problems is, "Wel,l here's a link to a Google Drive. It's got 400 files in it. That is our project. Go see," right?

Of course, the person at the other end - that's not a helpful answer for them. They don't have time to work through your Google Drive. They have no idea what the important stuff is in there. What they need, what they want is something much, much shorter and much, much simpler. But also something that makes it easy for them to find out more, if and when they need it.

You asked about the lure. The team that I worked in at the Government Digital Service was headed by a man called Russell Davis, who was hired in from a career in the world of advertising. He brought in a lot of advertising thinking. The lure that I'm talking about borrows a lot of ideas from that world.

If what you need to do is attract someone's attention, and that person is not already paying attention to you, then you need to lure them.

You need to put something sparkly and shiny and dangly in front of their eyes, and say, "Come and look at our work, because we think that you will be interested." That means - if you're going to do that, you need to be just as creative as the people who are making adverts on the telly or on your computer, or on the cinema screen. You need to make something that is going to provide that shiny, dangly - ooh, enticing interface. That means you need to be creative. You have to put a little bit of spark into that. A little bit of poetry. A little bit of life. A little bit of love into that tiny, tiny thing - to make people pay attention to you.

Now, not all teams need the lure. Sometimes the job you have is not to make people pay attention to you, because sometimes the people you're communicating with are already paying attention to you. So, you don't need to lure them in.

But what you might need to do, is still give them something - a brief update. Or an introduction that provides just enough information. This is how I define the "context."

The context is something that helps the reader or the outsider make a decision. It helps them decide, "Do I know enough now? In which case, I'll stop and I'll go away and do something else." Or, "Do I want to know more? If I want to know more, where do I get it, how do I find it?"

So the context layer - the three layers work as a path. The lure brings people in. The context helps people decide, "Is what I need just the basics, or is it more than that?"

The final thing the context layer does, is provide that link onwards - through the path, to the detail layer. So it says, "Okay, now that you do know the basics - if you do want more information, if you do have half an hour free in your diary - you can go and look at this detail. Because you will need half an hour to read it, at least."

Just this afternoon, I've been working on a project with an organization. In fact, it's three different organizations, all working together on a particular thing. They have a need to communicate simply and clearly about a matter of policy.

My job this afternoon was going through pages and pages and pages of documents, that each of those three organizations has already written over the past five or six years. There must've been twenty or thirty of these documents. Some of them were two hundred pages long. All of these different documents exist. This was a huge, huge pile of detail layer, effectively.

One of the problems that these three organizations had, was that nobody understood what was going on in this policy area, because nobody has time to go through a list of twenty or thirty documents, some of which are two hundred pages long.

Len: Thank you very much for sharing that very specific form of problem, because it can sound abstract, but actually, this is exactly the thing that people who work in big or even small organizations encounter all the time, is having all this detail produced by very different people.

Even going into it, people might be very attached to that two-hundred-page document, that they spent six months writing. It can sound easy to say, "Oh, let's adopt these clear practices."

Then you run into somebody who's like, "I spent six months on that document. You really want to throw it away with a catchy poster?" I mean, that's - we could talk for hours about that as well, the personal element of things as well, right?

Giles: Yeah. But I would say, that - so there's a couple of issues there. One is - who wanted the person who wrote the two hundred pages to write two hundred pages? Could that boss who commissioned that work, have done something to make it shorter? Did it need to be two hundred pages in the first place?

Maybe it did, right? Let's assume that there are good reasons why it's that long. In which case - I'm not arguing, and I wouldn't argue that you should throw the document away and only have a poster. What I'm arguing is, you need a way to make people aware that the document exists. You need a way to give them just enough information, to help them decide whether they need to set aside the time to read it. Then you need to provide a link to it, or make it available to them in such a way that it's easy for them to get to, once they've decided, "Yes, I want to carve out time in my diary and read this whole thing."

Len: You just gave me the greatest podcast interview-y gift of a great segue. Which is - if you want to set aside time to read Giles' book, The agile comms handbook, and you want to know where to go - you can go to the website, agilecommshandbook.com. There you'll find a link to where you should buy it from, which is Leanpub, where you can get the ebook.

But you actually have print copies as well. I know you've got many of them, I saw you tweet about it earlier today. For the last part of the interview, we save it for the nuts and bolts of self-publishing - we'll maybe just take five minutes to do that, in the interests of time.

So, you actually created a print version of your book, I believe, quite some time before you made an ebook version on Leanpub. I wanted to talk to you about that, because the book is very, very well produced. I know you hired an editor, and I know you hired a designer for it as well. In fact, I think you mentioned her name - that you worked with her previously for the GDS, is that right?

Giles: Yes. So my editor was Amy McNichol. The designer of the book was Sonia Turcotte. Both of them are former colleagues of mine from GDS. Without their skill and talent and patience, that book would never have happened. So I'm enormously thankful to the both of them for helping me with it.

Len: You link to them in your book, right at the beginning, which is very great. That's very good for other self-published authors. I mean these kinds of - finding people like this, that you can trust, and you know are good - can be very hard. So please check them out if you're thinking of getting an editor, or having someone design a book for you.

One of the really fascinating things that you have to do, if you want to make a print copy, is you have to iterate on using print-on-demand services, and then you have to make a decision in the way you're doing it - it's like, "How many copies do I buy for my first run, when I've decided I'm ready to go?"

I actually wanted to ask you specifically - how did you decide how much to spend, and how many copies of the book to buy? Because you're going through the classic thing of like, "I've got boxes and boxes of books in my garage," or whatever it is. Or in my office. How did you just make the decision, how much to spend on your first print run?

Giles: So the route that I've gone down, to end up here - where I have boxes of books - is exactly the opposite of what I wanted to do in the first place.

Len: Okay.

Giles: In the first place, I wanted to do print-on-demand. I wanted to have nothing to do with the distribution process at all. Because - like the people that I describe in my slide decks - everybody is already too busy most of the time. I'm too busy as well. I don't have time for that.

I spent months trying out a print-on-demand service. The short version of the story is that - yes, they were capable of printing books on demand, and yes they had the necessary hooks to make the book appear on online sales services like Amazon and others.

But the quality of the printing was terrible. It simply wasn't reliable. I ordered a bunch of different test copies in different batches. Some of them directly from the print-on-demand supplier, and some of them via Amazon.

Essentially, they were all just slightly different colors. Some of the fonts were smudged and dirty. There were weird print production errors on some of the pages.

When I contacted the print-on-demand service about this and said, "What's going on here, why -? Can't you fix this, please?" We went through a lot of back-and-forth about it. But the end result, ultimately, the answer was, "We can't do anything about it, because that's how print-on-demand works. You can't guarantee the quality you want with our print-on-demand service."

So I iterated, and I realized, "Okay, I'm not going to be able to do what I wanted to do. I'm going to have to do what I didn't want to do. I'm going to have to print copies in a batch, and I'm going to have to keep them in my office, and I'm going to have to stick them in the post myself. Unless I pay my teenager to do it for me," and occasionally I do do that.

But as far as deciding how much to spend, the whole point of this project was not to make a profit. I'm just about breaking even on the cost of the print, and all the other costs associated with making the book.

The point of the project was to raise my profile a bit, frankly. To get more people interested in my work, so I can get more clients. In that respect, it's been successful.

I didn't set out with a particular figure in mind for how much I'd spend on the printing. I'll say now, it's been several thousand pounds. Every time I do another print run, it's a few thousand more. But it's been money that I think has been worth spending. Because it's helped my business grow. That was the point in the first place. All of it, as far as I'm concerned, has basically been my marketing budget. So my marketing budget is a book.

Len: Thanks very much for sharing those details, and the story of going from - having one assumption about how to do it, and having to pivot to something else.

The example you're giving of writing and self-publishing a book as a consultant, in order to raise your profile - that is a classic story that many, many consultants do.

Back in the days when our company was bootstrapping, we were doing consulting work. And by far, our most lucrative client - pirated two of my colleagues' books. He was like, "I'd really like to work with you guys." So basically, stolen copies of these ebooks, led to our biggest client relationship we ever had.

So, writing books is a great way to get attention. The thing I like about it, and one of the reasons I do what I do - is that it's like, the most genuine way of drumming up interest, is actually writing a book. Because it takes a lot of effort, and it's right there - whether you know what you're talking about or not, whether you can do it well or not. So, if the project succeeds, it's because it was a success in the first place.

On that note, I can't let you go without asking you the last question we always ask guests, if they've been using Leanpub, which is - if there was one feature we could build for you or do for you, or if there was one terribly annoying bug or crappy part of you using Leanpub that we could fix for you - is there anything you can think of that you would ask our team to do?

Giles: Make it so that the navigation doesn't change. The interface to Leanpub, I think is a work of art, frankly. You're doing an amazing job. Particularly because people like me are simultaneously several kinds of user. We have user needs as authors and publishers, and that's one set of needs to meet.

But we also have an account, that means we can buy books. So we're buyers, that's another set of user needs to meet. Then there's a sales and marketing set of needs. "How many copies of my book have I sold? Ooh, look - another one, hurray." There's another set of needs there.

But what seems to happen when you're moving around the site, is that - when you traverse one of the boundaries between those sets of needs, stuff changes at the top of your screen, that makes it hard to find the thing you were looking for six hours ago, for example.

That would be the only comment I have. There are so many things that I absolutely love about Leanpub, particularly the browser-based editor. As somebody who has spent many, many, many years writing almost everything in Markdown, I really appreciated being able to create a book out of Markdown, using plain text. That was one of the things that made me think, "Yeah, I've got to go with Leanpub."

Len: Thanks very much for the very charitable framing of that feedback. You actually captured it perfectly, the challenge, which is that Leanpub is used by people to discover and buy books. It's used by people to read those books and download them, or read them in the browser. It's also used by people to write books. It's also used by other authors - maybe they've got their entirely own process for creating ebooks, and they just upload to Leanpub, but then use all of our storefront. Then there's the storefront features that you've got to manage as well, like pricing, and all that stuff.

So, yes - by the way, I always share this feedback with the team, because this is gold for us, right? We've iterated many times over the years on the design, and there is this fundamental challenge of like, "Can you unify all of this under one design framework?"

Currently we - I'd say "still," because we know the challenge is there, and we know that we're not at the end point - but we still have a basic divide between what we call the "reader app," and, I guess, the "storefront" and the "author app."

The author app itself, as you pointed out, again - there's the writing if you're in the browser. There's also all the storefront stuff, things like that. Communicating with readers, and things like that.

So, I will say - for anyone listening - the escape hatch, is that little hamburger menu on the top right. [Here is an article from our Help Center that sets all this out with screenshots - Eds.] From there, you'll see the problem that Giles is pointing out.

Because it's like - we're really proud of that little escape hatch. But it in itself shows you the problem, right? Because the left-hand menu is like, "Author," "Library." it's like, well, if you go to "Author," then it will say, "Books," "Courses," and "Bundles," right? If you go to "Library," it'll go "Books," and "Courses."

Giles: Yeah.

Len: It's like - "Library" is for readers. They want to go to their library, they want to go to their books. If you're an author, you want to go to the books that you're working on. So, thank you very much for articulating that so well, because that is exactly capturing the problem. The problem's real, and it's something that we are always working on to improve.

Well, thank you very much, Giles, for taking some time out of your evening to talk to me and to talk to our audience. And thank you very much for using Leanpub as the platform for the ebook version of your book.

Giles: My pleasure. Thank you for having me here today, I've enjoyed our chat.

Len: Thanks very much.

As always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.