Matthew Skelton, Author of Team Guide to Software Operability: Proven techniques for making software work well

Len: Hi, I'm Len Epp from Leanpub, and in this Frontmatter podcast, I'll be interviewing Matthew Skelton.

Based in Leeds, Matthew is founder and head of consulting at Conflux, where he provides consulting and training for tech strategy and software engineering practices. He has been working on commercial software systems in various capacities since 1998, and published books through Skelton-Thatcher Publications, which he co-founded.

You can follow Matthew on Twitter at @matthewpskelton, and you can learn more about him on his website, blog.matthewskelton.net.

Matthew is the author or co-author of four books on Leanpub, and a number of other books. The books on Leanpub being, Team Guide to Software Operability: Proven techniques for making software work well, Build Quality In: Continuous Delivery and DevOps Experience Reports, Better Whiteboard Sketches: How to Sketch Clear Technical Diagrams, and his latest book, Internal Tech Conferences: How to accelerate multi-team learning across departments.

In this interview, we're going to talk about Matthew's background and career, professional interests, his books, and at the end we'll talk a little bit about his experience using Leanpub to self-publish, and his other work with publishers.

So, thank you, Matthew, for being on the Frontmatter podcast.

Matthew: Thank you. It's great to be here, Len.

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 first became interested in computers and software engineering, and specifically, can you recall your first experience with a computer?

Matthew: I grew up near where I live now. I lived in Bradford, which is very close to Leeds, in the north of England. I actually was intending to study music - and actually I've come back to that - but I've been learning trumpet for the past few years, and it's the most amazing thing. So actually, I didn't do a lot of computers when I was growing up; I was really super focused on the musical side.

But before going to University, I spent a year working as a lab technician in a school. I did lots of practical science, basically - preparing experiments, getting big laser machines out of the cupboard, and preparing bull's eyes for dissection, and all this kind of stuff. It's actually super interesting. But I actually having a conversation with my colleague at the time, the senior technician, who actually explained to me how computers work, in terms of instructions, addressing parts of memory.

And I realized at that point, "I have no clue about computers at all." Which is an interesting point to start from. I think that little anecdote actually reflects my interest in computers in terms of how they work, not just what we can do with them. I've never been particularly interested in things like computer games or some aspects of building software, but I'm super interested in how they work.

I was at university in Reading in the South of England. I studied Computer Science and Cybernetics, Cybernetics being a theory of control systems, the primacy of feedback loops and understanding systems in terms of feedback, multiple feedback loops. The department I was at was one of the first departments to build autonomous robots - for example, back in the early 90s. And that particular course was really interesting in the sense that they took a real systems thinking approach to systems in general. We used computers to understand systems, because it's straightforward to iterate very quickly using software and electronics and things.

I did a project, for example, on insect vision. How do insects see? Because there's all sorts of feedback loops in the insect's visual system. And for my final year project, I built an autonomous weather station. a weather station that's designed to sense temperature pressure, lightning as well. And using some - well, late 90s control networks and so on. So this is quite early, maybe 20 years before modern Internet of Things, IoT-based remote devices and things. But we were doing some stuff using 8 bit control networks at the time. For me, it was super interesting to really get to grips with the detail of how things actually work. Right down to the very lowest level - at the microprocessor level, and down onto the actual bus wire level of how computers work.

And then, of course, feel free to forget most of that as you move up the stack. Then you don't need to think of all that detail all the time, but it's still there. I think that level of detail has put me in good stead, because if you know the fundamentals, then although most of the time you forget them, you're never going to really make a fundamental mistake about an algorithm that you're trying to implement in software. I'm trying to think of another example. Some sort of mistake about how data is stored in the database or what happens when you make a SQL query, for example - knowing the real fundamentals can really help, even if most of the time you can forget about it.

Len: That's really interesting. I love asking this question, because not all Leanpub authors are in tech, but many are. And learning about their first experience with technology is really interesting. You're one of very few people that I've interviewed whose first - I mean, lots of people get into the fundamentals at a certain point and find it fascinating. But a lot of people, their first experience is the magic of typing something, and then seeing something happen. Like one guy I interviewed recently, he had a scientific calculator that he could program in. And he just found that fascinating. For someone else, it was a bouncing ball on a Commodore 64. But there's the occasional person who it's like, "Wait a minute. Like, machines can do this?" And they get into like information theory and stuff like that - how do gates work and things like that. And so it's really fascinating to learn everybody's journey.

I think you've already answered this question for me, but another question I always like to ask is - if you were starting a career now in tech, would you formally study Computer Science at university?

Matthew: I think it has been super valuable, certainly where I studied it. Because we have this combination with Computer Science, and it was actually the science of computing that we did. We did programming as well, but it was actually - there's lots of theory behind it, and so on. But we also did practical stuff with robotics and with human systems, with a bit of psychology in there. The course at Reading was actually really good, because it sets people up for a deeper and broader understanding of computer systems than just a programming course. And it wasn't just software engineering, it was a broader thing. A course like that where you do get to see a bigger picture. You do get to see some of the theories, some of the fundamentals behind it - I think it can be really valuable.

But actually, I was thinking this recently. I think what we really need in the industry is not just people who have had some experience learning about software and computer systems. We need people who have done psychology, people who have done philosophy and ethics, people who have a sense of history, people who understand design. In other words, we need people from across the spectrum of human interests and awareness building software systems these days - having input into building software systems. Because software systems are becoming so prevalent, so all-pervasive in touching all parts of our lives - from agriculture, health care. Not just banking and shopping, which it was for the last 20 years - but they're starting to touch everything.

We need a diverse range of people, a full spectrum, if you like, of people from all sorts of walks of life. feeding into, and contributing to how we build these software systems. I think it's important that we have some people who have been to university and have studied the fundamentals. I think it's important we have some people who have come straight from school, and have learned their craft as a programmer or as a systems person.

But it's not just about that either. We also need people who have got very, very different perspectives. More of an arts and humanities perspective as well. Because this is about society. This is about software affecting the society we live in. I think we need a really broad range.

Len: Actually, that's-- I wasn't planning on asking you this. But one thing that also comes up sort of routinely here, because I get to interview people from all around the world - is different university systems. What was it like at Reading? Did you have to take electives? Or did you only study Computer Science and Cybernetics courses? For example, did you have to take some humanities courses as part of your degree?

Matthew: At Reading, it was mostly - we had some flexibility in what we could choose. There was some crossover. Some people chose to do some psychology modules or some sort of human systems stuff. Most of it was fairly predefined, where I was on that course.

Len: It's really interesting, because what you were saying corresponds much more to the North American model of what an undergraduate university education should be, than the British one.

I couldn't agree with you more. The particular preoccupation I have - because my technical knowledge is nowhere near yours, but I encounter design decisions, like everyone else does, every day in software. And an example that I always like to think of when it comes to this thing, is bookmarks in Chrome. If you bookmark a website in Chrome, you can only put it in one folder. If you bookmark it in one folder, and then you try to bookmark it in another folder, it moves it to the other folder.

And I can see the thinking of the guy who made that decision. And that is, someone with no experience at all, ever, doing research of any kind.

Matthew: Or even no interest in behavior of people who come from different mindset to them, possibly.

Len: Exactly, precisely. I mean, I've encountered this myself with someone going, "Why would anyone ever want to do that?" And it's like, "Why would you treat the limits of your own imagination as the limits of imagination itself?" You shouldn't relate to your own horizons that way.

