[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.
I have a passion for learning, and I deliver training content to engineers on our Made Tech Academy Programme, so I’m really interested in how team’s learn. Jessica Kerr is an expert on helping teams to learn. She is currently delivering workshops on systems thinking with Kent Beck, so I was really excited to catch up with her on the 22nd of December and find out what a symmathesy is and how to deliberately enhance the learning feedback loop within our teams.
Clare: Today, I have Jessica Kerr here with me… who is a software developer of twenty years, currently an independent consultant for Jessitron LLC. I’m really excited to have Jess here today. I’m really glad that she agreed to speak to me. She’s a fantastic conference speaker, a very highly regarded consultant. She knows a hell of a lot about dev ops transformations and how to build effective software teams.
The thing that really made me want to speak to Jess today, was that we both share an excitement about helping software teams to be inspired creative learning organisms. Before we get to all that, I’d love to kick off by asking who, in this industry, are you most inspired by?
Jessica: That’s such an interesting question, and I am honoured to be the first guest on your podcast. Who am I inspired by? I’ve thought about this overnight, and the thing is, there’s not just one person. The industry as a whole is so exciting, it’s in such a phase of growth and exploration as we struggle to figure out what software development is. I hope we never do, because I hope we are continually evolving what software development is like we are right now.
There are so many people that I admire and am inspired by. For instance, Jabe Bloom and Abeba Birhane come to mind. They are both thinking in much broader terms. Jade’s doing his dissertation on design of change. Design of change that takes hundreds of years. Software relates into this because it’s such a big part of that, of how we do change and how we stop change.
There’s people who have been around for a long time, like Kent Beck and Eric Evans but are still writing new things. It’s such a place of continual learning. There’s just so many people.
Clare: Yes, and the thing about continual learning – and that’s the thing that we’re going to be talking about today – that’s the thing we are both really interested in. I’m intrigued by the idea of change over 100 years or more. 100 years ago, did we have software?
Jess: No, that’s the fascinating thing.
Clare: Yes.
Jess: Let’s see, a hundred years ago, that was 1920. No, we did not have software then. I think it started to emerge in the 1950s and 1960s. Here’s another person, Hillel Wayne, I think it is, Hillelogram on Twitter.
Clare: Okay, how’s that spelt?
Jess: H-I-L-L-E-L-O-G-R-A-M.
Clare: Fantastic.
Jess: I don’t even know people’s last names; I know their unique ID which is their Twitter. He wrote a lot about software history, and works into current conversations in development. It’s a recent enough industry that you can know a good chunk of the history. Also, we keep recording ourselves.
Clare: That’s true. There is so much. You can know a lot of the history, but you can never know everything that is happening in software at the moment. So, I guess you can never know everything that has happened because there’s just so much of it. Between us, we must have collective knowledge, but one individual can never know all of the things. This is one of the things that blows my mind about software.
Jess: Yes. One individual can never know half of how a computer works anymore.
Clare: Yes. When I’m teaching people, that’s something that I always make a point of saying to them. Do not think that you can do a course or a degree or even several years’ worth of study, and ever reach a point where you think that you know all the things that there are to know about software development. That point will never arrive, and you have to make your peace with that.
Jess: Oh, if it ever arrived that would be so sad!
Clare: Yes, because then you wouldn’t have anything to learn, and that’s the exciting bit, right?
Jess: Right.
Clare: I feel like all of this has been preamble, and I haven’t even officially asked you any of my official questions on my list yet. But before we do that, I just can’t resist. I have to say I love your hair!
Jess: Thanks, I like yours too.
Clare: It’s amazing, you look fantastic.
Okay, we’re going to be talking today about how our teams are naturally learning organisms. In the way they interact with each other and the way they interact with their software systems. We’re going to talk about how we can use both software tools and inter-team communication to deliberately enhance the learning feedback loop and acknowledge that we are constantly creating the next versions of ourselves.
We’re going to talk about how teams can create their own APIs to enhance collaborations with other teams. We’re going to be talking about Symmathesy. Symmathesy is a word that I hadn’t even heard of until I looked at Jess’s website, so I’m going to ask Jess to explain the word. What is symmathesy?
Jess: Symmathesy, it’s from the Latin ‘symm’, sympathy, and ‘matthesy’, learning. It was coined by Nora Bateson, who is an anthropologist. A symmathesy is a learning system made of learning parts. Nora particularly needed this to describe ecosystems and economies. In an economy, you’ve got all of these businesses and consumers, constantly changing in response to the market in response to each other. So, the parts are always learning, and therefore the system as a whole is learning and changing. Therefore, the parts have to learn and change etcetera.
Our teams are like this. Our teams are composed of people and, I argue; in software development, running software. We’re all learning from each other. Of course, we learn from each other as people but also, the software learns from us because we change it. We learn from the software when it throws exceptions or changes data. Also, our tools are part of this system, this symmathesy that is our team because we don’t change the software without tools. We need our version control and our deployment systems and our build tools. We learn only through our tools, through our SQL prompts at a low level, through our log aggregators, hopefully through our observability, and through our tests, and various other – some of the tools, like our tests, they exist to help us learn from our software. We get to create those at the same time.
I love this about software in particular, and this is one of the reasons, I think, that the software industry has a better opportunity than any other that I know of. I did work in biotech for a while. You can inject genes in the seeds, but then; did the gene get in there? You can synthesise the gene, you can hurtle it at the seeds with these laser gun things, but did it get in? You don’t know. Sometimes they will inject genes that glow under black light, along with the gene they are interested in, to find out whether the gene got into the seed. Then how many did it get in? You don’t know. It’s so hard to know what effect you’ve had on the system and what’s going on in there.
In software, that’s just a log statement. We can throw that in any time. I said that’s just a log statement, but I think logs are kind of a holdover from when that was the only way we had to get information out of our system. Now, just a log statement, that writes some data somewhere. At least now we have log aggregators that can pull the stuff together and search through it, but that’s because we didn’t put very much information in the log statement; information that can structure it and get that message to the right future self.
So, tools like Honeycomb, I love them. I love Honeycomb because you can put whatever you want in that structured log statement. You can throw whatever you want in there and then you can build queries to find those. Also, they fit within a context. Every Honeycomb event is within a span (or can be) or fit within a nested span and so on, so that you can contextualise this piece of information, this clue that you are leaving yourself.
Clare: Yes. You’ve just mentioned then the idea of our future selves. That reminds me of a phrase that you used when I talked to you about this last week. You talked about the next version of ourselves, which I find fascinating. Can you tell me a little bit about that and how that fits in with the idea of symmathesy?
Jess: Yes. This is a discrete learning which we can look at and then realise that when we take an action, when we choose to do something, there are two outcomes of our day, of our task, of whatever unit you want to look at, since it’s not very discrete. There are side effects on the world such as the code we wrote, the conversations we had with people and however that affected them, and there’s the next version of ourselves.
Take one day in the life of a developer. Our output might be some change to the code that’s learning in the system, and it’s however we changed as a person in our pair. What we learned that day is going to affect what we’re able to do in the future. So, the whole symmathesy has changed.
It’s important to think about that because if as a manager, for instance, you are pushing the developers that you are responsible for to only change the code, to only work on the software, and not giving them space to do it better and better and thoughtfully, in a way that also produces new versions of themselves with additional abilities, then you are really hampering your entire future.
Clare: Yes, yes. The interesting thing about that, is that we’re saying that everything that we do is going to be a learning process. Even more interesting, is that because everything we do is a learning process, that’s true whether we like it or not.
Jess: True.
Clare: So, there is always going to be a new version of ourselves. We either acknowledge it and celebrate it or we don’t, but it’s going to happen anyway. Therefore, what you have to do is acknowledge growth, and acknowledge change, and acknowledge that we are all going to be learning as we progress. That’s something we can capitalise on.
Jess: We’re building software systems that are bigger and more interesting than we can understand. We’re building teams, and other teams, and other teams, and organisations of teams, that the people outside, executives for instance, they can’t understand all of that. You kind of have to let go.
Clare: Yes, so that’s problematic though, isn’t it? How can we build teams that are agile with a small ’a’, that are flexible, that are able to learn, that are responsive, but also have them be understandable by other teams? Because teams have to collaborate with each other, so somehow, we have to coordinate these efforts. How do we do that?
Jess: Well, I think this goes back to software too; you make an API. [Laughing]
Clare: Fantastic! When you say API, do you literally mean API, or are you creating an analogy here? You’re saying that there are processes that teams can have that are like APIs?
Jess: Oh, sometimes you really implement them in software, in the sense that many organisations want all of their teams to use Jira, or all of their teams to use Rally, and the reasons they want that is because the reports roll up. They can get some sort of overview of what the teams are doing. The fact is; the higher levels of the organisation need some information about what’s going on.
Part of being responsive is being in some ways transparent, is being legible upward in the ways that people need. So that they can make not perfect predictions, but confidence intervals.
So we do need to provide information going outward. As an API, I think it shouldn’t matter how the team works internally. Maybe they use Trello, maybe they are lucky enough to be in the same place. I wish! Maybe they use a whiteboard or maybe they use Miro, whatever. They also need to provide information to the organisation in a way that rolls up but separate that from your internal workings.
[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.
We’ll return to our interview with Jess now. Just to remind you of where we were up to before the break, we were talking about coordinating with other groups in an organisation, and how responsiveness is more desirable than predictability, and how that fits in with agile methodologies.
Clare: You got very excited a minute ago and I didn’t let you continue. Was that the thing that you wanted to say?
Jess: Okay, it’s like functional programming again, where we make functions a first-class citizen of the language, a first-class value, I should say. Then we can consciously look at the function as a thing, pass it around, store it, blah blah. But those relationships between people, that shared context and vocabulary, we can make that a first-class member of the team. It’s the same with your tools, for instance. When you make those first-class, instead of, ‘Ugh, we just have to deploy, we have to have some way to deploy!’. So, this is good enough, but don’t spend anymore time on it. That tool, it determines the relationship that you have with your software. How quickly can you teach it something and in turn, learn from it? Those are first-class members of the team.
Clare: Okay, so what concrete techniques do you use with the teams that you work with to achieve symmathesy with those teams?
Jess: Concrete techniques for symmathesy. ChitChat and Slack is one, tooling, working on tooling. In the learning of the team as a whole, where in the team I include the running software. It’s part of how we achieve our purpose in the world. Not much use without it. There’s this line, Dr Cook and Dr David Woods call it ‘The Line of Representation’ in the resilience engineering community.
It’s the division between our social and physical space, and the digital space within the computer. That line is only crossed by screens, mice, keyboards. Our windows into that are only what we create, the buttons that we create, the displays we create. That is a high leverage point to increased learning in the system. When you can bring in Honeycomb and get drilldown into the clues that you need, for instance. When you can add tests because those come back to you, that is a high leverage point.
People often ask, how much time should you spend improving the system like this? The 80:20 rule; spend 80 percent of your time using the system to accomplish what the rest of the world wants from your little piece, and 20 percent of the time making it better for the future, so that every other 80 percent will be bigger.
Clare: Okay, so when you say, ‘using the system’, what do you mean by the system, in that context? Give me an example.
Jess: That’s a good question. So, I was thinking of the team’s ways of working, the team’s tooling, everything we have at our disposal to accomplish our wider purpose that our software adds as capability to the business. To improve or increase the capabilities that we add to the business, that’s our 80 percent.
Clare: Yes, so 80 percent of the time building and deploying software, and 20 percent of the time improving those pipelines and the ways that we’re deploying.
Jess: And what we know about and are; in relationships to each other and the rest of the business. Just generally, becoming a system that can do more and serve both its parts; that’s us, and the wider system.
Clare: Yes. I talked earlier about achieving symmathesy, but symmathesy is there whether you like it or not, isn’t it?
Jess: Yes, you’re learning something. That something may be just more ingrained habits, this is how I type this. You may just be becoming more bored and hungry, but you’re always changing.
Clare: Yes, so I suppose what you’re saying is recognise, be explicit about the fact that everybody is learning. We are learning as individuals; we are learning as teams. Recognise it, celebrate it, aim for it, and look at how the tools we use and the systems we use can enhance that. And actually, be consciously seeing how you can learn from your tools and your systems.
We are officially out of time, but can you hang on a little bit longer for some last, wrap-up questions?
Jess: Of course, I’m on vacation today.
Clare: Fantastic. We’ve been talking about how our teams are symmathesy and how that means that they are learning organisms, constantly learning from each other and their software systems. We’ve talked about how we can enhance that learning feedback loop through effective communication and collaborations, through creating APIs for teams and through good use of software tools. I suppose my first question would be, what would be your biggest takeaway that you would want people to have, when thinking about symmathesy and teams’ abilities to learn. If there was one thing they came away with after listening to this podcast, what would be the most important thing?
Jess: What you are doing is not correct. Your code is not correct, your software is not correct, your design is not correct. But because of our conscious, thoughtful effort, all of these things are becoming better all the time.
Clare: Lovely, I like that. So finally Jess, can you tell me one thing about yourself that is true, and one thing that is not true?
Jess: Alright. One is that I was in a band as a teenager, and I played both the flute and the tuba, but not at the same time.
Clare: Wow, okay! And the next fact that may or may not be true?
Jess: Another one is that my grandparents were authors and published over a hundred books between them.
Clare: Wow, I love that. They are both fantastic. Okay, so the way that this is going to work is that in a minute, I’m going to ask you to tell me which one is true, and which one isn’t. That’s not going to be broadcast on the podcast. So, people who want to know which one is true and which one isn’t will have to subscribe to find the answer.
Jess: They could ask me on Twitter.
Clare: Yes, they could! Go and find Jessitron on Twitter and ask her. I’m going to guess… that’s so hard. These books that your grandparents published, were they a particular genre?
Jess: They were mostly about missionaries.
Clare: Were your grandparents missionaries?
Jess: My grandfather was a minister. They went and worked with missionaries, but mostly they just wrote books.
Clare: And what kind of music were you making with your band when you were playing the flute and the tuba? Was that the correct instruments?
Jess: Whatever the school assigned, mostly. But sometimes video game soundtracks.
Clare: So, Jess, where can people find you, and do you have anything that you are particularly running or about to run or writing? Or anything that you would like to plug that you want people to know about?
Jess: Why, thank you, Clare! In general, you can find me on Twitter as @Jessitron, J-E-S-S-I-T-R-O-N. Also, jessitron.com as my blog. Currently I am excited about a workshop that I am doing with Kent Beck. He and I are teaching Invitation to Systems Thinking. Now, from where we are now, the next one is in January 2021, but that one is full already. Go to systemsthinking,dev to sign up and hear about the next one.
Clare: Fantastic. Is that systemsthinking all one word, no hyphens or anything?
Jess: Right. Systemsthinking.dev. I love that domain name.
Clare: It’s a good one. Let’s end on a high. Can you tell me what is the best thing that happened to you this month? It could be either work related or not work related, but what was the best thing that happened to you in the last month?
Jess: Well, it’s in between career related, I guess. I got to take the domain-driven design workshop from Eric Evans. That was really fun.
Clare: Ooh, yes. How long did it last?
Jess: We did four days of four hours each, over a weekend; Thursday, Friday, Monday, Tuesday. So, you had the weekend to process and do the homework, which I didn’t do because I did not have two hours that weekend. But it was great to dig into that. There’s so much wisdom in domain-driven design. It doesn’t try to get everything right up front. It says, on one hand, explore with your imagination what the model could be and what language fits the best and works the best. On the other hand, map the contexts as they exist in the system today in all their messiness, and then notice which area is the most important. Which area is crucial to the business based on its current strategy? Not even just what kind of business is it. There is no one core domain area of most import.
Then focus on improving that. It gives languages for the relationships between software teams that are dependent on each other, and a language to talk about the way that we talk to each other.
Clare: Yes, fantastic. Okay, thank you so much for talking to me today. I’m sure we will chat again, and maybe one day when this is all over, we will meet at a conference. Wouldn’t that be lovely?
Jess: Yes.
Clare: Cool.
Jess: Thank you, Clare, have a great day.
Clare: Thank you, okay, bye.
[Music Sting]
Clare: Just to help you process what you’ve heard, I’m going to do a quick recap. Jessica has talked to us about how our teams are symmathesies, which means that they are learning organisms. They are learning from each other and from their software systems. We can enhance that learning feedback loop by effective communication and collaboration, by creating APIs for our teams and by good use of our software tools. Also, teams can and should collaborate to learn together whilst still retaining their independence.
Every other episode, this last, short segment will be devoted to story time. Storytelling is useful for teaching, for unlocking empathy and for creating a sense of shared connection and trust in your teams. I love telling stories to both children and adults. I’m actually a lapsed member of the UK Society for Storytelling. The plan is that I’m going to be using stories to illustrate various points about effective software development.
This story is about a 25-hour weekend hackathon, Hack Manchester, which used to happen every October in Manchester. It’s 25 hours because it always happens on the weekend the clocks go back. When I first heard about it, I thought, nah, no way, I can’t write software in a month, never mind in 24 hours. So, I didn’t go. Then a couple of years later, I was working for AO.com and they had a team who were planning to go, who already knew what they were doing. I thought, okay, I could go along for the ride.
When I got there, it was mostly men. It was quite intimidating, but we all mucked in on our team and we made something we were pleased with.
Fast forward a few years, I’d been to a couple more Hack Manchester’s and I decided that for the next one, I was going to try and put together an all-female team, and then struggled to find any other women who really wanted to do this with me. I was beginning to think that I was going to have to give up on the whole idea.
At the last minute, I managed to persuade my friend Luce Carter and my friend Katie. We decided we were going to make an app for menopausal women and then thought, oh God, how are people going to react to this? People will be shocked, appalled that we are talking about such things as menopause. For me and my friend Katie, it meant admitting that we were ourselves approaching menopause. But we got on with it.
Then at the end of the event, there’s the awards ceremony. It goes on for a while and there are lots of different categories that get announced. We thought, oh well, never mind, we’ve done our best. Then at the very end of the awards ceremony, they announced the Best in Show category. They started talking about sex discrimination and age discrimination. No way! We actually got shortlisted for Best in Show. It was amazing.
But the story isn’t over yet. The following year, I managed to put together another all-female team. Me and Luce Carter again and then this time also, Cynthia Lee and Sal Freudenberg. Now, Luce and Sal and I are all neurodiverse and sleep is very important to us. This time, we decided that despite it being a 25-hour thing, we would go to bed rather than staying up all night. Time became the theme. We decided to make a time machine. If you want to know more about that, look up our blog posts.
The awards ceremony came around again. We sat through all of the different categories, we weren’t listed in any of them and then finally, at the very end, comes Best in Show. Surely, it couldn’t have happened again. I mean, no, right? But yep, we got shortlisted again, runner up for Best in Show for the second year running. Okay, we’d take that. Then they announced the winner, and it was us. We were just so excited. If you look at our blog post, you’ll see the photos of us being very excited.
So, that’s the happy ending of the story. What are the lessons? I think one of the things that it really reinforced for me is that it’s a good idea to do what scares you. Hackathons are scary but it feels so good to approach something scary like that, and then break through and come out the other side having achieved something.
Another lesson it reinforces is to not worry what people will think of you. Don’t worry that you’re making an app for menopausal women. Don’t worry that you’re sleeping when you’re not supposed to, because it’s an all-night hackathon. Don’t worry about having an all-female team at a mostly male event. Do what’s important to you.
The great thing there is that it’s a win-win scenario because in fact, people respond really well to people doing what they care about and being their true, authentic selves. And it’s so much more relaxing when you are being yourself and being honest about what you care about.
[Music]
Clare: And finally, we come to our Making Life Better segment, where colleagues share tips about how to make the world a better place. This week, Academy Engineer Zack Adlington shared with me the following tip. He says, ‘I pick up litter. Not all the time but just if I am walking from A to B and I can see a piece of litter in the same view. Boom! Up it comes. I’ve found that picking up even one tiny piece of litter makes me feel much better.’
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.
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
