Victoria Morgan-Smith and Special Guest Sarah Wells, On Digital Transformation in Journalism and Internal Corporate Tech Conferences

Len: Hi, I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast, I'll be interviewing Victoria Morgan-Smith and Sarah Wells.

Based in London, Victoria is director of delivery for internal products at the Financial Times. Before taking on team-leading roads at the FT, she was a developer for a few years - an experience which informs her current leadership role.

Also based in London, Sarah is technical director for operations and reliability at the FT, where she leads a team that brings together existing delivery enablement and first-line support teams.

Victoria is co-author of the Leanpub book Internal Tech Conferences: How to accelerate multi-team learning across departments.

In this interview, in addition to talking about Victoria's book, we're also going to talk about Victoria and Sarah's own paths to working on the IT side of a major news organisation, and some of the work they've seen and done within the FT during their time there.

I'd like to add that I've really been looking forward to this interview. I think those of us with an interest in journalism and tech often hear about things naturally enough from the point of view of journalists and readers, and I think it's going to be really interesting for our listeners to get to hear about things from the perspective of people who made their way to working on the tech itself.

So thank you, Victoria and Sarah, for being on the Frontmatter podcast.

Victoria: Thank you.

Len: Thanks. I always like to start these interviews by asking people for what I call their origin story. Victoria, I was wondering if you could talk a little bit about where you grew up, and how you first became interested in technology and the web?

Victoria: I originally grew up in Cumbria, in the north of England. Which seemed - and I guess, was, miles away from any big city. So business and tech was a long way from my radar.

My early ambitions at that point were to do teaching, something you can relate to pretty much anywhere you come from. I wasn't ready to commit to teaching, so I did a degree in English Literature instead, so that I could do some post grad teacher training and test my theory while I was studying that, as to whether or not I could teach.

It was a good thing I did. Because I realized that children in groups of more than two terrified me. So then I had to do a quick switch and - so ultimately, really what happened was I stumbled into technology. Because working out what I wanted to do next, I then did a Master's in computing to learn a bit about, essentially how to use a computer and how to do smart things with it, while I worked out what I wanted to do. And during that time, I discovered that this coding stuff was actually quite good fun, and I quite liked it and I was quite good at it. That's how I ended up finding a job doing development - a complete accident in the end, but I enjoyed it.

Len: As a recovering English major myself, I wrote a DPhil in English, and then went into investment banking in London for a few years. So I had my own experience - coming from something that people often think isn't really very applicable, to something else, and finding it very much was. Did you find that your background in English helped inform your work that you did later?

Victoria: I would say not particularly, but having taken time to - I suppose my early interest in teaching did help, when I then went from doing coding to other things - the idea of education and bringing people together. That helped in my later degree, later career. But in terms of programming, did my English degree help? The degree of learning to study and how to apply yourself and analyze and think - all of that probably helped. But I don't necessarily see a huge number of parallels between the two.

Len: Fair enough. I can see from your profile online that you worked for a few years as a developer, as I mentioned in the introduction, before becoming a Scrum Master at one point. I was wondering if you could talk a little bit - for those listening who might not know, about how that switching roles came about - from being a developer to being a Scrum Master and a team leader, and a little bit about what a Scrum Master does.

Victoria: Oh, yes. I did enjoy being a developer at the time. But while I was doing that, I was always interested in the conversations beyond the code. I was always interested in how we work, how we engaged as customers, and the way team members could collaborate to solve problems. So it was that connection piece. And pre-Agile, I'd looked at - with horror - at a project manager role, which seemed to be that awful stuck-in-the-middle bit, where the client would get grumpy with them for the project being late, and the team would get grumpy with them for making promises on their behalf.

And so then when I came to the Financial Times and discovered Agile, that's when I also discovered the Scrum Master role. Which is quite different. It's got parallels to project management, but it's quite different. Because the focus is more about helping the team to plan and coordinate their activities. So it's a supporting role. Those plans and activities are owned by the team, but the Scrum Master is there to provide some structure, to help them think, to reflect, to encourage good practices - and it's much more about helping others figure out how to achieve what they need to, and be the best they can.