This is a problem that we encounter in the things that we use all the time that are designed by people who don't - it's not just that they don't - like, nobody knows everything, but even - lack a fundamental curiosity. I think the more that people in their education are sometimes forced to branch out, the more likely they are to understand that there's a world beyond what you know - and that when you're designing or creating things, you need to do it with that understanding.

This is actually all very relevant to my next question. I was surprised to notice when I researching for this interview, that you and I nearly overlapped at the University of Oxford, and you studied neuroscience there.

Matthew: That's right.

Len: And the typical model of student life there for undergraduates, and what they call post-graduates - or in North America, we call graduate students - can seem unusual to people unfamiliar with it. And I would venture to say this is particularly true for people more familiar with the North American university model. What was your experience like at Oxford?

Matthew: I was on the Master of Science in neuroscience. And that was quite a radical program. This is back in, in 1999, 2000, a while ago now. But it was quite a radical program at the time, where they took students from a wide range of disciplines. I was obviously coming from Computer Science and cybernetics, but there were people on the course who had backgrounds in philosophy, psychology, mathematics, biology. All sorts of different backgrounds in terms of their undergraduate study, being brought together to do Master's-level study in neuroscience. And that was deliberate, because what they wanted to achieve was this diversity of opinion.

Because at the time, this was 20 years ago - it was quite clear that we understand much less about how the brain worked than we had thought before. Nothing's changed in that respect; we still don't understand an awful lot about how the brain works. It's just become quite clear it's become more and more awkward and complicated and nuanced.

And so that was a really great experience, a really great course. Because we had this huge diversity of people coming from - mostly from the UK, but we had people from North America and a few other places too. And so the conversations that it would spark, and the positions that we're coming from, led to some super interesting discussions and super interesting perspectives on brain function and perception and sensing and this thing. I mean - maybe I'll talk about this in a little bit. But that, my experience there has been quite a real strong influence on some of the work I've been doing recently with the "Team Topologies" book.

So outside of the course itself, the learning model at Oxford is - it needs a lot of independent study, compared to some of the universities. More recently, I did a Master's in music at the Open University. Which is a university based in the UK, but they've got a worldwide presence.

I think they've been doing distance learning since the 1960s. Back then, it was sending cassette tapes or video tapes or whatever out to people by post. Obviously now, it's all online. And the Open University model is super supportive. You get loads and loads of really good materials, and you're really guided through the learning and that thing. That was a great experience as well. Oxford was very much the other end of the spectrum. Where you're expected to be very independent and so on. I learned a lot about all sorts of stuff from that experience there.

Len: I have to ask, what college were you at?

Matthew: Brasenose College.

Len: Okay.

Matthew: Where were you?

Len: Balliol.

Matthew: Okay, just across - yeah, just around the corner.

Len: Yeah.

Matthew: Were you there before or after?

Len: After.

Matthew: Okay, 2001?

Len: 2001, yeah. It's interesting you say that about independence. I'm just - not to go too "inside baseball" on our listeners here, but this has come up on the podcast before, that the Oxbridge model is basically, you arrive - and this is, and I don't know - I can't speak to the undergraduate experience, although I do know a fair amount about it. But the post-graduate experience is - you arrive, and you're like a kite - they let you out, and then they tie it to a rock, and then they come back later to see if you're still flying.

It suits a certain type of person. And it very much does not suit another type of person. And so, if you're considering going, keep that in mind, that part of the experience is being alone and doing things yourself.

And so that sounds like a really fascinating program. And it becomes relevant to the work you do later.

Just keeping with the timeline, another coincidence I found when I was researching for this interview was - back in 1999, I was working in London for a company that was at the time called Computasoft and is now called Dealogic. I remember when they came up with the name, actually. And I found that you've actually worked with them as a consultant. That got me thinking that when I was there from 1999 to 2001, the company was building a huge database of information on corporate mergers and acquisitions around the world, going back to 1995.

Something that was only possible - at least the way my team did things, because of newly available search technology and the expansion of the internet. And of course, the relevant technology that companies like Dealogic can use nowadays is orders of magnitude beyond just searching.

But it got me thinking - what would you say are one or two of the biggest changes you've seen in the tech sector in the UK, in the companies you've worked with over the course of your career? I say the UK because sometimes there are culturally specific things that are very interesting that can happen.

Matthew: The first one is obviously the move from desktop to web. When I started working as a software developer back in 2001 - well, I was doing some work prior to that, actually. My very first job was as a network engineer installing Windows 95 machines in schools and colleges around the UK. That was a long time ago. I learned a bit about networking and consulting back then.

But my first real job was writing software for brain imaging machines, and big hardware devices. I was writing the desktop software. The big switch since, since 2000 - well, a little bit earlier than that, but the big switch is, in my career, since 2001 - was there has been this big shift to web-based delivery of applications and so on.

I mean, now we're seeing a switch towards, an expansion of stuff to include IOT devices. very small devices where a fabric of computers - this current wave is somewhat similar to the switch from desktop to web in a sense.

We've been working, for example, with some manufacturers in the UK. And there is an increased need to be able to grab telemetry and data - the metrics data, from the machines on the assembly floor, or in the processing plant itself. Sometimes that's retrofitting onto existing machinery that might be quite old. Sometimes it's actually deploying new sensor technology, that can be more rapidly reconfigured and controlled.

And there's starting to be this bridge between the manufacturing plant and the cloud. We're scraping the data off the centers and pushing it to the cloud for analytics. And things like preventative maintenance of machines, which can save a huge amount of money. That's just in a manufacturing sector, but it applies to healthcare, agriculture, and so on as well. That's a huge shift at the moment where we're starting to see sensing technology being deployed into a huge range of different scenarios. And then with that data being pulled up and processed, we're able to make much more effective decisions that are actually data-driven, that help us to avoid waste or to better optimize the machinery and so on.

I think that is a big change. And I think a lot of organizations are maybe either struggling, or might fall by the wayside, if they don't adopt that approach.

Len: I think I get what you're talking about with preventative maintenance. Basically if you can have more or less real time data coming from sensors from machines, then you can see - the real time lets you know what's going on, but you can see patterns that can help you make changes to how the machine is operating, so that you can prevent faults. Is that the thing that you're -?

Matthew: Yeah, that's exactly the thing. Instead of sending a maintenance engineer out once a year to maintain an escalator or an elevator or something - you detect one that needs maintenance, and then you can send them out just at the right time.

Len: That reminds me of a really interesting thing I read about. It was actually probably a couple years ago now. But there was this, I think, a famous machine learning experiment, that I think it was Google did on like a data center where they set this machine learning algorithm - they gave it control over the cooling mechanisms in the data center. This is like something as mundane as opening and closing vents, for example.

Matthew: Yeah.

Len: And it increased the efficiency of the data center by 15%. And in a competitive world -

Matthew: That's huge.

Len: That's huge. But the idea that companies are like - you can imagine it from a C-suite perspective. "I mean, really? I can just get this secret sauce if I've got the right sensors and the right computing going on in the cloud, that I can increase the efficiency of my machinery by this huge percentage?" I mean, the incentive to get involved in that must be really intense.

Matthew: Yeah, so that stuff's driving all this AI/machine learning/algorithmic application of data driven stuff. I think that that is one big thing.

I think that the second thing that feels like a big shift is that many organizations haven't really realized that. Or haven't really taken advantage of the virtualization in cloud and modern practices, and still think that the way in which they're running their thinking and commercial view on their products or their market fit or whatever - the way these companies seem to be running is still as if they're going to deploy some software onto a desktop. The people running them have still got a kind of, "Software basically is just about what I can see on the screen."

