Money flows rule everything

So I remember Docker coming out around 2014, so that’s seven years now… Seven years ago, Docker fascinated me. I thought it was amazing. Like, “You mean what?! Finally, containers that make sense.” LXC has been around for a long time, so I know that Google contributed to the Linux kernel and they were using it for a long, long time, and I also know that Heroku was fairly big and was very successful in that context… But the regular developer that was just coding some software and shipping it - they didn’t really use containers, until Docker came about. And I was fascinated by it. I thought that was amazing.

In 2014, at the time, I was a lead engineer for a startup called How Are You. And I was into Chef at the time, I was using Jenkins heavily… And I blogged about using Jenkins with Docker for continuous deployment. Again, this was 2014. And in that context, there was a meetup in London… Was it the London Ruby User Group?

It definitely wasn’t Ruby, because I would not have gone to a Ruby conference at that time.

Right. It wasn’t a conference, it was more like a meetup.

[04:24] Yeah, a meetup. I think it was like a DevOps… Maybe it was a DevOps things, or–

Yeah… I know ContainerCamp, or whatever the Docker equivalent was at the time… Container Days? Something like that. I can’t remember. It was a long time ago. And in that context, I know that we met, and you were like “Hey, Gerhard–” I think you’ve read something, or we’d be like on the same GitHub issue, or I can’t exactly remember how, but we realized that we have quite a few things in common. I was into shell scripting big time at the time, and you loved your shell scripts; even now you love your shell scripts. I do too, let’s be honest about it; you can’t hide it. And we were both fascinated by Docker at the time. I was more like as an end user, and you were more like in terms of what this means, and what does it represent for the wider sector, I believe, for the tech sector, because you had a more enterprisy experience at the time. Is that right, Ian?

It’s very different from my memory, Gerhard. [laughs]

That’s exactly what I thought. Like, what I remember is very different from what you – so what do you remember, Ian?

Okay, here’s how I remember it… And it just shows how fallible memory is. It’s a good reminder. So I remember giving a talk… I was working at a company called OpenBet, and we did backend systems for online gambling companies around the world… So it was like a big monolithic, old-school, three-tier system. And I’d heard about Docker, I’d read something in Wired, and I clicked through, and I got something going in 20 minutes… And I was like “This is amazing.” I had not actually heard of LXC before that. So I went to my colleague at work, the resident Egghead genius guy and I said “Do you know anything about this Docker thing?” And he said “No.” And I showed him, and he was like “Oh, right. I’ve been doing that for years, with LXC, and stuff.” He had his own containers set up with different setups on his host, and I was like “Do you realize how transformative this would be for engineers, how much time this would save us?”

So I did a little skunkworks project, deliberately went skunkworks because previous attempts to go the official route had not worked. I did something before with Erlang… So yeah I went the skunkworks route with a couple of really bright, young engineers, and we got the whole 15-year-old monolith packed into a single container. It was considered not the right way to do things, but we did that. And then we had it built daily. So engineers could just pull the new layer for that day to their machine, whether they were in London or whether they were in the Far East or wherever around the world, Australia… And they would have a working environment that was suitable for development, with all the applications on it. It was like 50, 60 different applications. It would have a complete database with realistic data on.

So engineers who’d spend weeks setting up their machines suddenly could just get going from day one. And they had a completely safe environment - they could trash it, they could commit it… Docker Commit was a wonderful thing, and it’s a shame it’s kind of disappeared from view… But you used to be able to just make changes, commit; make another change, commit. This was like Save Game. The game is to make the feature work.

I missed that completely. That’s crazy. I missed that feature. I didn’t even know it had it. Wow, okay… Okay, go on. This is really interesting. I’m finding new things out from seven years ago, which I completely missed.

[07:57] You could run your environment and then you could run a cron job that did some ETL process… And then you could go “Okay, Docker Commit. Now let’s do Docker Diff. Oh, these files changed. Why did those files change?” It’s like another debugging tool. It had so many things like this which were mind-blowing. We tried to use VMs, but the presales guys – you know, presales guys you’d think would love using VMs, because it’s like “Oh, you wanna see this setup? Right, here’s the VM for this.” They’d given up, because they were like “It’s more hassle than it’s worth. I’ve just set up a machine, I have a bunch of scripts etc.” I was like “Well, just take those scripts, stick them in a container, and then we’ve got something that people can work on, and it makes them super-productive.”

So how we met, to get back to the point, was I started talking about this in public, and I was terrified of talking in public. And I can’t remember – this is where my memory goes hazy, but it may have been the first talk I ever gave, and I was super-nervous, and I had practiced loads at home, and I got up and I said “Look, we don’t do CI/CD properly. We’re old school etc. But we do this Docker thing and I’ve found it to be transformative.” And anyway, it was a really kind of raw, honest “We’re messed up. Here’s how I’m trying to fix it” kind of thing. And people really responded well to this. They were laughing along with me, and it was fantastic. It felt so freeing, because suddenly it was like “Oh, I’m not just getting shouted at as like wasting your time, because you all know this already.” It was like, “Oh, you all wanna hear this.”

So those people came up to me afterwards and said that it was great to hear the real stuff… And you came up and said – I was gonna leave, because it felt like these were all sales talks… And then you’d get up and talk some real engineering. That’s wonderful. And we exchanged emails, and that’s how I remember us meeting.

That does bring some memories, but I do have to say, maybe that day was so bad that I mostly forgot about it… Because you’re right, we did exchange emails, and then nothing happened for a long time. And then we met again. I said, “Hey, Ian.” And at the time I think you were working for Barclays when we met the second time… And that was like years apart. And you were in this enterprise IT for a bank; Barclays is a huge bank in the U.K, and I think even in the world… And you were working in the context of that IT department, and you were working with containers, and you were still on Docker, and I think that you were – either you have only just published the Docker in Practice ( the first book), or you were very close to publishing it. Do you remember whether you’d already published it at the time?

So the chronology was I had found out that with this Docker stuff, with its surveys among the engineers who were using it, and one team had adopted it completely, and we found that we saved (self-reported) four man days a month per engineer. And I thought it was actually more, because they didn’t wanna say “We were wasting our time before, but now we’ve cut a load of time out”, but basically a week of a month of developer time was taken out. And I was like “Great. I have this evidence now. I have a story. I’m gonna go to the board and ask for funding.” So I said “I wanna talk to the board.” I’d been there 14 years, and they said “Yeah, we can fit you in in six months.” And at the same time, someone from Barclays was saying “We need a Docker expert. Come work for us.” And I said “No. I never wanna work for a bank.” And this went on for a while. And I got tricked into a couple of interviews without knowing it, and in the end I went, because the team there was so impressive, and I was scared by them.” I was like “I haven’t felt this scared for a long time.”