And that is what appealed so much more to me than the project manager who makes all the plans. And so really, while I was doing development, during that time I'd shown a natural bent towards bringing people together. So it was a relatively natural thing that happened here. It's the type of company where you get the opportunity to try things. I had a secondment that worked out. And so when an actual role became available, I could apply there and then, and the switch happened.

Len: And what's the difference between - I mean, it's now getting a little bit old, but like a sort of conventional waterfall project manager’s relationship between management and executives, and the relationship that a Scrum Master might have with that side of things - and someone working in the Agile framework?

Victoria: It's a different type of accountability. So, as a project manager they will often feel that they are the one who is accountable for making sure this thing gets delivered on time, to budget, and ticks all the boxes. You've got a plan, you've worked out that you're going to do - and the focus is on tick, tick, tick - those things are delivered, regardless of what you may or may not learn along the way. So your focus and your attention is all about pushing and, "Can we get this done faster?" And it's just about doing that thing.

Whereas the Scrum Master role is often, it's much more about - maybe setting some expectations, but helping those conversations go about, "What are we trying to achieve?" We're going to form some plans together. Those plans may change." And it's a different level of commitment - it's enabling those ongoing, continuous conversations between the engineering team and the business and management teams - and trying to bring them closer together, so that the conversations evolve, and the plans evolve as you learn, and as you may pivot. It's a slightly more healthy and open conversation, [compared to] when you feel as if your head's on the block, because everyone's looking to you to make it all just happen and get done.

Len: Just one last question, before we move on to hearing Sarah's story. Victoria, was the FT sort of ahead of the curve, with respect this type of management - or this kind of technology development style?

Victoria: Well, I suspect so. I mean, I joined - I've been here 15, 14 years. And so when I first came here, they were talking about Agile, which many organizations weren't. They were trying to implement it. And they had a long way to go. There were many, many things that weren't fantastic - but they were trying. Ot was a thing that the company was trying to shift into. So I think, probably - compared to many organizations, they probably were.

Len: Thanks very much for that.

Sarah, I was wondering if you could tell us a little bit about your own background? I believe you have a background in publishing actually, before you got into tech - and how you became interested ultimately in software development and technology?

Sarah: Sure. So I didn't ever really have a strong view on what I wanted to do. I kind of knew things that I was interested in, but I didn't have a real idea. So I followed things I was interested in, in terms of subjects. I went and did a degree in natural sciences, and realized very quickly that I didn't want to work in a science lab. Because I went and did it for a summer, and ended up doing history and philosophy of science - which is a fantastically interesting subject. It's not particularly applicable to many jobs, but I went into science publishing.

I did journal production editing, and then book production editing. Which is - it's a very organisational job. It's proof reading, copy editing - you're doing all the steps that produce a book. And after about six years, I got made redundant. Which is a kind of a rite of passage in publishing. It happens a lot. And it made me stop and think - do I actually want to carry on doing this? Because actually every book that you publish, just is the same set of steps. And I knew how to do that. I wanted a job that was going to be a different problem that I was solving every time.

Around this point, I met someone who was working as a software developer - and I thought, "Actually that sounds like something that would give you that problem solving." So I went and did a Master's, a conversion course. That was in '99, and I've been working in software development ever since.

Len: The next question I have is for both of you. It's a question that comes up often with technical book authors on this podcast, and it applies to both of you, which is great. If you were starting out now with the intention of following a career in tech and perhaps in software development, would you formally study Computer Science at university. So Sarah, we started with Victoria's story - why don't you go first with this one?

Sarah: Well, I think it's interesting that you're going to ask Victoria and me this, and neither of us formally studied a three year Computer Science degree. I find a lot of the women that I work with, who are not from the latest of cohort of people doing things like Makers, did conversion courses. Because we basically got to the point of thinking, "Well, now I want to get a job in IT. I'll go and do a Masters." If I was doing that now, I would probably be likely to do something like Makers Academy, something that's very business-oriented, quite focused on exactly what you need to know.