And this is hurting so many organizations. Because the way in which these companies are prioritizing the software work is basically crippling their ability to innovate, is effectively squeezing their own capabilities. These sorts of organizations have not taken the time to think about operational concerns, think about testability, think about how easy it is to diagnose a problem, how easy it is to restore a service after it's fallen over. All they're thinking about is a set of features and pushing those features out as quickly as possible. And these companies are really struggling.

Because they are falling behind their competitors - who are able to go much faster, who are able to do things with less effort, apparently, and able to get a better market fit. Because they've completely changed, the companies in front have taken a very different approach. Which is very small changes, tested. A really strong focus on testability, on operability - these properties of the software. Optimizing for the ability to change, rather than just pushing out a big long feature list.

And so I think that that's been a big change in the UK and around the world basically, is the way we think about doing this thing called software - there are new patterns which were really, really successful - but not every company has really understood that that's the way to go.

Len: This is a bit of clunky segue, but speaking of big changes - on this podcast, we like to talk about people's careers. And in 2014, I know you started your own business at a certain point. But in 2014, you decided to start your own consultancy - if I've got the timeline right?

Matthew: Yeah.

Len: What led you to do that? That's that's a big decision.

Matthew: At the time, this was when the DevOps movement was still fairly new, I attended one of the first devopsdays events - it was actually in Hamburg, back in 2010. I gave a quick lightning talk there. That was only one year after the DevOps thing really kicked off. I've been going there a few years, and I'd been working for a couple of different companies in London at the time.

I decided, actually, the market was ripe for me to have a go at it alone - basically, to see if it could work. It also coincided with a move - moving house from London to Leeds, where I now live. It was a nice opportunity to just have a clean break.

Len: Was there any particular reason to leave London? I lived there for a few years myself, and it's a very exciting place, but it can also famously wear on one.

Matthew: Yeah. Look, London's great. And there's so much opportunity, so many amazing things to do. I appreciate living here. The air is cleaner. I can reach seven different national parks within a day. I can get out there and go walking and be in the open air. And this is where I grew up, so I know it quite well. It was a great time in London. I was there for 10 years - but I love living where I do now.

Len: You founded the London Continuous Delivery Meetup Group, which has thousands of members.

Matthew: Yes.

Len: How did that come about? And why do you think it became so popular?

Matthew: I founded that back in 2012 - or co-founded. I was giving a talk at an event called WebPerfDays, which was associated with the Velocity Conference from O'Reilly at the time, and it was taking place in London. I did a talk on how continuous delivery is shaping software architecture. This was at the place I was working at the time. I was talking about things like a focus on deployability, a focus on detecting problems, a focus on testing - things like this. I did it, the room was packed. The room was absolutely packed. There were people who couldn't even get in the room, it was so full.

And so I thought, "Oh, that's really interesting. People seem to want to know about continuous delivery." Of course, a book called Continuous Delivery by Jez Humble and Dave Farley, had been published two years before. it was still fairly recent. It was probably less than two years between the publication of the book and my talk at the time.

I just asked people at the end of the talk, "Look, if anyone wants to meet me after the session, and talk about maybe doing something around continuous delivery in London - then let me know." There was a chap there, Dave, who came and had a chat. And we decided, "Well, let's make a go of it, and let's see what happens." I was running that meetup group for seven years - well, seven, eight years.

I've actually just handed it over to some folks from a company called Engineer Better, who have been really good supporters of that and the Pipeline Conference, which came out of the meetup group. The Pipeline Conference, we ran from 2014 to 2018, and that was created and founded and run by people who were involved in the London Continuous Delivery meetup group. The group was an amazing experience. There's so many good people that I met there. I'm so grateful to have had the opportunity to work with all those people, and to be able to hear what they had to say and so on. There's really great community around it.

I think one of the reasons why it worked so well is because we avoided a focus on tools. We did have some talks about tools when it was appropriate, but we avoided it just becoming about, "Hey, here's Version 1.7 of this tool." And, "Oh, look. Here's 1.8, and look at all the new features it's got." We avoided that thing. Which is fine and useful, but we made sure we had a broader appeal. We had talks on product ownership, we had talks around testing and testability. We had talks on version control and branching - the whole range of different practices, it was more of a practice based thing. It appealed to quite a wide range. And we moved around different offices, so different companies. We moved around London each month. We got to see lots of different locations, and we got to, I guess, partly promote quite a lot of different organizations, different companies as part of that.

Len: And, just for those listening who might not know, what is - and thank you for sharing, sharing the story.

Matthew: Yes.

Len: If you could explain what continuous delivery is, because this is another big, big change in the way things are done?

Matthew: Continuous delivery, as defined by Jez Humble and Dave Farley in their book from 2010, is reliable software releases through build, test, and deployment automation.

Quite often people think continuous delivery is just about pushing code to "live" when we're done. But it turns out, in order to do that effectively, we have to actually think about a whole lot of other things. We have to think about team ownership of software. We have to think about version control practices. We have to think about how often we're merging our code with other people; a whole load of other practices and team interactions and individual interaction between people, to make this stuff work really well.

And what's interesting about the "Continuous Delivery" book, is - I'm still waiting to find some practices that Jez and Dave recommended that no longer apply, but I can't find any. I'm always looking. It was a great book in that sense. They made sure it wasn't too technology-specific. It was really focused on fundamentals with some good examples.

But I mean, there's some new stuff that's come along since 2010, obviously - and particularly in terms of things like container orchestration, cloud and things. But the fundamentals are absolutely sound. It was really useful to have that as a focus. Because effectively, it's perpetually useful as a set of techniques and practices.

Len: It's really interesting to think about how aspects of our lives have changed because of this. I mean, in the old days - for example, if you were making a product like Excel. You code, code, code, code, test, test, test, test. And then you print, in the old days, disks.

And then you wrap them in plastic and cardboard, and you ship them out - and then people install it on their computer, and that's the product - until you buy a new version.

But nowadays - and it's not just the things that we use on our computers or phones, it's even our cars - I mean, if you're fortunate enough to own a Tesla. They get updated all the time. And the updates aren't just always new features. It's like keeping up, and just making it continue to work - making things continue to work with the changes happening in the world around whatever the product or service is. And the theory, and the management and team practices that have to exist in order to enable that, is a really fascinating subject just on its own.

At Conflux, your current company, it says on the home page that for you, digital technology is viewed as a - quote, "Organizational sensing mechanism," end quote. People probably recall from earlier in interview when we talked about things in factories being - machines in factories having internal sensing, and how that can work. But you do a lot of work at the organizational level, and it's just such a fascinating idea. I was wondering if you could talk a little bit about what it means to think of an organizational sensing mechanism - and how it informs the work that you do with companies, from multinationals to startups?

Matthew: Sure. I think this comes from a combination of my background in music. I sing in choirs, and I play the trumpet, I'm learning the trombone - various things like this. And so I've got a very strong sense of having to listen to other people. Like when you're playing in a band or an orchestra or a choir - whatever, there's a very strong sense in which you've got to listen carefully, as well as deliver your part, if you like? Play your part.

But I think that's combined with the study that I did, that we talked about before, in neuroscience. Obviously, so neuroscience - all about the brain, but the brain needs sense organs to function. that's partly why the eyes, the nose, the mouth, the ears are very close to the brain. It's precisely because the shortest path between the sense organs and the brain means that the information gets there much more quickly, and therefore could be processed more quickly.