“So I’m gonna join you, because you scared me.”

They scared me…

Really the opposite thing happens when you get scared… You run away. Not you. You run towards the danger. [laughs]

Well, this is actually a philosophical point… I often say to people, “You should feel uncomfortable at work about 30% of the time.”

30% afraid. Okay.

Yeah. Not more than that… But if you’re feeling uncomfortable 3% of the time, you’re not moving enough.

[12:18] When you mean uncomfortable, do you mean like out of your depth, like you don’t know enough, or what type of uncomfortable do you mean?

Well, it’s never good to feel out of your depth, right? So when I say uncomfortable, I mean – it’s kind of related to another piece of advice that I liked many years ago, which was if you have a choice between doing two things at work, and one of them makes you feel slightly uncomfortable, do the slightly uncomfortable thing. Because you’re smelling the opportunity for development. Of course, it’s terrible to be stressed. We’ve all been there we’ve been at 3AM and shouted at our customer. It’s not fun, and this is not a way to live. But generally, you should be feeling like “I’m pushing myself. I’m at my limit somehow. I’m stretching, slightly.” I think it’s the feeling of being stretched.

I see. I think I would call it challenged. You should feel like you’re challenged, you’re learning something you maybe don’t know, you don’t have all the answers and you’re figuring things out… Because that’s growth. Failing - that’s great; keep failing, because those things you don’t know, and that’s how you learn, and that’s how you grow. So I think challenged is how I would put it.

I think that’s a better word, yeah.

Okay, okay. So 30%, like a third of your time you should feel challenged, so that you’re learning, so that you’re not being static, stagnating, and feeling like “Well, what’s the point? Nothing’s happening. I’m not going anywhere. I’m stuck.”

Yeah, so in this 14-year company that I worked for, it was a very narrow domain, and everyone there was an expert in that domain… And it was a very challenging environment; people were really into it, and you had to kind of work – but you were working in this narrow domain. So I went to talk to these people at Barclays and they were part of the infrastructure team. So it wasn’t only that they were working for Barclays, which is, as you say, a huge organization, but they were in the belly of the beast. They were trying to produce the stuff that the rest of the business would use. And one of the things when I’m explaining how enterprises are tough, I try to explain that if you’re in an engineering team in a big company that has a lot of process and a lot of oversight (regulation), a small team can get away with a lot if they wanna go around the side, because it’s like “It’s one app. It doesn’t really affect the whole business. There are risks. We need to mitigate those risks. But as long as we have looked at it…” “Yeah, you can have that.” You can get away with this, you can get away with that. But if you’re working in infrastructure, you’re delivering stuff to the whole business. The whole business is gonna use it.

At the time, at the beginning, we were working on OpenShift version 2, which was pre-Docker. That was rolled out to the whole business, so any team could use it. So the rigor and the demand on security and audit and control was enormous… And it was very little about technology. I mean, the choice was made, the product was chosen and used pretty much out of the books. But everything else around it - the architecture had to be a certain way, and be built a certain way. We had to figure out workarounds for certain problems. These things were really hard, and I’d never experienced them before.

So one of the things that was really attractive was like I’d worked in unregulated – we had router production everywhere and these huge databases with millions and millions going through them every hour, to a place where everything is really tightly locked down. And I was like “I’ve never worked in that environment, I’ve never worked in infrastructure, I’ve never worked in banking.” Worst-case scenario, I’ll get six months banking experience, which is probably valuable somehow somewhere else. So even if I go in and they think I suck, at least I’ll take away something from the experience. So I stayed there for 3,5 years…

[16:04] You went from the initial Docker experience and Docker in Practice book I was talking about the second time we’ve met… You were working for Barclays, and I think you have almost maybe just finished writing the book, or it was just published… It was around that time. This was the first edition. You wrote a second edition as well since, so…

Yes.

I don’t think you wrote another book, but you did write some courses… Is that right? Or like self-published books, the Hard Way. Because you had Git the Hard Way. Bash the Hard Way. Terraform the Hard Way. Were they self-published books, or courses? What were they?

Yeah, the book was published when I was at Barclay’s, and that was a very long process. And then when the book came out, it sold very well… So they said “We want a second edition.” I thought naively that the second edition would be “Add a chapter a here, take a chapter out there, revise some stuff, fix some stuff, and we’re done. It’s not gonna be much work.” But actually, they treat it like a whole new book. You don’t literally start from scratch, of course, you take the original book, but they go through each one, and you have to work through each part. So it was much more arduous than I thought.

The self-published books came about because – well, I can’t actually remember the chronology. I think I did the Git one first. So I was working in Barclays infrastructure, and there were all these super-smart people around me, but they were very infrastructure-focused; they were not from a dev background. And they were doing these projects with Terraform in the cloud; they were actually trying to create accounts per team that were automatically provisioned and had all the controls that were needed, and so on, but were still AWS-native; so it wasn’t like a wrapper around AWS. It was a kind of template for building out accounts.

Anyway, long story short - they came to me one day and said “Oh, Ian, you know about Git. Can you help us with – we’re trying to find out where this change came from.” I was like “Oh, great. Just send me the reference to the repo. I’ll download the repo and I’ll figure it out.” So I downloaded the repo, did git log --graphs my usual trick… And I got a page of pipes. I was like, “Okay, what’s going on here…?” And I said “How is this structured?” They were like “Well, we have 12 teams working on this product, and each team has about seven people… And each team has its own branch, and they have features off those branches.” I was like, “Okay, do you rebase?” They were like “What are you talking about? No, we merge.” I was like, “Okay… So this is why I’m seeing a whole bunch of pipes, because there’s so many branches, and they’re all merged in, therefore there’s no single line of change.”

So I tried to explain what rebasing is, and of course, I got to the deeper points about Git… And I realized, “Oh, to get there, I need to explain all this other stuff.” So I created a course for people at Barclays who were using Git, but wanted to understand it more deeply.

I’d read “Learn Ruby the Hard Way”, because I was doing Chef at the time, and I’d read a couple of other of the books by Zed Shaw, who kind of popularized the Hard Way method. I wrote to Zed and I said “Is this your trademark/copyright? Would you be pissed off/upset if I used this in my books?” and he said “No, it’s fine. I can’t trademark it. It’s actually an older idea that I took…” So I was like “Cool. I can use it. Well, I’ve got this course. I could turn it into a book.” So I did that. The book was pretty well received.