I really enjoyed my conversion course, but I would say that it was very much an academic thing, where the people who were teaching didn't know the things that we would need to know in the industry. So we weren't learning - this is in '98, '99 - I was learning C. But really, you'd have been learning Java Java or C++ if you were going to be going into the industry at that point. And I think there's a whole bunch of stuff related to that. So I think, very focused courses - it's not such a big commitment in terms of money or in terms of giving up other things. And they teach you how to use source control. They teach you how to do the stuff that actually means you can go into your job and know what you're doing.

Victoria: I would agree actually on all of those points. I'm not sure I would've gone to university, if it cost as much as it cost these days. It is really expensive. And what you learn in a computing degree, I do often wonder. As Sarah says, it's how relevant a lot of that is. Because technology's changing so much, by the time you get to the end of three years, what you were learning in the first year might not be particularly useful. And if I do look back at my lecturers in - even in my Master's, I don't know that any of them had any industry experience.

So in terms of their ability to teach, and stuff that was meaningful and useful once you're in a career - I would say was limited. We've had some really good successes of bringing people in from schemes like Makers, where it's short, it's sharp, it's meaningful. And it is quite a commitment. So it's not an easy short cut - just because it's shorter, it still requires quite a big commitment. But they really learn stuff that's immediately valuable. And I would probably be much more likely to recommend that sort of scheme.

Sarah: I think it's interesting. Because a lot of the people we've got in through Makers actually did probably do a degree in something else. And then they've worked for a bit, doing something else. I mean, it's a mix. And you gain quite a lot from what people have learnt in their degree and in their work before they do that, I think, as well.

Len: I wasn't planning on asking this question, but it sounds like you've both been involved in some hiring. And so, you're suggesting that having a Computer Science degree - whether it's a conversion degre,e or a sort of full undergraduate degree, actually isn't necessarily a requirement in an organization like yours - for being hired in a development role?

Victoria: It's not. But we work closely with partner organizations for these things. We have apprentice schemes, we have people in on internships. We work very, very closely with Makers Academy, who run a 16-week learn software development process. So we tend to do it through some kind of structured set-up, where the people coming in get the support that they would need.

Len: You mentioned the expense. This is a little bit of politics and history, that we might want to go into for a brief moment. I remember when I moved to London from where I was in Canada in 1999 - I worked on the Aldwych, just off the Strand, not too far from where the FT is based there. And that's right amongst the LSE buildings. I remember lots of protests about the impending increase in potential tuition costs. Because I believe - even in '99, it was still free to study at universities - most universities in the UK.

I remember I had a colleague who told me that he had a student debt of 5,000 pounds - which he represented, quite naturally, as a crime against justice. In Canada, we don't have the same problem with tuition that people have in the United States, but still, something like a 5,000 pound debt wouldn't be something that people would regard as onerous. So it was surprising to me.

But in the time since - and it has been 20 years - tuition has gone way up in the UK. It was probably under Cameron, I imagine - that it really went up? Have either of you noticed a drop-off in the number of applicants who've formally studied at university because of the increase in tuition? I mean, I'm asking you to kind of guess here - I know this is kind of an anecdotal question, so please take it in that spirit.

Victoria: I'll let Sarah answer, because I do less recruitment of technical engineers now.

Len: Okay.

Sarah: So, I don't think that we could say. Because we generally recruit people, either - the people get in that are less experienced, normally come in with partnerships with other organizations - as I said. So by the time that we're interviewing without that kind of partnership, we're looking at their job history. So I certainly don't worry too much when I'm looking at a CV about educational history. I'm looking for experience and a coherence - a story of what they've been working on, more.

Len: Okay, thanks very much for sharing that. That's really good to know.

So, you've both worked for a large newspaper during a time of profound transition in the industry. I'd like to ask each of you about one or two of the experiences you've had, or projects you've worked on in that time. Victoria - I believe you worked on a project that involved a shift to digital-first publishing, that involved working with the editorial team. I was wondering if you could talk a little bit about that experience, particularly from the perspective of changing the internal culture in a well-established company?

