[Intro Music]
Clare: Hello and welcome to Making Tech Better, Made Tech’s fortnightly podcast bringing you content from all over the world, on how to improve your software delivery. For us, that means empowering your teams to collaborate compassionately on creating high-quality software that delivers value quickly, to the people that really matter, the users.
My name is Clare Sudbery, and my pronouns are, ‘she’ and ‘her’. I’ve been a software engineer for 21 years. I do a lot of speaking and writing on the topic of software delivery and I’m a Lead Engineer with Made Tech.
Change is unavoidable in our industry, but balancing change can be surprisingly difficult. Writer and independent consultant Kevlin Henney is someone I often bump into at conferences. Whenever I do, we always have the best conversations. He is full of interesting insights, so he was a great person to talk to on this topic.
Clare: Hello Kevlin!
Kevlin: Good morning Clare.
Clare: It’s so great to see you again.
Kevlin: Likewise.
Clare: One of the first things I wanted to ask you about was when I was looking at your bio, I noticed it didn’t mention anything about blue screens of death. I have become aware that you are somehow associated with blue screens of death. I got it into my head that people call them a Kevlin Henney, but I couldn’t find any Googled evidence of that. What the hell is that all about?
Kevlin: Okay, what’s all that about? I’m going to write a blog post about it. It needs an origin story because I do get asked that. This goes back to the days when phones acquired cameras. I started taking photographs of failure screens in public places. I would sometimes show these at conferences as part of my talk or I’d put it in the break, and I’d do it in workshops as well. Then people started sending these to me.
Then around 2016, a couple of people started saying things, ‘I saw a Kevlin Henney screen’. That’s a Kevlin Henney. It has since appeared in The Register in one of the Verity Stodd columns. It has also been added to Urban Dictionary. I don’t know who did that, but that’s the only way I can gain any kind of credibility with my kids now. Hey, I’m an entry on Urban Dictionary.
It’s useful and interesting in many ways. One, it’s kind of fun, two, it allows me to make jokes about the fact that software developers are the largest creators of accidental installation art on the planet. Sometimes if it’s at train stations and things like that, people will say hey, train provider in whatever country, you’ve got a Kevlin Henney at this platform. There’s a public service there as well. I also use these as introductions, not only on how to talk about motivation for testing from the point of view of correctness, as opposed to the other aspects of testing, but also reflect on the idea that software loses its encapsulation when it fails.
Up until that moment it was beautifully – software is the art of creating illusions. We create an illusion, we turn these little pixels into buttons, we turn them into worlds. It’s all beautiful and then it cracks, it falls apart, it gets dropped on the floor. It’s like anything that breaks, the fracture lines tell you something about how it was constructed.
It doesn’t necessarily give us answers there, but it lets us ask questions about how was this created, what was the culture and context in which it was created? There’s more to it than just a funny error screen, that’s a starting point but it’s definitely not the end point.
Clare: Yes. I love that idea of breaking the fourth wall, as well. This idea that your devices are emulating functionality. They become an email sending device or they become a game, or they become whatever you are currently using them for. When the error appears, that illusion is broken. I’m trying to think, what is the phrased that’s used in theatre and film? Not breaking the fourth wall…
Kevlin: Suspension of disbelief, is that what we’re after?
Clare: Suspension of disbelief, that’s the thing I’m thinking of. Actually, you’re in the same dance with your devices, aren’t you?
Kevlin: Exactly, yes.
Clare: It’s almost as though you forget this is the same physical object as it was a minute ago but because I’m using it to do something entirely different, it takes on a different character in my mind.
Kevlin: Yes, it’s like a UFO landing in the middle of a Victorian drama. It’s like, hang on, that doesn’t belong there.
Clare: Yes, okay. So, we were going to talk about balancing change.
Kevlin: Oh yes!
Clare: So, let’s have a go at doing that. Tell me what balancing change means to you. I know it’s something you’re really interested in at the moment. What does that phrase mean?
Kevlin: Well, first of all I’m going to start with really interested. I have idle curiosities in a number of things. I do not pretend to be a scholar in anything really, but I’m interested in this constant tug of war that companies, teams, and individuals are always in with change.
I came across this lovely observation a couple of years ago. It was probably the wisdom of Twitter, but it may have come from another source. It was this idea that there are two things that humans really hate. One: things remaining the same, two: change. That kind of captures everything about this issue of change. We recognise that change is at one level, normal, and we also recognise that it is desirable. On the other hand, we also like predictability, comfort, confidence, and certainty. This plays out on an individual level, but it also plays out at a company level.
We sometimes end up – this idea of balancing change – we either end up with long periods of stasis and complacency and then by the time we need to change, it’s too late. So now, suddenly you are forcing people into something that is radical. Guess what? That doesn’t always work out. In fact, it very rarely works out because it turns out that people are involved. Some people will be right behind the idea of change, some people will be against the idea of change. Those who are for change might have different ideas about what needs to be changed. Also, those who prefer stasis might have different ideas about what should remain the same.
I did some work for a company years ago, I visited them about twice a year for about 15 years. I visited all of their teams. What was fascinating was that by the time we finished, the department was dissolved, organisational change, all of this kind of stuff, many of the people were still there. They had incredibly good staff retention and most people were in the same teams as when I had first met them.
Clare: Wow, okay.
Kevlin: That also introduced me to the idea and the awareness that actually, although we often talk about team stability as being important, these guys were too stable. In other words, there was very little knowledge sharing. One particular team, one of the best long-term reuse strategies I’ve ever come across, best technical competence, use of unit testing, how they used meetings and all of the rest of it. These guys, absolutely brilliant. They were right next door, partition-wise, to another team that had really struggled. Yet all the knowledge that was needed by the second team was with the first team. But there was no movement.
Clare: This fascinates me because this is something that I was actually talking about yesterday, about my own life and about lockdown, and about how I’m struggling with the balance between stability and flux. And how I want both. I’m bored that everything is the same, I want change, I want to do different things, I want excitement. But I also want predictability. I’m not sure what’s going to happen, I feel uncertain about the future and I don’t like that.
Kevlin: Exactly!
Clare: I want to know what’s going to happen. What you were just talking about in terms of teams is something that I see a lot in larger organisations. I’m a big fan of the concept of the self-organising team. I think people need autonomy and control over what they are doing, and they need to feel some ownership in order for them to take responsibility and be motivated to keep working on things. So therefore, it’s very good to have autonomous units that have some control over what they’re doing.
But then you often end up with the problem that they become silos, they become separate from one another and what they don’t do, is collaborate with each other between teams and share what they know. So, it’s really interesting to hear about that, in the context of change.
Then of course we have this issue that all this learning has stayed contained in this one team. The change, I guess, has stayed contained, so one bit has changed, and another bit hasn’t. So how do we spread the change?
Kevlin: Yes, I think that’s really interesting because there’s no magic bullets for this one, silver or otherwise. Because one of the things I said to the Lead of Development, we went out for a drink and I said there’s only one person who has seen the source code of all of your projects, and that’s me. I’m an external. You don’t want that. The problem is that they had become so attached to the team idea, this very siloed idea, that it was quite difficult to break that. I tried to encourage them – and I think they were beginning to do that before, unfortunately, the whole department was closed down – was trying to move people around for at least code reviews. Have somebody from another team join your code reviews.
In other words, pick on something people are already doing. One of the things they were doing was code reviews. If you’re going to try and do any kind of change – and this is one of those ones you can pick up in a self-help book – piggy-back on something else that you do. Unfortunately, they’ve ended up with a stagnant pool problem. Sometimes you’d have a team where there was not sufficient expertise and you have a group of people who don’t know what they’re talking about sharing their ignorance, sadly. They don’t have somebody there to throw something into the pond and get a ripple going across, going ah, that’s a really different way of looking at it. To bring new knowledge or new questions in. So, having somebody from another team come and ask stupid questions – half the time that’s what I’m doing – I’m strategically using my ignorance. The fact that I don’t know your code and don’t know your company and don’t know your projects and the intention of your products, is actually, potentially my biggest advantage.
That can be somebody from a different team. They have the advantage of at least knowing the company. We have a better system, here, borrow this. Little opportunities like that. In this particular case, that’s what I would recommend, is that meeting of people, getting people together just to talk about random stuff sometimes, even.
Clare: Yes. I’ve seen that work really effectively in a few places, to give people that opportunity and make it be a normal thing for people to move between teams. Not necessarily permanently. It gives people a bit of a boost, it’s a bit of a change. Particularly if people feel a bit stale, they feel like their career is not going anywhere. For them to experience other technologies, other bits of the domain, other whole domains. Exactly as you say, it means they get to ask simple questions, they stir the pot up a bit. They force people to think and explain in a way that they might not otherwise have had to. They also bring their own fresh perspective and experience and skills and get to appreciate their own skills as well, that sometimes they don’t even realise they have. You know, this is something that I can use to provide value elsewhere. It does, it stirs everything up.
Kevlin: Yes. I think that’s really important. That shift in perspective, the necessary shift in perspective. It doesn’t have to be permanent, as you say. I’ve seen that work with companies, where oh, we’ve borrowed this person into this team for a while and so on. And that’s been really good.
When change is forced upon people, there is also a real pushback. This was the early 2000s: It was one of the first pieces of Agile training that I was asked to do. I’d just been doing some technical coaching at a company. Honestly, I don’t even know if we called it Agile, because I don’t even know if the Agile Manifesto existed at that point. But we were basically saying right, we’re using XP ideas and we’re blending them…
Clare: For the benefit of our listeners, XP is Extreme Programming.
Kevlin: Not to be confused with Windows XP.
Clare: Yes, exactly. It’s the technical offshoot of Agile. It’s the idea that you would have continuous integration, test-driven development, pair programming and that you would put your people first. I think that’s a reasonable quick summary.
Kevlin: That’s a fair summary, yes. Although I would say timewise, it pre-dates. It’s not an offshoot, really, agile was an offshoot of XP.
Clare: Oh, that’s interesting.
Kevlin: Kent Beck once said he regarded the early days of the Agile movement as a marketing campaign for extreme programming. I came across XP in the late 90s, and the Agile Manifesto was created 20 years ago, this month, actually. Back then, in the early days of Agile, when people were talking agile, they were pretty much talking extreme programming or some derivative or relationship of it, by default. Particularly if they were developers, that’s where they would be coming in from.
So, I ended up doing this workshop via an intermediary who didn’t know what to do with it because they’d never heard of this stuff. They were a traditional training shop, and it was like, we’ve been given this request and we don’t know what to do with it. I thought, wow, this is great, this company has been really innovative and forward looking, that’s great.
I was really fired up to do this workshop. I arrived and there was such indifference in the room. This was not their idea. I could sense the culture. If they had been told the sky was blue, they’d say, no it isn’t. They were at odds with the powers that be, basically. There was a real antagonism there.
Change has to be owned. Whether one person regards it as necessary or not, it really does have to be owned. Because no matter how good it is, it will be rejected antibody style, if that antagonism or indifference exists within an organisation. There is change that they need, but it’s not the change they think they need.
Clare: It’s a cliché, as well, isn’t it, that if somebody is going to change, they have to want to change. People talk about it in the context of addiction and lots of other contexts. You can’t force somebody to change, they have to want to change.
Kevlin: Yes, humans are funny creatures. There’s that idea that where there is conscious change, we have to want it, but sub-conscious change, we don’t actually have to want it. This is the space of nudge psychology and all the rest of it. This takes time.
Clare: Let’s talk about an example. So, if we go back to an example of the company where you had two teams next to each other, one had really good practices, the other one didn’t.
Kevlin: Okay, so the team with really good practices, when I first visited them, it was just for code review originally, and design help. One of the first things I noticed was their code was quite verbose. So, I gave them a few hints and tips and concrete pieces of advice. They ended up having some of the best unit test coverage, the best review techniques. This was a process that took years. It wasn’t necessarily to do with the brilliance of the individuals. They were very good at working together as a team, they were very good at becoming brilliant. There was no flick of a switch. They had moments of insight, but also there were lessons along the way.
I remember having this wonderful session with one guy there. He said, let’s look at what the compilers are producing. He just told me all kinds of stuff I didn’t know and that was so cool. From my point of view, I learned a bunch of stuff. That’s the point, that change was not consistent, it was not perfect. They did not arrive fully formed, dropping out of the pages of a book. They were filled with accident and opportunity and they owned it.
I remember the first time I ever changed role, way back when I was technically young. I changed from one job to another. I remember having this really weird experience in the first couple of months in my new role, of having this wave of knowledge rush over me. A lovely feeling. It turns out it was just a reappraisal of everything that I had previously been doing. It was like, oh, that means… I just saw everything I had previously done in a completely new light because of the new perspective.
Clare: Yes. I had a similar experience when I was contracting for a while. I was doing short-term contracts and at first it was terrifying, and then it was incredibly stimulating. Every time I joined a new company and a new code base with not exactly the same technology – there would always be at least one technology in there that I hadn’t worked with before. That was scary because I was being paid a lot of money to supposedly be an expert. But then it was incredibly stimulating because what I realised was that I could use all of the knowledge and experience that I had gained, to learn new things more quickly and more effectively.
Kevlin: Yes.
[Music sting]
Clare: While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry, I am pretty choosy about who I’ll work for, but there’s lots to love about Made Tech. We’re software delivery experts with high technical standards. We work exclusively with the public sector. We have an open-source employee handbook on GitHub, which I love. We have unlimited annual leave. What I love most about Made Tech is the people. There is a real passion to make a difference and they really care for each other.
Our Twitter handle is Made Tech, M-A-D-E-T-E-C-H. If you go to madetech.com/resources/books, you’ll find that we have a couple of free books available; Modernising Legacy Applications in the Public Sector and Building High Performance Agile Teams. We are currently recruiting in London, Bristol, South Wales, and the North of England via our Manchester Office. You can find out more about that if you go to madetech.com/careers.
If you join our mailing list, you’ll get extra podcast content as well as finding out more about Made Tech. You’ll find a link in the description.
[Music sting]
Clare: Before we return to the interview, here’s a quick recap of what we were talking about before the break, which was personal change in the context of changing jobs, and how that can refresh your perspective and highlight how much you’ve learned.
Clare: When you’re thinking about balancing change, do you have any overriding principles that you think about, about how you do that? What is a healthy way of approaching change so that you can anticipate it and make it be effective?
Kevlin: There are no easy answers here. Part of the balance is the idea that sometimes what you want is one thing to be stable and the other thing to change. It’s like music, there’s this idea that give me the steady bassline and the beat and I will jam over it. But if you start messing about with the beat and the bassline, we’re not on the same page and it all goes to hell.
Clare: Yes.
Kevlin: You need to have, right, what’s my bassline here? You are trying to introduce change, but still there is stability. That’s got to be firm, your handhold, your foothold. Whatever it is, there has to be something there. So first of all, are you aware that there is a conflict, that you want both? That you want change, and you want stability? What is the bit you are going to keep stable whilst you’re changing everything else? What is the fixed point that you are working around? That was one of the things back in the XP era. There was a lot of talk because of the name, extreme. It comes with the territory. People say right, we’re going to be really radical and do everything. There’s the extreme sports metaphor, jumping out of aeroplanes and parachutes and snowboarding down a mountain whilst getting a compile to work.
Actually, this idea of how we introduce XP into a team, maybe that’s the wrong question. What is the effect you’re going to get? How do we introduce pair programming, particularly if there’s resistance there? Well, okay, let’s pick out first of all why do you want to do pair programming? What about review? How do you do review? Well, somebody does this, we make a pull request then they email… there’s no people there. You’ve optimised it to the point that it’s non-optimal. Asynchronous review, I really, honestly don’t think it’s a great idea.
Clare: I agree.
Kevlin: It’s not that people can’t make it work, it’s just that you’ve got an opportunity here to have a conversation, and you’ve just turned that down flatly. It’s not efficient on your time, that’s an illusion. People have a very poor perception of their time. Get somebody there on a call, in the room, whatever it takes, and talk through the code. Yes, but that’s slow. Of course, it’s slow, that’s the point. It’s to stop you rushing around, failing to see things.
What we are actually talking about is pairing, but we’ve given it a little more richness and purpose. We’re talking about knowledge exchange, we’re talking about social interaction, all of these kinds of things. All of these are very modest, rather than extreme. So, if there is an overriding principle, it is understanding the people. Also understand that where you want it to start changing may not be the right place. It’s also understanding that when you are asking about change, you need to also be asking, what is the thing that we don’t think should change?
We talk about disruption a lot, which misappropriates what the disruption metaphor was originally intended for. These days, disruption basically means going in, making a mess, and not really understanding the consequences of what you’re doing. And doing it all in the name of a start-up. Exceptionalism, particularly start-up exceptionalism: We’re different. Well, no you’re not! You’re a group of people. We have a recorded history of how people do and don’t work effectively. So, there are some things that don’t change. You’ve got a group of people here and they are trying to do technology. There is nothing new in that at all. This story is very old. Understand. Are you aware of this conflict that you have? I don’t think most people are. They pay lip service to it but really, they don’t genuinely understand that people simultaneously want change and not change. That is the core of this.
Clare: Yes. We were talking earlier about breaking the fourth wall and suspension of disbelief. I know that you and I both really care about storytelling. In fact, that’s how we met.
Kevlin: Yes, it is.
Clare: We met at a conference, in a bar, where we were drinking whiskey. We got talking to each other about the fact that we both write fiction. I think storytelling can have a much bigger influence, and already plays a much bigger role in the world of work – I’m not even just going to say IT – than people realise. What we have been doing today as we have been talking, is we’ve been telling stories. You’ve been telling me about examples of the principles that you’re talking about, and therefore they become more meaningful.
You’ve been telling me about people and their emotions. I’m just interested in how much you consciously use storytelling as part of your job.
Kevlin: That’s really interesting. I don’t think I necessarily use it as consciously as it might appear, except when people reflect it back to me as you’ve just done. I think that’s got woven into the fabric of how I think and how I talk about things. There’s the idea that a story is about a situation. We start here, there’s conflict, there’s whatever, and then there is resolution at the end, there’s some kind of insight that perhaps we are leaving somebody with. But we’ve gone through a journey and we’ve seen things. That’s very much how I tend to organise my talks these days. Sometimes people are tempted to do a very hierarchical approach, the classic bullet point approach. Top-down structuring is intrinsic to a lot of software ideas. If I do the big upfront design methodology and I draw all the boxes, I can come up with a really good design. But how do I get to that? What does time do here? What is the effect of time?
If I end up saying I’ve got ten components, do I build one component at a time? It turns out that’s not as smart as we think it is. The Lego brick model doesn’t really work. Perhaps I should be building five of them, but half of each of the five. That’s a little more useful, it’s a bit more like a champagne fountain, if you like. It’s filling things out simultaneously, so it’s more like sketching the shadow into the drawing. Rather than saying I’m just going to draw the hand over here, and then I’ll draw the arm. Instead, I’ve got a rough sketch, now I’m going to do some of the shading, so I’ll get a sense of where the light falls. Perhaps I need adjustment to what I’ve got.
I’ll show you the finished picture, but that doesn’t show you how I drew it. How time flows and things change is the essence of what a story is. That has reinforced this idea of trying to take somebody somewhere, so they know that they got there, they know what they saw, they know where they started. The story has a beginning, middle and end.
When I talk about testing, I talk about that. What’s the story your test or your set of tests is trying to say? Which test do you want somebody to read first? You are telling a story about the problem domain. If it’s code-centric or if it is a business-centric idea, what is the first thing you want to tell me?
As an author, you get to be a timelord. You get to manipulate time for other people, and say well, this is not the first thought I had, but I think this will help you to get into this. Whether it’s technical or business, let’s put them in an order. The minute you start doing that, you are basically telling a story. I think that answers a personal question for me. The thing I struggled with most is how do we do this in time? I see where I want to go, but I don’t understand the steps in between. It turns out that process is, guess what? One of change.
Clare: Back on change again, actually, you just mentioned Agile. It occurred to me that for me, that is kind of what Agile is for. That’s what the word agility is about. It’s about managing change. The way that our sprints are structured, the ceremonies that we have, they are all about encouraging people to think about change, encouraging people to acknowledge, accept and even celebrate the fact that things are going to change, and things should change. The idea that you try not to use the waterfall approach, because the waterfall approach starts with a design and assumes that in two years’ time, nothing will have changed. Whereas the agile approach assumes that everything will change, and it is trying to give you ways of anticipating and acknowledging and coping with change, actually building it into your processes. I don’t know, I think sometimes people maybe forget that.
Kevlin: Yes.
Clare: They think that it is giving them a set of rules that won’t change.
Kevlin: That’s certainly one thing that I’ve encountered. I remember turning up to one company and a person there said, ‘I’m from the project management group. Basically, we want to find out what you’re going to say and then we’re going to document it, write it and standardise on that.’ You haven’t even tried it! How can you standardise on a thing… what I’m telling you is not for that; I’m giving you the starting point.
Sometimes people talk about scrum rituals. Honestly, go and look at extreme programming. Honestly, that was all rituals. Those rituals all served a purpose. If you didn’t understand the purpose, you were just enacting rituals and you probably didn’t really, truly, understand them.
When my younger son was very tiny, at one point he was at the classic kid stage of food redistribution. We call it mealtime but actually, some of the food gets in the mouth, some of it gets on the face, some of it gets on the floor and the table.
Clare: One of my least favourite things about small children, but anyway, carry on.
Kevlin: Yes. So, his older brother was four and would do the trying to help his parents thing. I remember noting one day that the older boy was watching my wife clear the table. So he thought he would do it the same way. My wife was sweeping the crumbs and things from the table. He could see that. He could see the top view because he’s short. The right hand is sweeping the crumbs. What he completely missed is that the left hand was just beneath the lip of the table and she was sweeping the crumbs into her hand. What he ended up doing was just sweeping all the crumbs straight onto the floor, because he could only see the right-hand movement. For me, that’s a lot of people trying to do agile, as opposed to be agile. What they’ve done is they’ve gone, here’s a certification scheme, here’s the simple rules of scrum or of safe or something, but the right-hand stuff, they’ve totally missed. There’s no point to it until you put the left hand in place. Otherwise, you are just going through a bunch of rituals.
The whole point is that those rituals are designed – you are allowed to change them. That’s the first thing that people don’t realise, that you’re supposed to. It’s something more sophisticated. It’s a simple practise, but that’s not where it ends, that is where it starts. The whole point is that there is more to it than perhaps you first noticed. That’s the left hand. With some people, you look at them and you think, there’s a lot of right-hand movement there, there’s a lot of yep, we’ve got sprints, we’ve got micro-management, we’ve got… No, no, this is not really what it’s for. A lot of these structures are there to be your baseline. That’s what they are there for. Then you are supposed to jam around it. It’s okay not to have complete knowledge because that is the normal human condition.
Most of our pain comes from the illusion of having complete knowledge. When we get up in the morning, we work with incomplete knowledge. It turns out we are surprisingly good at it. What we’re not good at is when we fool ourselves into thinking we have complete knowledge. Once you are at one with that, once you are settled with that, now you understand why it is that sometimes a little bit of ritual rhythm, if you like, or structure. It’s just enough structure to get you started, but that’s the starting point. That’s not where you’re supposed to end. Otherwise, you end up with a very dull story.
Clare: Exactly. The whole left hand, right hand, sweeping the food was yet another example of a story that really helps to illustrate…
Kevlin: Yes, I suppose it was, yes.
Clare: Very visual as well, I think that really helped. You’ve got the imagery and you can keep referring to the left hand and the right hand. Lovely. There are a few questions that I ask everybody. The first one is, who in this industry are you inspired by?
Kevlin: That’s an interesting question because for all my talk of awareness, it’s not something I’m necessarily aware of. Let me start with the long termers. In terms of people that I have met, as opposed to people that I haven’t met – there are certainly inspirational figures there – but in terms of people that I’ve met, a friend recently passed away, Russel Winder, who sadly passed away a couple of weeks ago. I always found him quite inspiring because he hung out in so many different communities. He was originally an academic, he had a deep thirst for knowledge. He would hang out in the groovy community, the C++ community, the D community, the Java community. He would argue about which was the best Linux distro, so whichever community he was in at the time. He also had a great thirst for knowledge and made everybody feel welcome. He was involved in the organisation of a number of conferences. He was always impassioned to help people and that was very present in the way that he worked. But he was also passionate against any injustice that he perceived in the world. From that point of view, yes, what would Russel do was kind of a mental model there.
Somebody else I found hugely inspirational with very similar ideas but very different, Linda Rising, who I’ve known since the late 1990s. I originally met her though the patents community and the object community. What I’ve always liked and been inspired by is that you can always have a conversation with Linda. She has an immense knowledge and experience that she brings to everything. She has a genuine scientific curiosity, and a genuine sense that she is trying to help people with this knowledge. She is a knowledge sharer; she wants it all to work out.
Clare: She is so highly regarded. I met her in San Diego at an Agile conference a couple of years ago. There was a whole session that was just Q & A with Linda because everybody wants to know what Linda thinks. It was fascinating, it was amazing. An audience with Linda.
Kevlin: Linda is one of the people I’ve always looked to, to say it’s okay to be a compassionate person in this industry, and that’s a good idea, as well. That it’s okay to know stuff, as well. Again, with Russell Winder, he made knowing stuff kind of cool. It’ s okay, we work in a knowledge-based industry. We can’t know everything, but the desire to know and pursue that and to defer to people who know more, or to ask people, that’s okay. That’s entirely fine.
Clare: Okay. This is one where I’m going to ask you to tell me one thing about you that’s true and one thing about you that’s untrue. The answer to which is the true one will be shared with subscribers. Go for it.
Kevlin: I share a birthday with Sigourney Weaver.
Clare: Fantastic.
Kevlin: I met Neil Gaiman at Heathrow Airport.
Clare: At Heathrow Airport, okay. There’s not a lot I can ask you about the shared birthdate, so tell me about meeting Neil Gaiman at Heathrow Airport.
Kevlin: This was a long time ago in a galaxy far, far away. I feel I’m mixing the genres here. That was one of those things. I was sitting there with my laptop open, answering email. I see this guy and he looks like Neil Gaiman, one of my favourite authors. I think oh, he’s in the UK at the moment. I was about to message somebody, my wife in fact, to say hey, guess what? It’s Neil Gaiman. I thought why don’t I get up and go and introduce myself to him? So, I did.
Clare: Wow. Was he friendly?
Kevlin: Exactly as you would expect, yes, very much so.
Clare: Of course, fantastic. What is the best thing that has happened to you in the last month or so either work-related or non-work related?
Kevlin: Work has been somewhat predictable; it has all happened at my desk. Possibly dropping my son back at university. That was nice. Not to be rid of him, although it is now clear that he has now transitioned to that stage where he’s quite different at home and at university.
I think the best thing is probably a short story competition that I entered. You don’t know what the theme is until you start the competition. You are given a fixed period of time. Depending on the kind of competition, flash fiction or short story, that could be 48 hours, or it could be a number of days. You are given a brief; your story must be this genre. There’s a level of unknown, what am I going to get? You end up writing sometimes in genres that are unfamiliar. I would never sit down and say I’m going to write a thriller, but guess what? There we go. And ultimately, there’s no consequence. If my story is no good, then at least there’s a new story in the world.
Clare: Yes, that’s something that has stimulated you enough to have been one of the most enjoyable things you’ve done in the last month. That’s fantastic.
Kevlin: Yes, it was a very interesting one. I was reminded this is why I like writing. I think the pandemic has been very bad for writing. Although you have, sometimes, some time, it’s terrible for inspiration. It’s terrible for your mental point of view, the mental freedom you might otherwise enjoy with creative acts. This was a real reminder that yes, I like this stuff. It was fun.
Clare: Yes, I think a lot of people have struggled with that. There’s this idea that you have more time, so therefore you ought to be able to do amazing things with it. But what you don’t have is the inspiration or the motivation or a lot of the other things that you need. Time on its own is not enough.
Kevlin: Again, that learning thing is that time is not the only thing. We like to attribute things to time. I think that’s true in all walks of life. We like to say we don’t have enough time, and I am certainly somebody who has said stuff like that. But we’ve been running this huge – I was going to say controlled experiment, but it’s rather uncontrolled – planet-wide experiment and we have discovered, many of us individually have discovered that time wasn’t the problem that we thought it was. There are other things here. It’s to do with connection and motivation and all of these other things. There is a certain Groundhog Day experience that many of us are going through.
Clare: Tell me about it.
Kevlin: This was outside that. Likewise, driving my son to Sheffield. Oh, my goodness, I get to drive somewhere!
Clare: I know, it’s so exciting.
Kevlin: I get to go more than ten minutes away from my home. That was just utterly thrilling.
Clare: I have had exactly the same experience taking my son to and from London, which is where he is at university. Yes, it’s very exciting.
So, where can people find you, and do you have anything coming up that you would like to plug?
Kevlin: I have a bunch of online courses that I do. I’m always doing public courses, so probably the easiest thing to find me online is Kevlin Henney is, fortunately, fairly internet unique. You can find me on Twitter, I am also on LinkedIn. Those are probably the places that I’m likely to talk and interact and so on. I’m fairly easy to find.
Clare: Fantastic, yes. And it’s K-E-V-L-I-N and H-E-N-N-E-Y, which is pretty easy to guess, in fact. I guess probably the only potential surprise in there is that there is an E between the last N and the Y.
Kevlin: Yes.
Clare: Fantastic, thank you very much for being here. Hopefully, I will see you again at some conference at some point, or we can have another call.
Kevlin: Yes, thank you Clare.
As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.
A Kevlin Henney is an independent consultant, but also an error screen, normally seen in a public place.
Teams and individuals are always in a constant tug of war with change. They hate it and they love it, and they often disagree with each other about how and why and when. You have to be aware of the conflict that exists in relation to change, and that where you want to start change may not be the right place. You need to anticipate the need for change, or stagnation can creep up on you. You need to make conscious decisions about what you want to change and why and be aware of any trade-offs you are making.
Change itself can change. You can change your mind about what you want to change. Change can take time and it can be inconsistent over time.
People need to have input into and control over what they are being asked to change. It’s better if people can do change together, rather than individually. It helps to keep something stable to balance change. If you start with what you already do and build on that, that can be really helpful. For instance, if you want to introduce a new habit, build on an existing one.
Agile methodologies are all about change. You can’t standardise and memorialise your processes, but what you can do is use structures as a baseline and then jam around it.
Finally, you can use storytelling principles to design good test suites, and to write a good talk. Think about conflict, resolution, and insight.
That’s not all, we’re not done yet, so stick around for some extra content.
Every other episode, this last, short segment will be devoted to Hack of the Month, where one of my colleagues, and in the future our listeners too, will share a life or a work hack.
Today, we’re going to hear from Claire Guest, who is one of the engineers who has graduated from our academy programme.
Claire: So, my top tip would be although it can be really, really intimidating when there is so much that is unknown to you and there’s this big wide world of technology and you don’t know where to start, you can view it as a challenge and an exciting thing. So, every day, you’ve got the opportunity to learn a bit more and develop a bit more. Although it only feels like you’re making a little bit of progress every day, in a couple of months you look back and you are just amazed at the amount of stuff that you can do now, that you wouldn’t even have dreamed of a few months ago.
Working in the public sector means that at Made Tech, we really care about making a difference. So, for this final Making Life Better segment, myself and my colleagues will be sharing suggestions for small things we can do to make the world a better place.
This one comes from Adam Friday, who is one of our Delivery Managers here at Made Tech. He says walk more. I know we’ve probably all had enough of walking, as it’s been one of the few things we have been able to do over this time of restrictions. However, I think it’s good to draw positives from this experience, and for me, walking has been one of these. I walk to the shop when I can, rather than driving, I walk to meet friends. It’s better for the planet and it’s better for your mental health, plus there is nothing like some fresh air.
And that’s the end of another episode. You can find me on Twitter, @claresudbery, which might not be spelled the way that you think. There’s no ‘I’ in Clare, and ‘Sudbery’ is spelled the same way as surgery, with E-R-Y at the end.
I’ve got a few talks coming up. If you look at the events page on my medium blog, which is linked to from my Twitter profile, you will find all the details there.
You can find the podcast on Twitter @makingtechbett2. That’s; making, T-E-C-H-B-E-T-T-2. You can say hello, give us your feedback, give us any contributions you have for future episodes, or just have a chat with us.
Thank you to Rose for editing and thanks to Richard Murray for the music. You will find a link in the description. Also in the description is a link for subscribing for extra content. We will be releasing new episodes every fortnight. Thank you for listening and goodbye.
[Music Outro]
[Recording Ends]
Back to the episode