Then I thought “You know what - I don’t know Bash as well as I like, and there’s so many things about Bash where I’d like to use the Hard Way method so I can understand how it works…” So I wrote one on Bash, and that was really popular. That sold really well.

[19:51] Then I was learning Terraform and I thought “This is how I learn stuff now.” I pick up a technology, I use it, and then I’m like “I really wanna understand it more thoroughly. Writing a book is the way to do that.” So that’s what happened with Docker - I felt like a complete impostor; they were asking me to write this book because I’d been giving talks and someone had recommended me… And there I was, writing this book, thinking “Surely, someone proper should be writing this book, but not me.” But I got away with it, and I thought “Well, let’s keep this going.”

And of course, self-publishing is easier in the sense that you have more control. No one is telling you how to write it, no one is telling you you need more of this, that and the other, and you can kind of follow your vision more closely.

If you were to write a book today, would you go via a publisher, or would you self-publish?

It would very much depend. I really enjoy the self-publishing, because of two reasons. One is pretty selfish - I take 80% of the money. But more seriously, you don’t write books to become rich, you write books because they develop you… And it would depend in which way it would develop me.

My interests now are moving up the stack towards management and consulting, and so if Wiley came to me and said “Would you like to write a book on money flows in tech, in organizations?” I would be up for that, because it’s Wiley, and that would increase my credibility.

Something the editor told me when I started writing Docker in Practice - because I said, “No one writes books for the money, right?” He said, “Well, you can make some money, but what you’ll find is that it puts you in a different category in the industry.” And that was very true. Suddenly, doors are opening to me. Not because I knew more about something than other people I knew, but simply because I’d written a book.

I always say to people, if someone tells me now “I’ve written a book on X”, I don’t think “Wow, they must know so much about X.” I think “Wow, they must be really organized.” Because the hard bit of writing a book, once you get past the basic knowledge you need to write it, is having the level of organization to hold down the job and do it.

I can see that. It is discipline, you’re right. It is the commitment, it is seeing it through shipping it… Because it’s very different – I mean, maybe if you self-publish you can do chapters at a time, and then the book grows… With a publisher it’s a little bit different. It’s a bit more structured, it’s a bit more demanding maybe… And you have to make that stuff work besides your job. I mean, okay, maybe your employer is understanding, in a way, but it doesn’t mean that you can stop working and just focus on your book. It doesn’t work like that.

And still, you managed to write a published book – well, two, because the second edition is not the same book, as you pointed out… And you also self-published three books. And also, you have the course. We’ll add a link in the show notes, but if you’re curious and if you want to contribute to Ian’s future self-publishing books, check them out. Because I think contributing directly to the authors is a great way of showing appreciation, showing that “Yeah, I like that. It’s great content. Thank you for it.” So yeah, that really helps.

I would like us to start going a bit up the stack, as you mentioned… So we talked Git, we talked Bash, we talked history, how it all began… Very different recollections of that. I remember that I started giving you some feedback on the Bash the Hard Way, but I don’t think I finished… Maybe like ten pages, or something like that; I was very busy and I never finished that review properly, so sorry about that… It was not intentional.

I don’t remember, but yeah, it’s fine…

Yeah, I still remember that. When you mentioned Bash, I was like “Ahh, I should have given you some feedback five years ago or three years ago (however long it was).” Yeah, I did like part of it, but then I had to stop.

So the title of this episode is “Follow the money.” And the reason why it is what it is is because you told me that this is something that you have on your mind quite a lot. You’ve mentioned very briefly money flows, so first of all, I’m curious what money are we talking about? Is it the proverbial money, is it the actual money? Who should follow it and why?

Sure, yeah. So I was aware that when we called this “Follow the money”, that it would sound like I was saying “Hey, you should get all the money you can as an engineer.” And that’s very much not what I’m saying… Especially when I mentioned that I worked for banks, it really sounds like I was money-grabbing. So I wanna make that clear from the outset - what I’m talking about with “Follow the money” is that… So as I mentioned, I worked in a very narrow domain, and the economic model of it was really simple; so simple it was invisible to me. So customer wanted thing, customer had platform, customer paid licenses. Customer wanted thing, customer had time and materials, and customer paid for ongoing support and maintenance. That was the model.

I didn’t think about this too much as a significant thing, but then we tried to convert to being a product company, and failed. There were also reasons we could argue about, about why that failed… But I took that experience, I had my ideas about we used the wrong technologies, or we had the wrong culture, or whatever. I took that experience and then I went to Barclays. And I’ve found that there it was far less about the technology and far more about the organizational. So I became less interested in technology, because there were better and worse technologies for any given situation… But really, what causes success or failure in these organizations is the structure of the organization, and so on.

There was a common meme when we talk about DevOps and we talk about software engineering development, that when you’re young, you think about tools. “Should I use Go, or should I use Java, or should I use Ruby…?” And people really focus on that. Then the wise old person says “No, no, no. It’s not about that. It’s about team organization, and agility, and so on.” So you get to thinking about these things. And then the slightly older person says “No, it’s about culture.” And then I’d find the conversation just stops. Like, people just say it’s culture, and you go “Okay, it’s culture. Now what? How do I change a culture?” And this got me thinking – you know, I was one of those humanities students. I came to software when I was 25, when I wanted a different kind of career. And as a humanities student, I studied modern history; I obviously read about Marxian ideas, and one of the Marxist ideas was the material base, the kind of structure of material exchange in capitalism, and so on, ultimately determines the superstructure, which is culture. This is kind of where my mind’s been going recently, because I’ve been involved in various projects where we’re looking at why things are struggling to happen, and we uncovered that the business thinks of things in a completely different way than the engineers.

[28:04] The engineers think of a platform as this continuously engineered product, and it needs constant investment, and this investment is repaid over time, and the more you build it and the more you automate, the more you get as investment over time.

But some organizations are still in this very transactional “I pay for something and then I have a thing”, and then that’s it. So getting them to think in this kind of continuous investment way and selling something that isn’t just “Oh, we had ten engineers working for a month, and therefore it costs X”, we have this thing that is of value to you, and this is of this much value, and we have to invest in it to maintain it. This kind of way of thinking comes ultimately from the way companies run their accounts, is my hypothesis. And in order to really debug an organization and why it’s struggling to move to cloud-native, or DevOps, or whatever, you ultimately end up back with accounts.