Victoria: Yes. Essentially, new technology doesn't come for free, wherever you introduce it. It always involves changing the way that you work, and also take advantage of it. And our editorial department is one that's full of incredibly smart people who are under pressure every day to get the news out. So asking them to take time out to take part in a design studio, or do some user experience testing, that's really tough. So, it means that any change, any new technology - it's going to take some time, and working carefully with them. So everything specifically about them, trying to get them to think digital - digital first. That meant thinking about the composition of their articles a lot more.

So, the first tool that we built for them was a chart-making tool, which would make it possible for non-specialists to make simple data charts that would go in their articles at the time they write them - rather than following a really complex and time-consuming workflow through other teams, which traditionally would mean that they would end up following later, after the article was done. This was quite a big change for them. It sounds great, but it meant those specialist teams - they needed to trust regular journalists to get their data right and present it accurately in the charts.

Print is very risk averse. Because once the newspaper has gone out to print, it's gone. There's no bringing that back. You can't fix something, you can't augment it or change it. And so there's perhaps some very traditional thinking required for that.

Whereas, if you're writing for the web, it's a bit like software - that you produce more quickly, it should feel more liberating. But it takes time for people's mindsets to adjust to that and to let go a little bit. And particularly where we are still having to produce content for the newspaper - so we still need that mix of mindsets. It just makes that change difficult for them. So they are changing, and they're moving forward. But it's a conscious thing that takes some time, and we need to help them.

Len: It's really interesting as well, just given the particular organization that you work for. I remember in my investment banking training - one of the very harsh lessons we got was - I was working for an Australian investment bank based in London. And it probably wasn't the FT, it might have been another news organization - but there was a big headline that leaked something that was not supposed to be understood. And it was because a guy was in a pub and he mentioned he was going to Copenhagen tomorrow. He just happened to be the head of the airports team in the M&A division. And there was a reporter sitting next to him who knew about that, and that's how that got out.

And so it's really interesting just thinking about the shift to digital-first thinking in a news organization. Where it can move things. The idea of being able to do things quickly, and retract them quickly - is complicated, is difficult, for exactly the reasons you describe. That with the print medium makes you naturally more conservative.

But at the same time - the ability to do switcheroos very quickly on this or that, would actually also require a very different - and also in it's own way, kind of conservative mindset I imagine, as well.

Sarah, I understand that you were, for a time, in the role of principle engineer on a project that involved, amongst other things, a shift to a devops culture at the FT? I was wondering if you could talk a little bit about that experience, and what devops is?

Sarah: So, I was working on the content platform team. And around about four or five years ago, we started building a new content platform - publishing and delivery of content. It was the first big microservice architecture that we'd done. And we were able to do that because the company had already started moving to a more devops mindset.

We'd basically done the first thing that a lot of people do with devops, which is to automate things like server provisioning to make it much quicker. Devops is really about not having that separation between people who write code, whose interest is in deploying it - and people who operate code, who interested in things not changing.

When I joined the FT it would take - on average, we plotted this - it's 120 days to set up a server, configure it, get everything installed and ready to put code on it. The work that had been done up to this point meant it was about 15 minutes. So that's a massive increment. And it meant we could build microservices.

Microservices are great, because you have very localised changes, you can release code very often. You're releasing changes in one place. So small changes, frequently released - much less likely to fail. But they're much more complicated to operate. And ultimately when you build a microservice architecture, you kind of have to run it yourself. The team that's delivering it needs to be heavily involved in all the decisions about how it's run. So that's really what dev ops is about - it's basically, you build it, you run it. You're doing everything. You're not just writing code and giving it to someone else to package in a ball.

Len: And what are microservices, and how does the use of microservices differ from past practices?

Sarah: So with a microservice - rather than having one big application, you have lots of services deployed separately, and they communicate - normally over something like http. So the calls going over the network, rather than between processors. And that means that there's more of a chance that that kind of communication will fail. But you have very clear boundaries. They're often API-based. So you might have a microservice. The idea is a microservice should have one area of responsibility. So you may have a microservice that is responsible for order data. And everything that needs access to orders, has to go in through the API and get it that way.