And the way I see things is, many organizations are almost like a like blind wombat, or one of these creatures that can't really see and can't really hear properly. They're just stumbling around in their environment, not really understanding what's going on. Whereas the organizations that are really able to move very quickly through their environment. When I say "environment," I mean the commercial environment, the world in which we're working. it's not physically moving, necessarily - although many, many organizations do have lots of physical moving parts.

But you can see it conceptually as the organizations sit in an environment. If it's not bringing in sensory data about its context - so if it's not listening to Twitter and Facebook, if it's not listening to sales data and website traffic and the traffic and Google analytics or whatever - it's not listening to that stuff and understanding how consumers are interacting. If the organization is not doing incremental software delivery and testing what users actually want to - testing the features that users actually interact with, and testing which things actually work.

If an organization's just blindly just stumbling forward, then it's acting as if it's effectively just knocking into things, like blind wombat would do in its environment. The organizations that are more nimble, much more able to move around and avoid crashing into things. Crashing into problems like GDPR, or crashing into problems like - whatever - Brexit, or some privacy legislation. Then these are the organizations that are bringing in lots of digital data into their organization, and acting on it quickly.

They've got dashboards, they've got analytics. They've got teams close to the data, who are then able to make adjustments and changes to the software they're building very, very rapidly. Which seems magic to these older blind wombat companies. Because they - "We've got the same number of people, we've got the same level of investment." But what they don't have is - effectively - eyes and ears and noses and so on. Antennae, if you like - giving them this sensory input.

Len: I've got a question or two about stumbling around in Brexit to ask you in a couple of minutes. But just on that note, so you're talking about all this. We've talked about sensing just in machines, and now in organizations. But one thing you also talk about is - and this goes, I'm sure to your interest in neuroscience, and your background in that study. You also talk about cognitive load, which comes down to the individual and the team.

I had to put this together, but I'm thinking about your interest in computers and drawing on memory, and things like that. And humans have limits. We have these limits to how much information we can be managing in our working memory, and this can actually be part of a management tactics or strategy. To think about, like - if I've got a team of say X number of people, and they're working on this type of project - there's only so much that they can be crunching at a particular time.

Can you tell me a little bit about that? What is cognitive load, and how do you manage that?

Matthew: Cognitive load was defined in this context by a person called John Sweller, back in 1998 [correction: 1988]. And the cognitive load is the amount of stuff, if you like, that we can - the amount of information we can hold in our working memory when we're doing a task.

And there's three different kinds. There's intrinsic, which is fundamental things about the problem we're working on. in the case of computer programming, that might be - let's give an example. just something about Java syntax or something, or Ruby syntax. Something like that is there. I've absorbed that, and that's just something in the background I just have to work with.

There's extraneous cognitive load. Which is - things that effectively have nothing to do with the problem I'm working on, but which get in the way. An example in that context would be, "How is it that I deploy this software again, in this context?" Something that's nothing to do with the business problem, that's a distraction. We want to minimize that. We want to minimize the extraneous cognitive load, because there's no value add to that.

And the third kind is what's called, "germane," which is useful cognitive load, which I actually need in order to help me work on the problem. If I'm writing some bank account reconciliation algorithm, something like that, I've got to keep that stuff in my head, otherwise I can't actually do the task in hand. The idea is to minimize the extraneous cognitive load, we've got to have the intrinsic - that leaves more space for the germane cognitive load.

Len: If I can think of a metaphor? Say, not for necessarily writing software, but just writing, general - it might be like, knowing the language would be intrinsic, using my writing tool - like my fountain pen or my quill or my keyboard, would perhaps be the extrinsic. And then the germane would be knowledge about the subject that I'm actually writing about.

Matthew: Something like that, yeah.

Len: Okay.

Matthew: Something like this. And obviously, we want to be focused as much as possible on the germane aspect of a company's cognitive load. Because that's where, if you like, the competitive advantage is - if we're in a for profit company, or that's we can produce the best outcome for like citizens, if we're working on some government-focused system.

This becomes really quite important. Because if a team is asked to take ownership of a piece of software that is way too complicated, that has way too high a cognitive load for that team, then there's no way they can effectively own it. There's no way they can realistically deploy and test and operate that piece of software as a team, because there's just too much to think about. And therefore they will start to feel unsafe, if you like? They'll feel like unable to actually own it properly. The speed of deployments will probably go down, or the number of problems in production will go up, because they're not actually able to effectively own all of the aspects of the stuff that they're building.

I'm actually writing some slides for a talk next week. Which, I guess by the time the podcast goes out, will probably have happened anyway.

If we start from the viewpoint of needing to make sure that cognitive load is not exceeded for a team, this is a different way of thinking about the size of software systems. In the past, we've had big monoliths, where we deploy stuff together into one big, big system. It all gets deployed together. There's been a movement in the last 10 years or so towards microservices, where the focus is on very small, a very fine-grained set of services and bits of software.

But I think a different way to look at this is - if we have a team that's responsible for a segment of the system, as long as the software that they're working on does not get bigger than the collective cognitive load of that team - then we're fine. Because if the team's still able to own it, then they're still able to assess the complexity, they're still able to assess the risk, they're still able to do what's necessary to get that deployed in the right way. It's an angle that strikes me as fairly natural - coming through with a bit of a background in neuroscience and cybernetics and things.

But I think for other people, it seems like there's not that many organizations really so far that have really considered this. There are some. For example, the telecoms provider, Twilio, explicitly considers the cognitive load on teams that use its software internally, and they've spoken about this quite a bit - how they actually assess how difficult some of their internal services and systems are to use. And they drive down the cognitive load on the product teams explicitly around that.

Because they know that if the cognitive level gets too high, those teams will not be able to build and run and own those software systems. It's starting to be a thing - a very different angle about thinking about how big different parts of the system should be. Where we need to run, where we need to go very quickly and safely, it makes sense to explicitly consider a maximum amount of cognitive load that we expect a team to be able to handle.

Len: We've got to move on, but it's a really fascinating topic. I mean, I think, often when we're conducting business - it's often an instinct to be optimistic, I suppose? But to take into account these fundamental human limitations, I'm sure it's something that like Special Forces do, or something like, right? Like literally, like how long can you stay awake? What happens if you use stimulants to stay awake even longer? But you could actually measure how performance starts to change over time. And to think about these kinds of things in the context of running machines, is just really, really fascinating.

But moving on a little bit, one thing I wanted to ask you about was - I don't know how much you can talk about it - but I saw on LinkedIn that you recently worked on the contract for the UK's Home Office, to work on technology related to immigration. And of course, immigration has been a huge topic in the news in Europe and in North America, and many places in the past few years - in obvious ways, I probably don't need to really go into detail about. I was wondering if you could talk a little bit about the work you were doing for the Home Office? Or if you can't talk that much about it, how you see new technology might be used to manage information by governments, regarding things like immigration in the future?

Matthew: For most of 2018, I was engineering lead at the immigration technology division inside the Home Office, yes. It was quite a big program, there's lots of different teams. And one of the things we need to do is to bring in a coordinated approach to engineering standards - coordination across multiple teams. What's going to be our approach to deployment? What's going to be our approach to logging? What are the detailed low-level ways in which we're going to use logging, so that we have the best outcome for the what were called, "the live service team," people who are actually looking at the live systems, like ops? Ops people.

A lot of the stuff we were doing there was around considering what you might call the operator experience, the experience of teams who are running the systems. What do they need to see? How do they need to see it? What what do they need to do - for example, in this particular case, so we're working on systems that were involved in processing visas, processing immigration applications - that kind of thing. And if one of those applications got stuck, then someone's case would be delayed effectively, for days or hours or days. And that can be quite upsetting, and it sometimes needed a metaphorical prod in the machine, or - something needed to be reset.