I saw this in banks, to some extent, because we were building a platform that was consumed by the rest of the business, so it was like a product, but there was actually no way for us to be paid internally for that. So we had - I don’t know how many teams - many, many teams using this platform, but the ones who were using it more than others weren’t necessarily paying more. It was very opaque; we couldn’t actually get to the bottom of how the money was moving around. And actually, the whole business was structured around yearly review cycles, yearly accounting cycles. You couldn’t say like “Oh, we have a new version of this product and we need to invest in previous cycle.” It’s like, “Well, that wasn’t in the original budget for the year.” So you can’t be agile when you have to think in yearly cycles. You just think “What are we gonna do this year? We need to get the budget for this year.” It doesn’t work where every three months the number of people on our platform is doubling, but we had no more budget to support that, so we had to borrow, beg and steal money from other bits.

These are all questions that make me think “Oh, you know what’s at the bottom of this? It’s how money moves around in an organization, and why money moves around in an organization.” If you can sort that out, or at least get that aligned with the way you want to work, then suddenly things can move much faster. Organizations that are built from the ground up as microservices typically have a different cost structure. They allocate money to teams, and they’re responsible for products.

I spoke to my CFO where I work at Container Solutions and he said “Yeah, there’s this whole thing called agile accounting.” And he was a big fan of it. He turned me on to a couple of books on the subject… It tries to overthrow this yearly cycle in favor of continuous accounting… Because that’s familiar to us, right? Continuous accounting, continuous software.

So there must be a Conway’s Law type thing here, which says that the organizational structure determines the tools and technologies you use, but what determines the organization structure? Well, one way to look at it is the financial structure. How does money move around? So you get this thing of like – you’re always getting back to money. So this is why I say “Follow the money”, because if everything is working fine, you’re getting the resources you need to do your job properly, and then it’s invisible; you don’t care. But when things are going wrong, it’s like “Well, I’m debugging…” We did the Five Whys exercise with our customer recently. It was like “Well, why can’t you allocate someone full-time to this platform?” And they said “Well, we can’t do that because they get pulled away.” “Why do they get pulled away?” “Well, because we have other projects.” “Why do you have other projects?” And we kind of went around in circles, and then eventually we got to “Oh, because your time and materials company, and you think of things in terms of built, finished, done, and not in terms of “Oh, this needs to be continuously maintained.” So the senior management are saying “The platform is finished. Why are we still talking about it?” It’s like, “No, that’s the wrong way to think about it.” It’s in the accounts is the thing and now it’s depreciating. We finished it. It’s built.”

[32:06] Once we go back to that, someone else pointed out - someone very experienced pointed out and called it. Accounts are very used to the idea of investment. If you buy a warehouse, they understand that you buy the warehouse and you have to maintain the warehouse. Amazon don’t just buy a warehouse and then think it’s done. They buy a warehouse, big expense, and then they say “Right, there’s gonna be some ongoing expense here, as we need cleaners, we need janitors, we need security etc. Or we need to rebuild a part of it, because the products we store in them have changed.”

This is all not new to accountants, they understand it… But we don’t talk to them. As engineers, we’re scared of – maybe I speak for myself, but it’s a bit like when people talk to us, they suddenly get these jargon words, and we’re like “We have no idea what you’re talking about.” It’s like for us when we get to accountants. They start talking about tax deductions, and things we’re not that interested in necessarily… And it’s very technical. But if you get someone who wants to work with you, it can be completely eye-opening.

I remember learning about the difference between cap-ex and op-ex, and I was like – suddenly, it makes sense to me why the cloud has taken off, because it’s treated differently from a tax point of view and a spending point of view. Suddenly, cloud makes a lot more sense.

So I haven’t formed this into a coherent theory yet. There’s still some thoughts sort of flying around in my head, but it’s something that I’m super interested in exploring more.

I find that really fascinating, in that you’re right, we rarely think about that. Maybe if you’re a self-bootstrap business and you have a product that you’re working on, maybe the relationship is very clear between what you’re investing your time in and the return on that investment. Are you doing the right thing? And if you are, then the money is going up, and the income is going up, and you have more money to work with, which means that you can spend more time on the things that maybe generate that money, or other more important things… But the whole point is just keep the money flowing, keep the money - not necessarily coming in, because it has to go out as well. You’re not hoarding money. You use money to make more money, that’s the way it works (or it should work).

It’s interesting of thinking it in terms of money flows, and continuous money flows. I think when you’re starting a budget, even your personal budget - you know, like, okay, you’re saving money, but don’t focus on the pot, focus on what’s incoming and what’s outgoing. As a result of that, you will build a pot. That’s just how it works. Or different types of pots. So that makes sense.

As I mentioned, a self-bootstrap business - I think it’s very clear. A medium-sized business - maybe it starts getting a bit more opaque. 100 people, 200 people… But once you get to tens of thousands, even hundreds of thousands of people, this is completely opaque. You don’t even actually – and I know that some companies, you can’t even know how much money you’re making; it’s just not allowed beyond a certain level. I’m sure there’s very good reasons for it, especially if there’s like an IPO company, a publicly-traded company, things are even more complicated.

So this is very interesting, but again, I fail to see how this would make – I mean, smaller company yes. Bigger company - it’s just impossible. So would you use some sort of proxies?

Let’s imagine that you’re part of a big company, and let’s imagine that you’re working on a product which is sold for licenses, as you mentioned; you buy the thing and you use the thing, and then you renew your license every year. Let’s imagine that the team that is working on the product cannot know the cost that those licenses generate, regardless of the reason. What do they do?

[35:53] Well, yes, this opaqueness is absolutely part of the problem. I think what I was talking about earlier was more like structural stuff. But if we’re talking from a point of view of an engineer - when I was working for very large organizations, I had the same question, “How can we measure the value we’re generating for the business and then justify more revenue as a result?” And they got really political and complicated, because the best measure we came out with was the number of teams in production, or using the platform. And there were different measures: production, testing, dev etc. And we took those numbers, but we didn’t even really know where to take them, because as I say, we had these yearly budget cycles, which were way up the chain, beyond what we could understand. We had no idea if this information was going up to that part.

So even that structure wasn’t set up for people to think about things in terms of “Well, I’m delivering this value to the business, and therefore I can justify this funding for future growth.” It just hadn’t been joined up.