There's no sort of shared database. It means that everything's very encapsulated, and you are able to make changes and know that they're not going to have an impact. So generally speaking, when you're doing microservices, you can do, you can vastly increase the number of releases you do. We went from 12 releases a year, to probably 2,000, 3,000 releases a year for content publishing and delivery. And that means that you can basically try things out much more frequently, and you can experiment. Because you're able to release code, look at the impact it's had, release new code - and you know that it's first time correct.

Len: And just for those listening who might not know - when you talk about a release, you mean - people have made a change to something on the technical side of things, and then made it live.

Sarah: Yes.

Len: And so you're doing this multiple times a day, presumably across all the sort of - on the web, on the apps and things like that?

Sarah: Yes, yeah. So constant change. Constant small changes of code, configuration, things like that - all done in an automated fashion, so that you know that it goes through exactly the same steps every single time - and it's easy to reverse.

Len: I guess this next question would be for both of you. So, you're providing the tools for journalists to do the things that they do. I don't know how closely either of you would work with journalists themselves or editors. But I imagine there must be a little bit of a - is there a feeling on the side of the people sort of producing the content, that things are changing too rapidly sometimes? Or is everybody on board with it, and enjoying the high-speed process? You don't have to answer that if you don't want to.

Victoria: Oh no, I'm just thinking. From my point of view - and this is from a few years ago, because I don't really work directly with editors and journalists anymore. My current role is much more focused on developers. But there was a point where editors realized that all of the changes we made, meant that they could suggest something, and they had much more chance of it happening quickly. But there was a kind of flip side, which was - we might put a change out - and it might break something. But we'd fix it quickly. So I think there was more of an acceptance of some level of risk around moving relatively fast and quickly fixing stuff. Now, obviously there are some things we're much more careful about. But we're changing the layout on the website, we'll probably release it. And if someone says, "Well that doesn't look quite right," we'll go back to what it was like before.

Sarah: Yeah, I'm trying to think whether I'm hearing that there's any resistance to change. And when we're changing the tools that they use, that can be challenging. It comes back to - they're very busy, they are very under pressure - and anything different that we give them, means that there's something that they're used to doing that they can't do. They have to somehow learn this new thing, and they've got this deadline, this article they need to get out today. Or you'll book a meeting with them, but some other person that they need to speak to about a news item that's just appeared - interrupts their day. So change is just difficult. I don't think I hear an awful lot of resistance that change is happening too fast. It's just that we have to respect that.

Len: I confess I hadn't really quite thought about it that way before. But in such a competitive and high-paced environment - where you've got deadlines, and the news is moving - I can imagine having a technology underneath you that's allowing you to do things quickly is great. But having one that's changing a lot also means that it can actually slow things down - even though the change that's been made is meant to speed you up, it slows you down in the moment when you have to learn it.

Victoria: Absolutely.

Len: I imagine that's just a sort of inherent tension in the job now.

Moving on to the subject of your book, Victoria, Internal Tech Conferences. I believe both you and Sarah have played a role in organizing internal conferences and meetups at the FT. I was wondering if you could talk a little bit about how this culture developed there in your time?

Victoria: Yes. And Sarah was heavily involved actually in the creation of the first internal tech conference and the origin of it. I think, correct me Sarah - you were in those early conversations that triggered it?

Sarah: Yes. It actually came out of a bunch of us going to a conference in London. And realizing - the first thing was that we were listening to people who were talking about things that we'd already done. So over the space of three or four years, we'd gone from going to conferences and thinking, "That's amazing, wouldn't it be great if we could do it." To thinking, "Actually we're at the same level as the people that are talking." So that was an interesting realization. And actually, we also realized that we benefited so much from just talking to each other.

We were from different departments in the FT. We were talking in-between the talks, and realized that we had a lot to learn from each other. And, so a couple of us that had been in that conference, talked to our CTO and said, "We should do something so that we share how good we are at certain of these things. And also, so the different parts of the organization know what the other parts are doing." And then, and he said, "Yeah, that sounds like a great idea." And then phoned me up and said, "Oh I've booked a room for it in three weeks' time." And I said, "No, there is no way that that is going to happen. We need to actually plan it. We need to spend some time and get that going." At which point - pretty much immediately, Victoria came to hand, and Victoria was totally involved from basically week one of organizing this.