And so the ops people would have some their responsibilities, around looking to see why things have got stuck, if you like? Like in many, many situations. In many different organizations - not just government, but in all sorts of organizations - the experience of the operators is not front and foremost of the minds of people who are specifying what needs to happen. They're thinking about the primary users of the system. And actually though, to make things really, really effective operationally - we actually need to think about what these live service or ops people need to do, and see how they need to search for stuff, how they need to diagnose things. We did a lot of work around that.

Len: That's really interesting - that's relevant to the question I'll be asking you in just a couple of minutes about your book, Team Guide to Software Operability, where you talk about how - when you're building something, keeping in mind how it's actually going to operate in the real world. And then there are people that are operating it in the real world, it's really important.

But just before we get to that, so - the inevitable Brexit question. I was just wondering if you could talk a little bit about your thoughts on Brexit, and perhaps in the context of the tech sector? It is a huge and various thing in the UK, that - covering all kinds of things. But what's your sense of things - how do people in the tech sector in general feel about Brexit? Do you hear worries about recruitment?

Matthew: I think there's a whole lot of different, many different strands to this. I mean, my personal view is that it's going to be hugely detrimental - it already has been detrimental to lots of industries in the UK, and it'll continue to be that. I think it's hugely misguided for lots of reasons. But I think some of the things that Brexit will do is drive technological innovation in a few different areas.

Agriculture is one. Because, whereas in the past 40 years we've relied increasingly on lower-cost agricultural laborers from other parts of the EU - almost all of that labor has disappeared. There's no other - there is food, there is fruit and vegetables rotting in the fields in Britain, because there's no one to pick it. And so what that's driving is increased automation of fruit picking technology, it's driving investment in vertical farming. These are large warehouses where we've got plants, crops grown in almost like data centers. It looks like a data center. An old style big warehouse thing, with multiple robot gantries, and fruit picking things inside the factory. It's definitely driving investment in agricultural automation.

It'll drive investment in technologies around healthcare as well. Because here we have been - sadly, I guess - reliant on workers from EU and other countries in our healthcare system. But many of those people have left as well recently, so that will also drive innovation in the healthcare technology space. Along with things like automotive, cars and things. Because our car industry is now basically dead since Brexit. There will be a need to drive innovation in other areas too.

There could be a real opportunity - I'm trying to put the best spin on this as possible. - there could be a real opportunity to avoid, to reduce car usage - and look at other forms of transport which are much more sustainable and environmentally friendly, avoid pollution - things like electric bikes. There are actually some manufacturers in the UK, and electric bikes are really taking off. These are pedal bikes, but they've got a battery as well. And so it's much easier to climb a hill on these things. Obviously it's fairly easy to make an electric bike, compared to making a car. Although that I think there's going to be a huge amount of damage done, I think there will actually be an innovation that's relevant to people working in software.

Len: Thanks very much for sharing those thoughts. You've brought up some things that I haven't thought about before. But it's really interesting - when you talk about the - I mean, this is something people talk about in the American context as well. But people, for example, losing jobs in car factories - at the same time as fruits and vegetables are rotting on the vine. And it says a lot about the work that people feel they should be doing, and the work they feel other people -

Matthew: Definitely.

Len: Should be doing. And there's this really interesting internal contradiction to the logic of nationalism. Let's say, narrowly construed nationalism, around issues of labor. And when people's forms of work get tied up with their identity, technology poses, to some people, this incredibly exciting opportunity - and to other people, this catastrophe.

And these contradictions are woven into the problems that we're seeing in lots of things all over the place, right? Particularly with respect to automation, it's reminding me of something, that when I first lived in London, I had a friend who had a roommate - and actually he was from near Reading. And there was a news story about a bunch of long term unemployed steelworkers who were at a football match for their local football team. And by which, I mean soccer to any North American listeners.

And they engaged in a racist riot. And I took the opportunity to ask my friend's roommate - I put it naively on purpose. "But, what's going on here? Why are they doing this?" And he said, "Well, you need to understand Thatcher closed down the steel mills, and they've been out of work since - and so they're full of resentment." And I said, "Well why didn't they do something else?" And he looked at me like I was the biggest idiot in the world, and said, "Len, you need to understand - they're steelworkers." And it really struck me how - I would have been able to give the right answer to if someone had asked me the question, but it was really having it driven home into my heart, as it were, that people can become really attached to a way of living that involves their work.

And it might be like a factory job where their dad worked, and they got their job because their - I'm thinking in gendered terms here, in factories. But we have this issue in parts of Canada as well. Where like, it could be generations since the main breadwinner in the family actually had to go out and seek their own job, because it was always dad made a call to the Union. And there's something very unsettling about certain types of change that can make people feel like there's something they're losing, when in fact what they had was very tenuous and artificial in the first place.

Matthew: I think there's some interesting green shoots of optimism, if you like, around some of this stuff. Particularly with some of the some of the innovations in - these micro small computers like the Raspberry Pi and Arduino, and these things. Where they're obviously physically very small, they literally fit in your hand. they're not threatening in that sense. And a lot of the coding courses that have been developed to suit these devices are incredibly accessible.

In fact, so I was involved - one of our partners, through Conflux - the Foundation for Digital Creativity is based here in Leeds in the UK. And they've done a lot of work with younger people. But not just younger people. With other groups as well. So, some of the coding, like training courses and things, it doesn't even involve typing out code. It involves using drag and drop and configuration things, are at a slightly higher level. Like the concept of an if statement, a concept of a loop, the concept of a decision.

But, without actually having to type it as a stream of characters, you construct the algorithm on screen using drag and drop blocks. I was skeptical at first - but actually, it was really useful. Because you're thinking about the fundamentals. You're thinking about the flow of logic, rather than actually the typing. And you don't have to worry about the syntax. It generates Python or something behind the scenes, right? it actually then runs proper code.

But as a much more accessible way of getting into software, it was really powerful. And the kids who are learning this stuff are doing amazing things now. There was a gap in the like 90s and 2000s where this stuff really wasn't available. Whereas now, we've got computers that are much more accessible to a much wider range of people. They're taking this stuff into public libraries, and even like old people's homes and things like this. And getting like85 year old grandmas to write some code, it's amazing to see how accessible this stuff is.

I think it's an interesting time, where we actually will be able to enable a huge range of people who are not necessarily techies, but they want to do something useful with computers. One person I was talking to, she does textiles. And she wants to dye, she wants to color - she wants to dye wool a certain color. But the the wool dyeing process needs the liquid to be like a certain temperature for a certain time. She can write her own algorithm using like a Raspberry Pi, Arduino to test this. And then sound an alarm when the fluid's at the right temperature. And then, she can do her own wool dyeing.

She didn't want to be a programmer - she's a textile person. But she's going to use a computer, she's going to program it, in order to help her do something. And I think that's the key to broadening out the use of computers and things to a wide range of people is - let's not obsess about getting people to be trained up as programmers, let's get people to be unafraid of writing a bit of code to help them do something else. I think there could be a real opportunity for a huge expansion of how we see and use computers in this context.

Len: It's really interesting. I think we could probably talk about this--

Matthew: All day. No, I find it fascinating.

Len: Yeah, I know. One thing that I was just really thinking about when you were talking, is that - I mean the way, what people think work is. For some people, and this goes back to the origins of writing, but my brother, who's an English professor has a joke that like, "If you see someone with their chin in their hand like Rodin's famous statue, some people think, 'Wow that guy's working really hard.' And other people look at it and say, "That guy's doing nothing, he's just resting.'"