When you’re a company of a certain size - and being opaque is fine; most people don’t have the time, or energy, or inclination to think about these things. When those companies want to change, they just say to themselves “Oh, we’ll just be Agile now. We’ll put some posters up, and we’ll have some courses, and we’ll use a few new words to describe small things, and we’re okay. We’re Agile now.” And my feedback to companies who were trying to do that is always “You have to think deeper than that.” And usually, we stop at culture. But I’m starting to think that’s not enough, because like I said, okay, our culture is broken. Now what do we do? You can’t just magic up a culture. It’s very vague.

In fact, I read a blog piece called “Five things I did to change an IT team’s culture.” I was given the task of managing an IT team where the director had left… I did five specific things to change the team’s culture, from firing someone, to getting my hands dirty on the floor and looking at the pipes of work that were coming in… Because I wanted to say – you can’t just say culture is a problem and then walk away. “Here’s my invoice. Culture’s a problem.” You’ve gotta actually suggest something. And so at the time, the things I was suggesting were tough things, like firing people, and getting your hands dirty on the floor to see what’s happening. Like the goal in the book we were talking about before the podcast; one of the key things in that book was that the manager never actually went to the floor until he had to. So he had all these reports about the machines in the factory, and then he went on the floor and he’s like “Hang on a sec, that doesn’t really match. The reality on the floor is that we have these two machines which are sitting idle. Why are they sitting idle?” “Oh, because you told us we should use the new machines, which are less productive.” Like, “No, switch the old machines on. We need to deliver.”

Going to the floor is a huge thing. That’s practical thinking, too. But another practical thing that I’m thinking about now is this whole money flows things. And it’s not an easy sell, because “Why is this guy who knows about Kubernetes suddenly telling me about cap ex, and op ex, and money flows? This is not what I hired him for.” So you kind of have to be patient. But eventually, you get there with them, and they can start to see that this is a problem potentially. But I think it’s a very underexplored area, and I’m super interested.

The more conversations I have with different people, the more I realize that it is this holistic approach that people are not taking. They are comfortable talking about being uncomfortable in their own little narrow area, whether it’s coding, whether it’s operations, whether it’s whatever it may be… And they don’t have the energy, don’t have the interest, don’t have the time to step out of that narrow area and get uncomfortable. But maybe the real opportunity is outside of your comfort area. It’s when you start thinking “How does the money flow in the business? And how does my work impact the money flow? How does my work and my approach impact culture? Am I being a bad person?” I wanted to say “Am I being a jerk?”, but I don’t know whether that’s politically correct; I don’t know what the politically correct term is, but am I being a difficult person about this? And could I be doing more? And am I doing the right thing? Am I even doing the right thing?

[40:25] Maybe we look up to our managers and our leaders and expect them to have all the answers… But it’s a collective thing. It’s a team effort. We have to come together, and different people bring different experiences. And you’re right, I think this is a very underexplored area. We don’t know the relationship that exists in different companies between money flows and the value that we create and the value that we contribute. Maybe you would like to work more efficiently, but what does it mean? It’s not more lines of code, it’s not deleting even lines of code. It’s not that. It’s something else. It’s mentoring, being kind? Sure, to some extent yes, but there’s more to it. So what is this more?

One of the things that I now advise every team that’s moving towards CI/CD is not Jenkins over this, or whatever tool that you think… I say “First, measure how expensive it is to make a change on your system.” Let’s take a CSS change to your site. One hex value change. How long does that take to go through the pipe as it stands. And you get answers of like “Well, it takes three weeks, because QA have to check it, and we have to get the project management, we have to get this done etc.” And it’s like, okay, so that can take three weeks. So you have a number. You end up with some number. One small change, one trivial change costs the company X.

So now do we do GitHub, or CI/CD? Arguably, they’re the same thing… And we then measure the costs of the change now. So now you’ve automated your tests, now you’ve done this. Oh, you may still have a legacy QA process that makes everyone feel happy, but it’s short-term, because that stuff is destined. We have fewer errors, that means things go back around in the cycle. We have fewer bugs resulting. That’s the other thing - how much the business has tracked the cost of maintenance to their products. How much is that related to – actually, something has just occurred to me, which is that when I worked with that company before, I worked in third line support, and we were well-funded. I mean, we felt super-busy. We were super-busy and stressed. But if we needed more money, we could go ask for it… Because customers paid for support, and they paid well for it, because they cared about it. So they would give us lots of money for support. It was pooled up into one bunch of money, and then we had a team that services all these customers, composed of engineers and tech leads together, fixing stuff in real-time.

Other companies don’t have that money flow. They don’t have the same thing; they ignore maintenance, and kind of beg, borrow and steal energy from engineers to fix stuff while keeping them busy with other stuff… But they just pretend it’s not there. So if you can get measurements on these things, then you can start to draw a graph and say “Okay, we’ve spent X amount on the platform.” Platforms are very front-loaded; you have to spend a little money before you get any kind of return… But the return should be felt over time. This is not a new idea in business, it’s a very old idea. But you can end up with a graph which says “Okay, so we’ve spent a million pounds building the platform”, which is done now in the old way of thinking; whereas before it cost 10,000 pounds to make a single change, now it costs 1,000 pounds. So we’ve cut that thing in 10. So we used to do ten releases a year, now we can do a hundred.

[44:01] So that’s the financial metric… What’s the non-financial metric? Well, we can do even more. We have fewer bugs, we have easier rollbacks, we don’t have big meetings with lots of project managers in them and tech leads discussing the huge amount of changes that are going in once every month. All these things make a very good case for “Give us more funding and we can make it better.”

You also have to link to sales. Sales is a pipe of money, right? And if sales think of things in terms of transactional, they pay for something and it’s just done - that’s incorrect. With one organization we ended up discussing we should have invisible line items on sales, to say “Well, behind the scenes they’re paying for this product, but they don’t know it.” Or you put it on there and they say “What the hell is that?” and you go “Oh, don’t worry. We’ll scrub it off for you”, but actually you account for it internally. And by doing that, you can say “Okay, we’re bringing X amount of money in, therefore we can have our own team, therefore we can have focus, therefore we can hire maybe more people who are more focused on this new way of doing things”, and you potentially build up this virtuous circle.