Len: And a lot of people need to be - it sounds like things got moving quickly. But often it can take some convincing in some organizations - at all levels, to get people to want to participate. So, an executive with a lot of pressure to deliver something, might be like, "Why should I have all my team take a day off to talk to each other?" And then people on the team themselves might be like, "I want to get this done, why should I take a day off to talk to other people in my own company?" But of course there are obviously very strong benefits to doing this kind of thing. I was wondering if you could about - maybe, imagine to a skeptic, about what the benefits are of taking the time out and devoting the resources to putting on an internal tech conference, at a big organization?

Victoria: Sure. One of the main - there's the explicit goal and the implicit goal, I suppose? The explicit one is, it's about learning. Sending people out to courses and conferences - it's not just expensive, but it doesn't scale. And it's also very passive learning. So a bit like what we were saying about universities, but not quite the same. These courses which tend to often be quite specific in what they're teaching - are not necessarily massively contextual to those people for what they're doing right here, right now.

Whereas inside their organization, people are learning all the time. There are pockets of expertise arising all over the place. But in our agile world, where everyone's in these teams that are all self-sustaining - sometimes that knowledge is quite in those pockets. And so - an organization like this at a conference, taking people out of that - it gives people the opportunity to discover those bright sparks that surround them in those other teams, and they connect with that in the context of their own workplace. So it makes it much more experiential and more sticky. And also just simply scaled in a way that would cost a fortune if you were sending people out somewhere else.

The implicit goals that you might see - the implicit benefits are really the connections that people build at these things. So, again - related to a change. Technology's changing all the time. Business is changing all the time. And all that constant change means that there are lots of opportunities for people to collide, and disagree with each other - potentially, as differences emerge. So enabling your employees to connect at a time which is completely independent of that - a friendlier environment that's not challenging - it's going to significantly boost their chances of working well when a problem brings them together. So those connections are crucial. And they often don't happen by accident. So, creating those moments in a learning context can be massively powerful.

Len: My next question is about your book as well. In addition to the sort of high business and technology theory, reasons for doing internal tech conferences - your book is full of practical advice as well. I was wondering if you could talk to people who are considering running these complex events - what are some of the things that come to mind that can typically go wrong, let's say the first time you're trying to pull one of these internal tech conferences off?

Victoria: Wel,l I guess the first thing to be really on top of is the tech. It's hugely important. People have a habit of not having the right adaptors for their laptops, or having their slides in the wrong format, in terms of the aspect ratio or something like that. So just having a good selection of adaptors, communicating early what those constraints are - and ideally testing their presentations. So getting ahead of those needs.

Related to that, I suppose, is the tendency for remote connections to fail. Usually there's a good chance that you may have some remote attendees that you're trying to cater for. So we look after them by making sure that speakers actually talk into the microphone, having someone on the ground that they can connect to. And make sure that sessions are recorded, so that if live streaming fails, they have the content available later if something does go wrong there.

And then of course, the success of the day, it relies on the speakers themselves. So a talk going wrong is clearly something you want to try and avoid. If people need coaching, make it available to them. We've got a speakers guild here who do a lot of really great work. That's a really good support network to have.

And have a back up on the day. For in case one of your speakers does drop out. So anticipating things like that. There are lots of other things in the book that clearly go into this in more detail.

Len: That's really interesting about the backup. So is this someone - I'm really curious about the detail. Is this one person who is around all day in case someone doesn't show, or is it a person per session?

Victoria: It would probably be a person for the whole day. I think if you were to try and double up all of the sessions, that would get quite arduous - and a lot of people preparing sessions that they ultimately wouldn't deliver. So it's just having one or two emergency speakers who are ready to step in if something goes wrong, is probably a good idea.