And to some people, the idea that thinking and writing - which is what programming is - doesn't seem like work at all, and it doesn't feel useful. Whereas moving - I mean, to put things into these basic terms. But like moving things around and putting things from one place, building a structure feels, like work. This thing was over here, and now it's over there. These things were just a pile of something, and now they're an orderly structure of something. To some people, that can feel real, in a way that typing doesn't. Which is why we have this whole language about like how - I mean of course there's nothing ghostly going on when you're interacting with a computer. But we use terms like "virtual" to describe the things that they do with it, because we have - I mean generally speaking - because there's just something kind of -

Not to go way off into the philosophical weeds - but there's something uncanny about the invisible work that's done by a computer, compared to mechanical work; It's interesting, nowadays we say "technology" to mean "computers." When of course, a chimney is a form of technology, policing is a form of technology. But what we see is real, and what we don't are - seem to be very deeply ingrained in us. For some people, what you're talking about, being trained as a programmer just sounds like, "Oh my God, that's the last thing I ever want to do."

Matthew: Yeah.

Len: It just seems fake and unreal. And by making the way you program more tangible, that might actually really serve to make it seem more like real work to people.

But, not to hijack this too much - just moving on. You brought up operability, and so just one or two questions about your book, Team Guide to Software Operability. This is a really interesting book, where you and your co-authors talk about how "You should treat software operations as a high skill value add activity, not support tasks."

Len: I like this idea. You talk about how often companies will devalue the operational side of things and call them "non-functional requirements," as opposed to operational features. And you can just see the like - I don't know? The non-technical executive going like, "Why doesn't our website have this button working yet?" And you're like, "Well, because of this blah, blah blah, blah, blah, blah, blah, blah is the op stuff - and people really need to think about that as features, rather than just blah, blah, blah."

Matthew: Yeah. This is based on the work that we've been doing for a long time, really. I remember the first logging system that I put into place was for - a long time ago now, back in 2002, 2003. I was writing software for the oil and gas industry, where we were taking data from sensors that were at the bottom of the oil wells. This was like hundreds of degrees Celsius and a crazy amount of pressure. And so we had to then grab that data and remove all the errors, and then display it. We had to log quite consistently and carefully what was going on, because once you put a sensor at the bottom of an oil well - it's cheaper to drill a new oil well than it is to take the sensor out and replace it, or to repair it. You're talking about an expensive situation. I actually had developed some logging, which was really robust but resilient - and the software itself had to be super resilient, so that it wouldn't crash halfway through the data collection and this thing. And so I guess I've had to work in situations where the operational aspect of the software was always was always front and foremost. Because of size, because of the sensitivity - or because of the cost of getting it wrong.

And then a few years later, I was one of the leaders - the software architects on a big system for the London Stock Exchange. We were building out, not their primary trading system, but their secondary system. And we made sure to put operational concerns to the fore in that one. 10 years later, I caught up with a colleague of mine, who I was working with at the time. I caught up with him actually just last year. 10 years after we launched it, the software is still running.

I mean obviously it been modified and so on, and improved. But the foundations were still a foundation that we put in place back in 2008. That brought it home to me how this focus on the operational aspects of software can help organizations to get the most out of the software they're building. They have software that's not falling over all the time. that it's easy to diagnose what's going on, if there is a problem.

We've taken a team-first approach with Team Guide to Software Operability, and its companion books as well, so, Testability, Business Metrics, and Releasability. Because we wanted to demonstrate and share some practices which work well in a team context. It's not just about an individual developer or tester learning some skills. It's, "Here's how to do some stuff at a team level. Here's how to share information. Here's the - in this case, co-discover some operational requirements. Co-discover how to define whether the software is ready for service." These things.

And it's proving really valuable to lots of different people. We were at a conference, Continuous Life Cycle, in London a few months ago. We brought with us some big tabletop-sized printed sheets, with some operational questions and things like this. Every single sheet was taken by people, because they heard about this stuff and came to the stand and took them away. They realized the value of actually having the entire team sitting around a table, and discussing in detail all the aspects of operational readiness that this big sheet covered. We're finding this team focus on operability and similar aspects, to be actively really resonating with people in organizations who are struggling with some of these things.

Len: You write in the book about how most - even books that are about teams, are written to the individual, whereas this book is actually written for, to be read by a team.

Matthew: Absolutely.

Len: One thing actually I wanted to talk to you about, is Conway's Law. I know this is a bit of a, this is a big topic. But if you could maybe spend a couple of minutes explaining what Conway's Law is? Because this is a very important concept.

Matthew: When I first came across Conway's Law, I think it was through Allan Kelly? A UK-based software person who's got lots of experience, and gives great talks.

Conway's Law is this mirroring that occurs between the communications, between parts of the organization and the system that the organization builds. The way that Mel Conway described it in 1968 was, basically a constraint on the software system - or the systems that an organization can build.

The original 1968 paper by Conway is actually really, really interesting. There's loads of stuff in there. And a lot of people don't actually read the full paper. It's definitely worth digging that one out. It's called, "How Do Committees Invent?" There's loads and loads of gems in there.

What actually is a really interesting thing about Conway's law, is that it's actually a proper - it's a really strategic limitation on the organization. In the paper, Mel Conway talks about it this mirroring force being a constraint on the solution search space. An organization that is set up in one particular way, with communication between teams or between different people in one particular format - almost certainly will not discover certain solutions. It will not discover certain software architectures, it will not discover certain ways of doing stuff - just because of the way it's communicating within the organization.

And that's an exec-level limitation on the organization. When we're doing this knowledge work, when we're in a fast moving, rapidly changing context - using software to give us that leverage that enables us to adapt things very quickly. Because obviously that's one of the main advantages of software. It's not just about processing information, it's about the fact we can adapt it very, very easily.

Then your organization design can constrain the things that you're actually able to do as an organization. And that should set alarm bells ringing for any exec or C-level person in an organization. Because they might be trying to do certain things, but their current organizational design is actively constraining or actively limiting the likelihood of them actually being able to come up with a decent system or solution to to a particular market problem.

Len: And so when you say, "organizational design," just to drill down a little bit. Do you mean like - for example, I think I'm recalling a talk that I watched you give on YouTube, where you talked about how there were different - financial incentives for employees came in the form of not just salary, but also bonuses. And these bonuses were linked to - if you did 10 tickets in a week, or something like that - on the support desk, you'd get a bonus. But then there was some incompatible type of bonus that was doled out to another different team. I guess, I'm just trying to think about this at the theoretical level. If your organization is designed around bonuses for reaching targets, there might be certain types of solutions that your organization just can't do.

Matthew: No indeed. And likewise, if your organization is very hierarchical and needs information to flow up and down a permission tree, so that it hits the person who's highest in the organization, and people lower down can't make decisions - then, again, you'll be limited in the solutions that you can come up with.

Lots of organizations more recently have found that a really effective template, if you like, for the design of their organization, is to have smallish cross-functional teams. a mixture of skills inside the team, up to about, between five and nine people, maybe? Something like this. And they're focused on one specific part of the business domain. It might be accounts versus payments, versus orders or something more specific than that, if it's a larger organization. And one of these teams has basically all the skills it needs to go from idea to realization of the idea in working software.

Now it gets a little bit more complicated when we've got hardware and the real world involved. Because it becomes really difficult to get a cross-functional team that can do both web, cloud software, and physical hardware design. But that's a slightly more advanced topic.