But if you don’t think about these things when you’re starting the process, then it can flounder as you encounter them later. That’s a pattern I’ve seen in all the businesses I’ve worked that want to change the way they work. You start by thinking about the tools, and then you end up dealing with stuff that you didn’t even think about, like how sales thinks about what they’re selling. The salesmen are super-smart at hiding costs and changing invoices to make the customer happy, but it’s actually the same amount of money. These things turn out to be super-interesting if you get involved with them, but it’s not where you start as an engineer. You start over there – I’m sure actually CFOs go through the same journey, because a lot of accountants become CEOs. They start thinking of things in terms of nice, clean spreadsheets, and then they go and become a CEO and suddenly they’re axing a whole team, because they look at the spreadsheet and it’s “I can get rid of this number”, but they find there’s also secondary effects they hadn’t thought about, because they come from that background.

We have the same problem - we think of things in terms of technology and process, and we like system design, and thinking of things in terms of that, but we don’t wanna think about the money; it’s kind of annoying. “I have to go and talk to someone about getting – just give me the money I need to get the job done. Why is this–” But that’s the reality of what we do. It’s all connected. It’s holistic.

So we were talking about money flows, we were talking about the cost of change, which is something that really stuck with me. We were talking about the holistic approach to developing and shipping code. Shipping value. It’s not just code, it’s value, and I think if you start thinking about things in those terms, the work that you do will be more valuable, because that’s the way you approach it. it’s not about lines of code, it’s not about changes, it’s about what you contribute to the world. Maybe the world’s a bit too grandiose for some, to our users - whether it’s five, five thousand, fifty thousand; it doesn’t really matter. Users will benefit from what you do.

So with that in mind, what would you say that is the biggest mistake, in your experience, that you’ve seen developers make? Because you’ve been around the block a couple of times now, you’ve seen small orgs, big orgs, banks, startups, everything in between… Maybe there’s multiple mistakes that you see developers make, or software engineers. Anything that stands out?

Yes, I think it’s related to what we were talking about - it’s the lack of holistic thinking… Which is completely natural. Because if you’re a specialist and you’re young, you will have focused very tightly on your domain of knowledge, and worked hard to improve that, and we’ve all been there. I make this mistake, of course. I think every engineer makes this mistake as they’re younger, so I’m not saying I’m somehow special. But as you get older, as I get older, I think more holistically about it. So what I find is that engineers think – let’s take an example… I had a lot of engineers surrounding me when I was working at Barclays, because I was named as the owner of Docker, this technology. So each technology in a company like Barclays has an owner, and they’re responsible for the lifecycle of that technology within the organization.

So people were friending me up and saying “I wanna use Docker.” And I would have to explain to them “I can’t just install it on your machine. There are these following blocks.” And some of them were interested, but most of them were just kind of impatient, like “Can’t you just give me what I want?” And what I’ve found was that those people that thought about it more were more successful, because they would say like “Okay, so you need XYZ to do it. Is there a way I can talk to my manager or talk to their manager or something to kind of get the money moving around, so you can get what you need? Or can I join myself to your team and actually do the work with you to get it done?”

So that’s kind of a microcosm; that’s kind of a single anecdote. But generally, I see engineers just thinking about things in terms of technology. Here’s a perfect example - I made that mistake when I tried to do Erlang in the business. I thought “Erlang is a perfect fit for some of our problems. It’s a functional programming language, it’s message passing, it’s actor based… This will have all sorts of benefits for us”, and I just went full speed ahead with that. And then when it came to actually trying to roll it out, we found that engineers used to see syntax really struggled with Erlang, to the point where they were just writing things in misguided ways because they just didn’t grok the way things should be built. It’s like cloud-native, you have to think in a different way to build it. And that doesn’t just happen overnight. People still use their old mental tools to apply them. So this initiative floundered.

So this is a mistake I often see, failing to see – and it’s not a criticism of them, of these people… But if they fail to respond to that challenge, that’s the mistake, I think, that they make… Because you’ve gotta learn these rules of business somehow. Or you can just stick in your own domain and work away at it. But usually, you get to the point where you’re frustrated by something, or you can see how something can be done better, and you want to kind of go and make that change… And at that point you need to start thinking more widely.

[51:52] I think it is valuable to stay focused, especially if you’re passionate about something and you feel connected to that thing, and you feel like you’re making great progress… That is very valuable. Some call it flow… By all means, do that. That is important. But be aware there’s more to it than that. And if you stay in that mode for too long, your success will be hampered by the fact that you’re staying in that mode. It’s almost like the equivalent of taking your headphones off, walking around and talking to people. It’s the equivalent of that… But in this case, it’s the business. It’s maybe the sales department. It’s maybe the marketing department. It’s all connected. It’s accounting. And you can ignore it; not a problem. Again, there’s no right or wrong here. What we’re saying is that if you’re a bit more aware of what’s happening around you, you will be more successful. You’ll feel more connected to the business.

Yeah.

So look around. Stop. It’s okay to stop. It’s okay to take a break. Because guess what - when you get back into flow, you’ll be more efficient, you will be more guided; you will be better connected to everything else… Because it is a team sport. It’s not just you. Even when you think it’s your company, and it’s your product, and there’s no one else, you have your users. So you have to pay attention to that. And it’s all the things that you’re not doing, that you should be doing. And that’s when a lot of people get stretched, and they get out of depth; it’s like a nice little progression, it doesn’t happen overnight. That’s okay. Be kind to yourself and to others (but it starts with yourself), and open your eyes. The world is a big place, and there are people that want to help, there are people that know what they’re talking about, there are people that failed in N ways until they realized there is a better way than just coding and shipping and coding and shipping. There’s so much more to it.

So you’ve mentioned Container Solutions a couple of times… I know that there’s this very – well, I won’t say very popular, but it’s a concept which is increasing in popularity. WTF is X. So my question is, first of all, who is Container Solutions and what is WTF is X?

Right. So who is Container Solutions - Container Solutions is a consultancy that helps companies move to cloud-native. That’s typically what we do. But we like to think that we have a wider perspective than just that. What we often do with companies is we don’t just go in and say “Hey, you should be using Kubernetes” or “You should be using Docker.” Actually, sometimes we say “You shouldn’t.”

My first assignment actually with Container Solutions (or CS, as I call it), was to go to work on an assessment - we do these two-week assessments, where we go in and we interview 15-20 people within an organization, the key people, for an hour each. We collate the information we’ve gathered, we synthesize that, and then we analyze that, and then we produce a report of how they should get to where they want to be, or how we think they should get to where they want to be. And one of these companies - they said “We wanna use containers” and we said “No, no, no. You’re thinking about this wrong. Maybe for the new stuff you use containers, but the old stuff stays where it is, because it’s low risk, it’s generating huge piles of cache for you… So just leave it. Invest in it, maintain it. But if you try and rebuild everything from scratch, you incur a huge risk.” So first learn on the side, and maybe learn from those lessons, and draw them back in.