Len: It's interesting you mentioned the distinction maybe between active and passive kinds of learning. And one of the, it seems to me - one of the great benefits of having an internal tech conference, is that every one of the speakers is someone from your organization. And they've had to put together a talk, and think - I mean, often people say the best way to learn is to have to teach something. And I imagine this is an experience that people sometimes might be a little bit trepidatious to enter. But once they do, they probably feel quite empowered by it.

Sarah: Oh definitely, it's one of the advantages. If they can be brave and realize that. There's often something that - it maybe interests us, but we haven't quite found the time to look into it a bit more. If you are going to stand up and talk about something, you do want to make sure you know what you're talking about. So it can be encouraging, and as part of an internal thing - then they could be given the support by the management, "We would like people to get up and talk about a thing." So if that requires them to spend a bit of time learning a bit more about it, then we can support them in that and explicitly give them a bit of time. It's an exciting learning opportunity for them on something that's outside perhaps of what they're doing every day. And then there's the learning they get from having given a talk in public as well. That's a really good growth and learning opportunity for them too.

Len: And what kind of space should one use for an event like this? Let's say if you're going to have - I mean I actually don't know what the size of the events you've both put on would be. But if there were say 100 attendees, what kind of space should you try and find?

Victoria: I guess it depends on how you're structuring the day. Because you might be structuring the day where you've just got a series of big talks that you expect most people to try and go to. Or you might be structuring the day where you've got streams, and you might have several smaller talks scattered across different rooms. So it depends on how you structure it really, and whether your focus is more a single track, or whether you have the option and more - more content, and more rooms and spaces available to you.

Previously we've had one big conference room, and so we've had a single stream of talks and panel discussions that are being given from the front of the room, with people consuming and asking questions from the floor. This year in our new building, we've actually got a greater variety of spaces available to us. So we're looking forward to this year, and getting quite excited about the idea of having parallel streams of smaller workshops and open space discussions, going alongside what might be a main thread of main topics. So we've got more flexibility this year.

Sarah: Can I just say something on this?

Victoria: Yeah.

Sarah: I think that it depends on what you've got. I think you can set up an internal conference with whatever size of space that you have, and you'll change what you're doing to fit that. What I think is important, probably the first time you do it - is not to try and bite off too much. So this year, we are excited and thinking, "Oh we'll run multiple streams." But we were a bit more cautious the first year - to say, "What do we think we can manage?" I think now, we're just - we feel like we understand how to do it, so we can expand it and do more. So I think it's, work with what you've got, don't try and do too much to start with if it's going to be overwhelming. And then develop from there.

Len: One of the really interesting details about running a successful - I mean, I guess probably any kind of conference, this has actually come up before on this podcast - but I believe that one should not underestimate the importance of providing quality food.

Sarah: True, yes. After our first event, the biggest negative feedback we got was about the food. We just served pizza, and not enough of it. And at the time we thought, "Oh that's great, everything else must have been awesome if that's all they had to complain about." But truthfully, I think that they probably spent a fair amount of energy mumbling and grumbling about it and maybe going to get snacks - rather than enjoying it and focusing on the event. And so later, at other events where we provided better food, you see people actually relaxing, enjoying the food - and actually getting much more out of those opportunities for those conversations and connections, because they're relaxed and enjoying and being positive - and it actually makes a big difference, yes.

Len: And I imagine, feeling respected as well?

Sarah: Yes.

Len: Is a big part of it.

Sarah: Absolutely.

Victoria: It's also true of external conferences. You have to do good food, otherwise people will comment about it.

Len: I imagine people will comment about something anyway. But that actually leads me to my next question, which is, that I believe following up, is actually a very important principle that you have with respect to these conferences - that it's important to follow up with both the volunteers and the people who've attended. How do you go about doing that, and what are you looking for in the follow-up process?

Victoria: Well, there's different kinds of follow-up. Getting feedback, that can be just via a form or just by having some conversations with people.

But doing some legwork and having the conversations is really key. You want to find out from attendees how the event went for them, and how you could make it better. But also from the speakers - how was it for them, and how could you better support them in the future - with other speakers?