But generally speaking, if we can get a team that can take an idea through to that idea being produced or running = they're more involved, they're more engaged - they're also closer to the information. That team sees how stuff runs in production. Effectively, that team then starts to become an organizational sensing mechanism. It starts to become a little bit like eyes and ears. They're so close to how that stuff is running, that they're able to then get that information - or bring it back into their design, build, run process - and effect a change really, really quickly.

And this model is backed up by recommendations from, for example, Stanley McChrystal, who is a former general in the US Army. Who, over the period of one of the Gulf wars, realized that they had to fundamentally change how the army worked - the US Army. That's changed, from a very command and control hierarchical thing, to a much more distributed control. Where intent was specified centrally, but then execution was devolved out. And this seems to be an effective model for going quickly, safely - where the world is changing rapidly, and where we need to be able to respond to what's out there. We can't predict what the world is going to be like in even six weeks or two weeks’ time. We need to devolve some of the decision making.

Len: That's really interesting. I've read a little bit about that. About how - instead of, "Take that hill by doing X, Y and Z," you send out a team. But, I mean, of soldiers or Marines or what have you, and say, "Take that hill, but you guys--"

Matthew: "Figure out how to do it."

Len: "Figure out how to do it yourself."

Matthew: Yeah.

Len: And so, there's this autonomy and empowerment that the team is given. But crucially it has to be guided by a clearly communicated goal.

Matthew: Goal or intent, yeah.

Len: Goal or intent even.

Matthew: Yeah.

Len: But the clarity of communication becomes even more - I mean I was just actually interviewing someone who worked at Spotify, just the other day. But there's this idea, that all this decentralized autonomy comes at a cost. There's a price you have to pay. And the price you pay is communication. You have to pay a lot more. You have to put a lot more focus in thinking into how you communicate, when you have decentralized autonomy in this way. And on that note, your latest book is, Internal Tech Conferences, which is all about communicating and finding, letting organizations know how much they know, to some extent.

Which you wrote with your co-author, Victoria Morgan-Smith, who works at the Financial Times. I was wondering if you could talk a little bit about that book? How did it come about that you and Victoria decided it would be worthwhile to write a book about running internal tech conferences for organizations?

Matthew: This goes back several years - I think five years or so, when we were both at a conference in London. Victoria had done a lightning talk on her experience of running their first tech conference internally. And at that time I'd been running effectively the same thing, internal tech conferences at the company I was working for. We just got together and decided to collaborate a bit. We wrote an article for InfoQ on exactly this, internal tech conferences. We interviewed a few other people from different organisations, and compiled an initial, "Here's some ideas on how to do it," based on our experience at the time.

And then fast forward to last year, we realized there's a few more companies who are out there who had actually been doing this - and been writing about it, and there'd been some different ideas. We decided to expand what we'd already written, expand our experience. And since then I'd run some more internal tech conferences. I'd helped other people to do that as well. And Victoria had run several more years’ worth of these events, where she works at FT. And so it felt like the right time to do it. We got some great case studies in there from a few different organizations, and it was nice to be able to follow up on some of the early material, and see what's changed.

Some of the technology has moved on as well, since 2014. Things like full screen videoconferencing type technology, is now basically ubiquitous. I mean I'm talking to you across an Atlantic divide - and it's perfect, basically. The quality is great. That's just an amazing enabler to bring, to be able to reach remote offices. If you've got an internal tech conference day, and actually you want to bring in speakers from across the other side of the world - it's basically doable now, which is an amazing - really it's an amazing thing - magic, basically. As far as I’m concerned. The technology's moved on to an extent where we've got more opportunities for including more people in these events.

Len: One of the themes of the book, and the whole idea of having internal tech conferences, is that often people end up being siloed naturally, within companies. And this has the effect that you can be reinventing the wheel all the time. But it also means that people don't know what everybody else is doing. And you don't really have - your sense of what your work is, is all about what you do every day. But actually you're part of a big organization that's doing all kinds of different things. And understanding that - not just how the whole thing is operating, but that you're playing a role that's useful in a particular way, and so is everybody else - and it all comes together. An internal tech conference can really help think about what they're doing.

Matthew: Exactly. And I think it shows a good degree of organizational maturity when an organization actually decides to run one of these things. Because you're doing lots of things. You're investing in people - individuals, in terms of preparing a talk - preparing them to be a speaker. You're investing in different groups in the organization, because you're able to showcase what different groups have been doing. You're also being honest as an organization about how important certain things are.

You might say, "Hey, we've just built a brand new relational database." And then if you present that an internal tech conference, and someone - most people will probably say, "Well, why didn't you just use MySQL or SQL Server, or Postgres or Oracle or whatever?" Maybe there's a great reason, but actually maybe you just wasted like many, many, many, many years’ worth of people's time? And so it's a good organizational health check, or way of validating what you're doing as an organization - to run one of these events.

Because you have to surface what's going on in different parts of the organization, and work out what it is about what you're doing that's good and worth celebrating. What it is that maybe has been more difficult, and you'll still want to share it - because you want to bring that to the surface and get some feedback from people. The organization has to be mature enough or transparent enough that people feel safe to be able to do that sharing. It can really help to raise the game.

The organization where I ran these internal tech conferences - what we did was, every six months we ran a half-day event. And we actually invited everyone - at the time the organization was about 300 people in size. Everyone was invited. The technology team was about half that. But we invited like legal and HR and marketing, and all these different departments. And it was brilliant, because we're able to demonstrate what was inside this technology machine, if you like?

It really helped to build some bridges with other parts of the organization. They really started to understand why it takes so long. Because you've got to do all this migration stuff. We've got to test the backups. We've got to - physically it takes like two days to move that data out of the data center. "Oh, well why can't we just use a cloud?" "Yeah, exactly - let's use a cloud then." it really helped to open some eyes and get some buy-in to some of the stuff we were doing at the time. I think it can really, really help an organization - to run an internal tech conference, it really helps an organization to raise its game, basically.

Len: It's really interesting too, there's all this high theory. But one of the themes of your work is that the operations - it all comes down to operations in the end. And on that note - one of the great things about the book too, is that they're - like, all of this great stuff only works if it works.

Matthew: Yes.

Len: On that note, I wanted to ask if you could talk a little bit about the importance of food at conferences.

Matthew: Linda Rising, who is expert at organizational change - and she's written several books in this area. One of her patterns that she talks about is, "Do food." When you're trying to effect organizational change, make sure you do food. And that's because food brings people together. It has to be good-quality food, it can't be a few limp sandwiches and some cups of fizzy pop. It has to be good food. It's worth spending on. People feel that they've got something different, something that's worth eating.

But there have actually been some like academic, scientific studies done on this stuff with different groups of people. And the groups that had like cake or food or whatever, performed significantly better than those without. And so even at just that level, you have to make sure that food is part of the mix. It brings people together, it's a nice way to make sure that people can mingle. Because it's a neutral space, over lunchtime. If you're doing a full-day internal tech conference - then the food can stimulate, it acts as a stimulation for a wide range of different conversations at lunchtime. People mingling all together and talking about the morning events, and talking about what might happen in the afternoon.

It would be a big mistake, if you're running an internal tech conference, it would be a big mistake to have no food. It would be a big mistake to have poor food. You have to have food that people are going to remember that feels nice, so it feels like a special event.

Len: Yeah, on a number of different levels, it needs to be seen as desirable and enjoyed when people go.

Just moving on to the last part of the interview, where we talk about your experience writing. You've written a book with O'Reilly, I believe? Continuous Delivery with Windows and .NET.

Matthew: Yeah.