The reason I joined Container Solutions was because I had a meeting with the owner, a guy called Jamie Dobson, and he immediately figured out my frustrations with work, and told me “I could help you enjoy work more.” And that’s exactly what’s happened since I joined… Because I now I feel like I’m thinking about the real problems. I’ve spent years working in large organizations, seeing projects flounder, and it was nothing to do with tech, and it was nothing to do with a lack of will, or nothing like that. It was simply that the problems weren’t being analyzed in the right way.

[56:09] So what happens is we often get companies coming to us saying “Hey, we want Kubernetes. You can give us Kubernetes, right? How much will it cost to get Kubernetes?” And we kind of say “Yeah, we know Kubernetes. We have engineers, we write operators, we do all this stuff… But we don’t start there. We start at a higher level and look at the way you’re approaching this, and have you thought about all the things that you need to think about.” And companies really like that… It builds a lot of trust… Because we often go in and say things which seem to be not in our interest.

We did an assessment recently of one company, and we basically told them that they’re actually a shining beacon of how everything should be done, and maybe we can learn from them actually, more than them from us. That was really satisfying, because we got to tell the truth, and not just say like “Hey, we’ve got this whole model of how you should move everything to Kubernetes, and have a platform team… This is our blueprint for you.” We don’t have a blueprint, we have an analysis process.

So we get to tell the truth… That’s a lot of fun. A lot of fun. Obviously, we have our expertise in tech, and that’s where we come in, so we have to demonstrate that… But yeah, that’s CS.

One of the things that I find very valuable on your GitHub, on the Container Solutions GitHub, is the Kubernetes examples that you have, the Terraform examples… I think you had a lot to do with that. The reason why I wanna call these things out is because it is – like, if you care about the tech, check those repos out. There’s a lot of very good examples and very good approaches to something that you would maybe google for. Search for them. There’s a lot of good stuff in a single place. So if that’s your curiosity, check it out. You will find it super-useful.

The other thing which I want to say, in a conclusion to what you were saying, is it’s really resonated with me, helping people in a way that they need, not necessarily telling them what they want to hear. Telling them the truth, the reality… Like “Hey, you don’t have a problem.” Or “You do have a problem.” Or “The problem that you think you have - it’s not the actual problem.” So having this honest approach will always win. Even if it’s not in your best interest. Because what you care about is the customer’s best interest. That is a winning approach in anyone’s book, I’m sure. If you care more about the other company/person/whatever than you care about your own interests - that’s great. And find the alignment, where do your interests meet with my interests. If there’s no union, that’s okay. It’s not a good combination.

Yeah, it is very satisfying. It’s more satisfying to work in an environment like that. You learn a lot more quickly, because there’s no formula. You can’t go into a company with a fully – everyone has prejudices and experiences which fly against reality, but the 15 hours of interview process is a really good way to get beyond that… Because you have to actually start thinking about “How did these people see it? How is that different from my way of seeing it?”

You very quickly develop a mental model of how different organizations work, and that’s really a very valuable skill to gain. It’s something that I’ve really developed over the last year, because I’ve worked with companies that are fully microservice-based, and then companies where they don’t wanna use cloud because it’s too expensive, and they like having their data center. And we actually told them “Keep going. You’ll be fine.”

So the reason we can say that, in that example, in that case, was because we can see that you understand the limitations of what you’re doing and how you’re doing it, but you’ve actually accounted for that; you’re ready for those challenges. And they did actually use cloud for some things where it made sense, but they were very resistant to it.

[01:00:02.10] Anyway, you get to see all these different ways of thinking in environments, so you learn to become more flexible in your thinking, and it affects everything… Whereas when I worked in the same place for 14 years, I felt very stuck in a very particular line of thinking and way of thinking, that has been challenged heavily since.

WTF is X, that’s what I’m thinking.

Yes, yes. We didn’t get back to that, right. So what happened is during the pandemic we’ve been very active in conferences, and setting up events, and so on… So the pandemic hitting suddenly, “What do we do now?” This is a whole area of business that we have hired people to do. So we flipped and we started doing some online stuff and we learned some lessons, and we did a couple of conferences… And then the marketing team at CS and Jamie came out with this concept of WTF. It was a really great hook, because I think a lot of people in – I mean, we all know in tech that there are all these things coming at you all the time: GitHub, microservices, Docker, Kubernetes, Swarm… They never stop coming.

Yeah.

And you go to a conference and people are talking about it and you are kind of smiling along, and sometimes you know what they’re talking about, and sometimes you think you know what they’re talking about, sometimes you have no idea what they’re talking about… And you don’t often go “Hang on a sec… Time out. Sit down and explain this to me carefully for 20 minutes.” You don’t do that. You just kind of go “I think I get it from context. It’s fine.”

Everyone does this in the industry, and it’s even harder if you don’t have a technical background, or maybe you’re a buyer, or a senior leader who is less confident about this stuff. So wouldn’t it be great if we had this sort of banner of WTF, so that we could actually say “You can come along to these events and we’ll try and explain to you what it is. And if you have questions - great, let’s hear them and maybe we’ll discuss it more.”

One of them we did was WTF is GitOps, which I did… There was a small technical demo, but it was really just kind of showing people who wanted that kind of thing really “Where does this come from? What does this mean? If you hear this in a meeting, what should you be thinking? Where can you slot this?”

I don’t think there’s enough of that in software. I’ve noticed over the years that the really experienced engineers and the really confident engineers are the ones who always say “I don’t know what that means. Tell me what that means.” And then there’s often a very short five to 20-second discussion between the two people about “What does that mean?” “Oh, it’s like this.” “Oh, so it’s like that.” “Yeah.” “Okay, right. Now I have a clear idea what it is.” This is what experienced people do. It’s that old paradox of the more experienced you are, the more comfortable you are saying “I don’t know what you’re talking about.” That’s something I had to develop when I worked in banking, because you’re having acronyms thrown at you all the time, and you have no idea if it’s industry-standard, if it’s company-standard… You have to kind of go “Okay, I don’t know what that means. Please explain to me what that means.” You have to kind of get over your having been in a domain where you knew everything.