Another really good question to ask is - the other kind of follow-up, is to follow-up on the benefits and outcomes that you were seeking to get from it. So another really good question to ask people is just - what do they intend to do differently as a result? As people who have been involved in running it, are invested in it, or as senior management - being ready to notice and follow-up on, and gently nudge any spin-off activities that we might see a hint of that might be occurring - just to encourage those things to happen. And I think Sarah, you've done that before - haven't you? With events that we've had.

Sarah: Yeah. It's basically thinking, "Oh yes, I noticed someone talking about this - I'm going to follow-up and try to make sure it actually happens."

Len: And is this, just to get into the weeds of it - is this emailing people, is this walking up to people and tapping them on the shoulder? Is it web forms or something like that? Or all of the above?

Sarah: Everything.

Victoria: I think you can get - there's a lot of value in the structured feedback, of sending a form. Because it gives you information in a structured way. So you can say, "Oh well, these are the most popular sessions." But you also want to just talk to people as you're going around your day job and sort of saying, "Well how was it?" And because you will get people saying stuff that they may not have bothered filling in a form for - you know people fill in forms when they're really happy or not happy. Or if they have a strong sense of public-spiritedness, but the rest you're missing - unless you go and talk to people.

Len: And in your experience with this, is there someone that you need to report to afterwards? To say, "It was a great success, and here's my proof?" Or is the sort of culture sort of fluid and trusting enough, would you say? There's just sort of social proof that everything was worthwhile?

Sarah: I think the people that we need to have think whether this was good are actually there. So they're making their own judgement. So our CTO, our CIO - they're there at the conference. So they're going to see how it goes themselves. And I think that's actually really important, to have that, because if your CTO and your CIO are there and they're telling people about it, it's much easier for people to take time out of their normal day job and come to the conference. I don't know, Victoria, do you think we had to do any sort of separate feedback?

Victoria: No, I don't think we did. I think it's important to catch up with them afterwards. Because if you're - before running it, being clear with them about what it is that they're hoping they will achieve out of it - because then your conversation with them afterwards can reflect on that. "So you were hoping to get to see this, did you see this?" And also those follow-up activities we were talking about, nudging. You can help them spot some of those things that might need nudging. And maybe they can nudge them too.

And if you see some of these things that are changing, these light bulb moments, or whether maybe you've seen something, and a project's done differently because someone's learnt from the event. If you see those happening and encourage those happening - then they act as really good ammunition and motivators for running the next event. And it's just useful evidence to build as well.

Len: Well, thank you very much to both of you for sharing all these details about your own careers and about internal tech conferences, and the work that you've done.

The last question I have, is the last question I usually ask on this podcast. And I guess in this case, it's specifically for Victoria, because she's published a book on Leanpub. The question is, if there was one feature we could build for you, or one bug we could fix for you - what would you ask us to do?

Victoria: That one's quite easy. I would love more data. I'd like more data about conversion rates. So I put a free sample of my book on Leanpub, and I don't know whether I'm putting too much on there or too little, if I'm putting the right content - I can't experiment. So if I could have data that shows how many people read that, and then actually buy it - versus read it and then just go, "Well, that's all I needed, thank you." I can't play around. I would love to have that conversion data, so that I could experiment.

Len: Okay, well thanks very much for that very direct and clear request. Those are the best kind.

Yeah, we've had some requests for more data before. It takes various forms. But definitely getting feedback on the success or failure of the efforts that you put into driving sales or attention, is something that can be really motivating. And so that's definitely something that we intend to improve in the future. Conversions from reading the sample to buying the book are something that we could definitely do quite a bit more work on. I mean, like you could imagine like a link in the back of the sample to go buy the book now, is something that we could maybe track.

Well, thank you very much to both of you for taking the time. It's the morning here, but it's the evening where you are. So thanks very much for taking the time out of your evenings to be on the podcast. And thank you Victoria for choosing Leanpub as a platform for your book.

Victoria: Thank you for publishing.

Sarah: Thank you.

Len: Thanks.

And 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 yourself, please visit our website at leanpub.com. Thanks.