Len: And you're currently working on a book called Team Topologies: Organizing Business and Technology Teams for a Fast Flow, which will be coming out with IT Revolution Press. But in addition to your conventional publishing books, you've also decided to publish some books on Leanpub.

I was wondering if you could talk a little bit about why you decided to do that?

Matthew: The first book that I worked on through Leanpub was called Build Quality In. This is back in 2013, and we published in early 2014. A collection of DevOps and continuous delivery experience reports from around the world. I was one of the editors, along with Steve Smith. What attracted us to the Leanpub platform was - well, it was several things.

Firstly, as techies, we could write the book in Markdown. Which is great, because that felt really natural. We can collaborate using version control in git, and then just push the changes - and it would trigger a build. And then we'd get the nice, new PDF coming down through Dropbox. I mean, when I first came across it I thought, "Wow, this is genius." This is, like, the simplest mechanism that can actually work, and it still works really well. It really appealed, that - the feel of like the operational side, the techie side behind it - it felt very nice.

But actually - the model, the Leanpub model of "publish often and get feedback," also felt like something that tied in so closely to all the stuff we were doing. Like, we're literally writing a book on continuous delivery, so let's use a publishing approach which feels very similar. It felt really important for us to follow that model through. And to be able to do it like that incrementally and get some feedback.

And so it's been good since then to use the platform, because the support we get has been really great. If - like occasionally, we'll find like a small problem with something - and I've emailed in. And then within like half an hour or 30 minutes or something, you get a response back saying, "Oh yeah, we've found that problem and it's going to be fixed soon." And it's fixed in a couple of days or whatever. The responsiveness as a user or as an author or publisher on Leanpub, has been awesome. I can't imagine there's another platform that has that level of responsiveness. For digital publishing, I think it's really good.

Len: Well, thanks for the kind words and for sharing that story. That's really interesting. I mean, one of the ways we've consciously decided to build Leanpub, is to listen very closely to what authors are saying. That doesn't mean do everything they want.

Matthew: No, exactly.

Len: But we try to treat every genuine signal as a problem to solve. That's what makes support interesting. If, for example - if you get to treat it as a puzzle that needs to be solved. And so if you people are - this is just kind of normal startup stuff. But if someone's found a bug, well that's a bug - you try to fix it as quickly as you can.

But then you treat it like, why did that bug occur in the first place? What's the deeper structural issue there? And part of, also - one of the reasons we can have confidence that what we're hearing are signals, is that so many Leanpub authors are technically-minded. I mean, they're writing books, right? They're probably smart people to begin with. But we've got all these technically-minded people who actually will send us screenshots showing the console in Chrome or whatever - what the error message is.

So anyway, we're very fortunate that when we get reports of issues, actually people often know how to communicate on ways that make it easy to solve, or easier to solve.

The last question that I always like to ask people on this podcast is - if there was one thing we could build for you, or one thing we could fix for you, what would you ask us to do?

Matthew: It's a really good question. The thing that immediately came to mind was actually just discount codes. You've got the coupon thing currently, which is like a URL. But actually, just being able to - because the it's difficult to shorten. It would be nice to just be able to copy and paste a discount code into the checkout box. That would certainly help in lots of cases, I think.

Len: That's really interesting. you're the second person to say that in the last, like, three interviews I've done, I think? The answer is that - if someone has a coupon code, they need to enter it somewhere. Which means that there needs to be a coupon code box. And we used to have this.

But when a normal customer goes to your book's landing page and they see a coupon code - if they don't have one, they might not buy your book.

Matthew: They get sad.

Len: Otherwise they would have [bought it]. I mean, a lot of people just don't care. They're just like, they want to the book. They're going to buy it if the price is right. That's fine. But there is a certain type of customer for whom that is a very unpleasant experience, to see, "Oh, there's a coupon code. If only I had it, then I could get the discount." And then so what they might do is like, try contacting you. And so now they're, legitimately - but now they're taking it like on Twitter or through email or whatever and being like, "Hey, Matthew. Can I get that coupon code?"

Matthew: Yeah.

Len: And you're like, "Well, the coupon code expired, because it was only for during this conference." And then they're like, "Well what - but there's still a coupon code box on the landing page for your book." And so, actually having coupon codes - well, for those who get it and get to enter it - that's a great experience. But for everybody else, seeing a coupon code box when they don't have a coupon code, sucks.

That's the reason we decided to go with coupon links. You get a link and then you go to a page that's designed for that coupon link.

But we're always willing to revisit decisions that we've made. And since you're the second person to bring this up, well - we take that a strong signal that there's something that authors are doing, or want to do, that solves a certain problem with people, that we're not offering right now.

Matthew: One other thing that could be really interesting - which is harder, it's much harder - would be some plugin mechanism into the book generation process that would allow additional checks to be plugged in. For example, the service called - is it called Grammarly? One of these like grammar-checking and style-checking things.

Imagine something where you could plug into that and have something do a tiny bit of like copy-editing type of assessment into the PDF generation process. That would be a bit awkward, because you're effectively running someone else's code. But if there was some way to hook into that, because that could be a super interesting thing. I can think of a whole lot of stuff I would want to write, to assess all sorts of stuff about what the authors have written.

And this is coming from the viewpoint of a publisher now, through Conflux Books, where the Internal Tech Conferences book is published through Conflux Books. And where that's the first of hopefully many different books that we're going to be publishing. In that guide, I'm actually acting as a publisher or editor. And it would be nice to be able to do a whole lot of editing checks automatically - and be cool to have like a little marketplace, or something like this where you can - oh, enable that plugin for checking grammar, and enable this plugin for checking spelling, enable this plugin for checking something other - other style things, and getting output - during the build process, that could be cool.

Len: That's a really interesting suggestion. A couple of things I would say about that. One of them is that - the furthest reach of what you're describing is: imagine I could click a button and the book would be translated into a bunch of different languages, and there'd be an audiobook. These are the kinds of things that technology actually, like - I mean, there's certain types of books where I don't believe machines will ever be able to properly translate them. But with the prescriptive nonfiction books that are typical of Leanpub books, actually automated translation is something that is probably achievable. A book about how to learn git, that's probably something that actually could be translated - if it were written in the first instance in the right way.

So, the like space age version of what you're asking for is click a button and the book gets translated into lots of different languages and it, and audiobook versions are created, and stuff like that.

And so then on another level it's like, "Can I hook various services into what happens when I generate a Leanpub book?" That's something that - because of what you're talking about, as you've mentioned - that's other people's code. That can be very complicated. But, one thing that is not so complicated is us showing authors - directing authors to these different services. Because , even if we can't build - or won't, or it would take too much time, or we might do it someday - but there's nothing stopping us from providing these resources to authors in our Help Center or somewhere in our documentation saying like, "Hey, by the way - one thing you can do is you can just upload your manuscript here and run it through this service, and then you'll get this."

Because we have one guy who - he speaks, I mean he speaks English in the way Germans do, which is very well, but when he was writing, he was a little bit less confident. What he would do is, he would write in English, and then he had this online service where he would translate it to German, and then he would copy and paste the translation from that service, and then paste it in again and translate it back into English. And so he would iterate on his grammar-checking that way.

Surfacing to authors these kinds of practices and services - whether we build features or not - is something that we could definitely help people by doing.

Well, thank you very much for those suggestions, Matthew. And thank you very much for taking the time to do this interview, and thank you very much for using Leanpub, and for being a Leanpub author.

Matthew: Oh, it's great. It's great to be part of it. Thank you.

Len: Thanks.

And thanks as always to all of you for listening to this episode of the Leanpub 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 yourself, please go to our website at leanpub.com. Thanks.