So yeah, I love that side of it. We recently did a conference, WTF is SRE, and we had many thousands of people attending. It was like a super-success, and we were like “Finally, we think we’ve cracked how to do stuff online now, how to do a conference online now.” But it was a long way to get there.

And on the WTFs I also do a gossip thing. So the first ten minutes we have general stuff, and then we have a little section where we talk about gossip in the community, and that’s kind of fun.

[01:03:41.18] So it’s pretty light, it’s not a heavy, serious thing… And it’s not heavy on demos or tooling. It’s much more about exploring concepts in the industry, and what they mean, and learning from the people who come, and vice-versa. We often get even side discussions going on the chats, on the Zoom, and they’re super-interesting. Because you get stuck in a bubble working in consultancy. You’re completely immersed in Kubernetes, and operators, and Terraform, and GitOps, and you think everyone knows this stuff… And of course, people don’t. They either don’t care, or they don’t come across it. So it’s really important to get your head out of your own space sometimes, and kind of see things from the other point of view, because otherwise you end up as a consultant just talking jargon to yourself.

I really like the approach of – so first of all, I have attended a few of those, even like the WTF is SRE; that was a really good conference. I think the videos are now available on YouTube, so you can go and check them out. There’s the Container Solutions website, and everything is linked there. There’s also the YouTube channels, you can go and check them out; we will add them to the show notes. But my perspective and my conclusion was that it’s where humans meet tech in a human way; no impostors, no high horses, and that is something that Changelog does a lot as well… Or at least we try to. I’m sure everybody fails, let’s be honest about it, but we try to call it how it is. “I don’t know. What did you mean, Ian? What money? Do you mean I should get a better job, is that what you mean?” No. Obviously, that’s not what you mean.

And things change all the time, right? We always improve. So those improvements - how do you share them? How do you improve as a whole, as a group? Because the only successful teams, the really successful teams are the ones that improve as a whole. It’s not individuals, it’s the interactions. Are the interactions better? Are your team members getting better? Is the industry as a whole getting better, kinder, wiser, learning from its past mistakes and not repeating them?

That’s really funny, because my first engagement with a customer at CS I got criticized in the first week for not doing enough high-level architecture. I was a lead on this project, I came in halfway through it… And I was like “I don’t understand… Why do they think that?” And it turned out that – because I was spending a lot of time mentoring the junior staff, I didn’t know the technologies so well, pairing with them and trying to help move them along… And I explained to them that I thought “You architecture is fine. You know what you’re doing. The problem is not the tech, the problem is that your junior engineers don’t understand it. And as you roll this out, they’re gonna have to get it. So let’s invest in that.”

And what they actually wanted from me was like a rubber stamp of like “Your architecture is fine”, but it came over as this kind of “Oh, we think you should be doing high-level architecture.” And it’s like, “No, no. I think I know what’s better for you, but I should have actually called out that your architecture was fine. I didn’t realize you needed that from me.” It’s an interesting dynamic there.

Biases and preconceptions. Oh, my goodness… I’m pretty sure that if we were to have another discussion tomorrow, I think it would be on that, how to manage preconceptions. Because they seem to be at the core of many things that we do. We assume that things are good, or fit, or the right thing.

When I was talking to Dave Farley the other day, he was saying “Always assume that you’re wrong… Because guess what - you won’t be wrong.” If you assume that you’re wrong, you won’t be wrong. If anything, you’ll be right. “Oh, actually I was right.” But you assume that you’re wrong; you won’t be negatively surprised. Double-check. Learn. Have that mindset of learning, on being open to a better way… Because there’s always a better way. And people that think that they know that their approach is best - they are the ones that need this the most… Because it’s not. Don’t be sure of anything. Always double-check. And if you have that approach, the sky is the limit. And not even the sky. Elon Musk, right? Mars, whatever.

[01:08:08.29] That’s right, yeah.

Another solar system.

Yeah.

Okay. So this conversation, if anything, it reminded me how important it is to talk to you, and I don’t think we did enough in the past… But I want that to change, definitely. Is there anything that you’re looking forward to in the next six months or twelve months? Because that is a very nice segue into the next conversation, where we can pick it up from here.

Well, yeah… I mean, at work I’m moving more towards doing that high-level analysis work, the lower-level technical work. So I’m excited about getting more involved in that and figuring out how to be more efficient and effective at delivering that work, because it obviously is one thing to do the analysis, and the other big thing is how do you present that information in a way that it can be heard well… Because it’s not just the logical exercise, you also – sometimes it’s a bit like a therapeutic process in the sense that you can’t tell the person everything you think they should do straight away. Sometimes you have to measure it out in spoons, like “First you need this, and then you need that.” It sounds kind of patronizing, but if you overwhelm them with “Oh my God, you need to change everything. It’s all a disaster”, they might just react very badly to that. So you have to kind of balance this honesty and transparency with this kind of how best can you help them change, or help them move towards where they want to go.

Sometimes I have done it too fast, tried to move people too fast and introduce ideas that they’re not ready for, and you get a lot of pushback… Sometimes I conform too much to the way they wanna think and don’t push back enough. It’s an art, it’s not a science, and this is the stuff I’m really interested in learning more about.

I’m really looking forward to having that conversation, Ian, 6-12 months from now, however many months it’s going to be… Because I think this progression, as you mentioned, is super-important… So one-off’s - what is one-off these days? What is transactional these days? It’s relationships. It’s building blocks and journeys. You build on top of conversations, you learn new things, you share those new things, you talk about them… Because as you talk about them, they improve, just by talking, the concepts. You refine them. And you go back in time six months and you realize “Actually, you know what - I was wrong. What I thought was right - that was actually wrong. However, another thing which I completely disconsidered proved out to be very important, and that’s what I’ve learned.”

I think that’s really important. I think we are getting better at that. I see conferences that are long-standing. Every six months you have a KubeCon. That’s a great example. So many relationships are built and so many ideas get born, and then they just fly. WTF is SRE - that was a great conference. The platform is really good, by the way; I really enjoyed that. And I’m sure there are many other things like that that will emerge as the world around us changes.

The world is not the same, and it won’t be the same again. 2020 taught us so many things… Those that wanted to learn. Because others are still blind and they still claim everything’s back to normal and it will be back to normal… It won’t. But that’s not even the point. The point is where are we going? Where do we want to go? And shipping it - such a small part. Important, but such a small part.

Ian, it was my pleasure. Thank you for your time, and I look forward to speaking with you the next time.

Thank you, Gerhard. It was a lot of fun. I really enjoyed it.